> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # Connectors > Give investigations access to the systems only your team can reach. Extensions are currently in **Private Beta**. Get in touch by [email](mailto:support@incident.io) or our shared Slack channel if you'd like to try them out. The Model Context Protocol, or [MCP](https://modelcontextprotocol.io/), is an open standard for letting AI systems use your tools. Connect a remote MCP server and investigations can call the tools it exposes, pulling in context from the systems that make your stack yours. ## Prefer a native integration where one exists Many products now ship their own MCP server, so you can often connect the same tool either way. When we support something as a [telemetry data source](/investigations/connect/telemetry/overview), connect it there rather than through its MCP server. The telemetry system is built specifically for telemetry: it speaks each product's query language, learns the shape of your data, and remembers what worked in past incidents. A connector is a generic way to call tools, and it can't match that on telemetry work. Reach for a connector when there's no native integration to prefer. ## How tools are discovered and called When you connect a server, its tools are discovered automatically: each one's name, description, and the arguments it accepts. During an incident, investigations pick the tools that look relevant to what they're trying to understand, construct the arguments from the context they have, call them, and read the results back. If your server provides its own instructions on how to be used, those are captured too and used to steer how its tools are called. Connectors are also available to the agent, so a question asked in an incident channel can be answered using the same tools. HTTP APIs are coming soon. Today a connector is an MCP server. If you have an API you want investigations to reach, get in touch by [email](mailto:support@incident.io) or our shared Slack channel and we'll let you know when it lands. ## You choose which tools we can call A connected server might expose more tools than you want reachable during an incident, and some may make changes rather than read. You keep an allowlist: only the tools you enable can be called. A request to any tool that isn't on the allowlist is rejected before it ever reaches your server, so enabling read-only tools and leaving the rest off means there's nothing an investigation can change. Tools that make changes are held to a higher bar. A tool the server marks as read-only can be enabled and used. A tool that writes needs an administrator to allow it explicitly, and even then it can only be called when someone is talking to the agent, in your incident channel or the dashboard. Investigations run on their own, without anyone watching, so they never call a tool that writes. We read whether a tool makes changes from the `readOnlyHint` annotation your server sets on it. A tool that doesn't say is treated as though it writes, so it needs the same explicit permission. ## Connecting a server Connect your server directly with its endpoint, an auth token, and the tools you want to allow. 1. From [Extensions](https://app.incident.io/~/nexus/extensions), add a connector. 2. Configure the connection: * **Server endpoint**: the URL of your remote MCP server. * **Authentication**: a bearer token, or OAuth for servers that support it. 3. Test the connection. The server's tools are discovered, and you choose which ones we may call. 4. Review the allowlist and save the connection. Once connected, the connector is available immediately, limited to the tools on your allowlist. You can disable it at any time. ## Limits A single tool call has 32 seconds to return, including connecting to your server. Investigations run while people are waiting on them, so a call that hung would hold up everything behind it. A tool that takes longer is abandoned and the investigation carries on without it, which means a connector isn't the way to reach something slow: a job that runs for minutes, or an agent of your own that takes its time. ## Best practices * Allowlist only the tools you'd want reached during an incident. A shorter list helps us pick the right tool rather than the nearest-looking one, it's easier to reason about, and a tool nobody enabled can't surprise you. * Make sure each tool's description and arguments are clear on your server. We rely on them to decide which tool to call and how, the same way a person reading the tool list would. * Write a [skill](/investigations/extensions/plugins) that explains when to use the connector and what its results mean. A connector gives us the ability to call something. A skill is what tells us why we'd want to. ## FAQs Not yet. Connectors reach your server over the public internet. If the system behind it is one we support natively, you can reach that instead by running a [proxy](/integrations/proxy) in your network and connecting it as telemetry. Yes. We record the calls we made and what came back, so you can see what an investigation did and so a call that worked can guide later ones. If that's a concern for the data a tool returns, leave the tool off the allowlist. The investigation carries on without it. A connector that can't be reached is reported on its page in your dashboard, so a broken connection doesn't quietly degrade your investigations. ## Related Write skills that tell us how to use a connector. How plugins and connectors fit together.