> ## Documentation Index > Fetch the complete documentation index at: https://docs.conduit.ai/llms.txt > Use this file to discover all available pages before exploring further. # Tools > Configure workspace tool defaults, per-agent tool access, MCP tools, and custom code tools. Tools let agents take actions and retrieve live data. In V3, tools can come from integrations, MCP connections, custom Python or JavaScript code, built-in Conduit capabilities, and AI-triggered workflows. Open **Agents** from the main sidebar, then select **Tools** from the Agents sidebar to manage workspace defaults. Open an individual agent and select **Tools** to override access for that agent. Tools are permissions rather than instructions. Enabling a tool means the agent is allowed to take that action, not that it knows when to. Pair a tool with a [Skill](/build-your-agent/skills) that says which situation calls for it. Wondering whether Conduit, or your integration, can do something? Open the agent's Tools tab and look. If you want to know whether Conduit can create a task in your PMS, the answer is whether that tool is listed there for you to enable. ## Workspace Tool Defaults The workspace Tools page has two tabs: | Tab | Use it for | | - | - | | **Tools** | Review connected apps that expose tools, create custom tools, and enable custom tools by default across the workspace. | | **Runs** | Inspect recent tool runs and results. | Custom tool workspace defaults are not the final word for every agent. Individual agents can override tool access in their own Tools tab. ## Tool Sources | Source | Where it appears | Notes | | - | - | - | | **Connection tools** | Workspace Tools and per-agent Tools | Installed through connected apps and integrations, including PMS wrapper tools that let an agent call PMS actions directly. The workspace page lists connections that expose tools; grant or remove access from an individual agent's Tools tab. | | **Custom tools** | Workspace Tools and per-agent Tools | Written in Python or JavaScript inside Conduit. | | **MCP tools** | Per-agent Tools and Operator Tools | Add MCP from the tool settings when the workspace needs external tool servers. | | **Built-in tools** | Per-agent Tools | Conduit-managed tools for native product capabilities, such as scheduling a follow-up, sleeping and waking the agent, and querying the data lake. See [Built-in Tools](#built-in-tools) below. | | **Workflow tools** | Tool pickers and Skills | Active AI-triggered workflows can be exposed as callable tools. | Some tool actions consume credits. Lightweight actions, such as updating a contact field, use few or no credits, while advanced actions, such as generating AI messages or placing voice calls, use more. See [Workflow Usage](/workflows/workflow-usage) for the credit cost of each action. PMS connections can expose two different things, and enabling one does not enable the other: * **Knowledge sync** imports PMS data into Knowledge so agents can retrieve it. See [Knowledge Base](/build-your-agent/knowledge-base/overview). * **Connection tools** wrap PMS APIs so an agent can call PMS actions directly during a conversation, instead of only reading synced data. The workspace Tools page currently shows connections that expose tools and custom tools. Built-in tools are configured from the individual agent's Tools tab when available for that agent. ## Connection Access Every connection has a scope, set when it's created and changeable later from **Settings > Connections**. | Scope | Who can use it | Typical case | | - | - | - | | **Workspace** | Everyone in the workspace | Your PMS, your shared inbox, anything the whole team relies on | | **Personal** | The person who created it, plus anyone they share it with | An account tied to one person, like a personal Google Drive | Personal connections are not shared automatically, because they often carry credentials to someone's own accounts. The owner shares them explicitly from **Settings > Connections**, either with individual teammates or with the whole workspace. ### What You See On An Agent's Tools Tab Every connection in the workspace is listed, including personal ones you don't have access to. Those appear greyed out with the owner's name. | Your access to the connection | Connection is listed | Tool names visible | Open the tool catalog | Turn tools on for the agent | | - | - | - | - | - | | You own it | Yes | Yes | Yes | Yes | | Shared with you | Yes | Yes | Yes | Yes | | Not shared with you | Yes, greyed out | Yes, if the agent already uses it | No | No | | Workspace scope | Yes | Yes | Yes | Yes | Connections you can't access are shown rather than hidden on purpose. If an agent is already using someone's personal connection, you can see that it's there and which of its tools are on, so the agent's behaviour is explainable even when the connection isn't yours. Its description, server address and configuration stay private. To get access, ask the owner to share the connection with you, or to move it to workspace scope. ### Attaching A Personal Connection To An Agent Agents are shared. Anyone in the workspace who uses an agent, and any guest talking to a customer-facing one, runs its tools through whatever connection is attached. That means attaching a personal connection to an agent runs it on the owner's credentials for everyone who uses that agent. Someone who was given access to one person's connection can attach it, and from then on the whole workspace reaches it through that agent. Before attaching a personal connection to an agent, check that you're comfortable with everyone who uses that agent acting through the owner's account. For anything the team relies on day to day, workspace scope is usually the better fit. ### Removing Access Removing someone's access to a personal connection stops them from opening its tool catalog and from attaching it to anything new. It does **not** remove the connection from agents it's already attached to. Those agents keep working through the owner's credentials. To stop that, open the agent's Tools tab and turn the connection off there. ## Per-Agent Overrides Open **Agents**, select an agent, then open **Tools**. Use the agent Tools tab to: * Enable or disable connection tools for that agent * Enable or disable custom tools for that agent * Add MCP access * Review built-in tools available to that agent * Search large tool lists Keep tool access narrow. Agents perform better when they have the tools needed for their job and not every possible action in the workspace. ## Built-in Tools Built-in tools are Conduit-managed capabilities that ship with the product, rather than something a workspace installs or writes. They're reviewed and enabled from an individual agent's Tools tab when available for that agent. | Tool | What it does | | - | - | | **Follow up** | Schedules a future check-in on a conversation instead of requiring the guest to reply right away. The agent can come back to the conversation on its own schedule rather than blocking on an immediate reply. | | **Sleep and wake** | Pauses the agent's own execution and resumes it later, so it can wait on an external event or a time delay without blocking. | | **Data lake query** | Queries the underlying data lake directly, for big-data-style, retroactive analysis across conversations and other workspace data rather than a single live per-conversation lookup. | Alongside these, an agent's Tools tab groups the everyday Conduit actions by area. What appears depends on your workspace, but the common groups are: | Group | What it lets the agent do | | - | - | | **Knowledge** | Get, search, and list Knowledge Base entries. Usually enabled already, since this is how the agent answers from the information you have added. | | **Contacts** | Look up an existing contact or create a new one. | | **Conversations** | Fetch a conversation and read earlier messages in it. | | **Conversation tags** | List the tags in your workspace and apply one to a conversation. | | **Places** | Get directions and local recommendations for a guest. | Applying tags is a common gap. Creating a conversation tag does not mean your agent can use it. The agent also needs the conversation tag tools enabled, and a Skill telling it which tag applies to which kind of message. Connected apps add their own tools on top. A PMS connection, for example, can expose actions such as updating a reservation or creating and updating tasks, each enabled individually. With the Devices add-on, agents can also inspect and control connected locks, thermostats, sensors, and cameras. This includes access-code management, device telemetry and history, lock and thermostat control, noise thresholds, and fleet health. See [Devices](/setup/tools-and-integrations/devices) for the complete tool reference and device policy behavior. ## Custom Tools Custom tools extend what agents can do with code. Open **Agents > Tools**, then create a new custom tool. ### Tool Fields | Field | Requirement | | - | - | | **Name** | Lowercase letters, numbers, and hyphens only. No spaces, no leading or trailing hyphen, no consecutive hyphens, and no conflict with internal tool names. | | **Description** | Tell the AI when and why to use the tool. This is model-facing instruction, not just a human label. | | **Language** | Python or JavaScript. | | **Parameters** | Add string, number, boolean, or enum inputs. Mark required fields and describe each parameter clearly. | | **Execution message** | The message shown while the tool runs. | | **Code** | Implement the tool logic in the editor. | ### Test A Custom Tool Use **Test** before saving or publishing tool changes. If the tool has parameters, Conduit asks for test values. The test panel shows JSON output, errors, logs, and runtime so you can verify the behavior before any agent depends on the tool. The editor warns before leaving with unsaved changes. Use Save intentionally after the test output matches the contract you want the agent to rely on. ## Tool Descriptions Tool descriptions are part of the agent instruction surface. Good descriptions answer: * What action does the tool perform? * When should the agent use it? * What information must the agent collect first? * What should the agent do if the tool fails? * What should the agent say after the tool succeeds? ## Operator Tool Access Operator has its own tool settings. Giving an agent access to a tool does not automatically give Operator the same access, and changing Operator's tools does not automatically change a customer-facing agent. Open **Operator > Settings > Tools** when you want Operator to use a tool while helping configure the workspace. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.