Tools, MCP and Connectors

You ask an agent to find the open bugs in your project and draft a follow-up issue. To do that, it needs more than good instructions. It needs a way to reach your issue tracker, read the right data, and possibly create something there.

This is where tools, connectors, and MCP come in. They are related, but they describe different parts of the setup.

Tools, APIs, Connectors, and MCP

A tool can also work locally. A calculator does not need an account connection. A file-reading tool may work entirely on your computer. An external service is only one possible source of tools.

What a Tool Actually Contains

A tool usually has a name, a description, an input schema, and an implementation that does the work. The description helps the model decide when to use it. The schema describes the arguments it accepts.

Here is a small fictional MCP tool definition:

The model might request search_issues with {"query": "open bugs", "limit": 3}. The surrounding application routes that request to the implementation. The implementation queries the tracker and returns results or an error.

The name and schema do not execute anything by themselves. The implementation must validate inputs, check access, and do the actual operation. A tool response is also separate from the model's final answer: the response might contain issue IDs and titles, which the model then summarizes. The MCP tools specification describes how tools expose these operations.

What a Connector Adds

A connector packages the integration with a particular system. It may handle signing in, selecting an account or workspace, finding data, and exposing supported actions as tools. Some connectors only search or read. Others also support writes.

Connector is a product term, not one universal technical standard. One connector might call a service's API directly. Another might use an MCP server. A third might search an index built from synced documents. Check what the specific integration supports. Microsoft's connector overview gives one example of integrations built around APIs.

Connecting an account does not mean the agent sees every file, loads all of your data into its context, or has permission to perform every action. Access depends on the account, configured scopes, the application, and the service's own permissions. Search results may also reflect an index that is older than the original documents.

For the issue tracker, keep these questions separate: Is a connection configured? Which project can it access? Can it only read, or can it create issues too?

What MCP Standardizes

MCP stands for Model Context Protocol. It defines a shared way for AI applications and external capability providers to communicate. It does not replace a service's API; an MCP server can use that API behind the scenes.

The MCP architecture has three main roles:

For a tool call, the client can discover the server's tools with tools/list. The application makes relevant tool definitions available to the model. If the model requests one, the application can send a tools/call request through its MCP client. The server executes or delegates the operation and returns the result.

The model does not need to open a network connection itself. The application and the MCP implementation handle the communication. Compatibility still matters: the host and server must support the capabilities you want to use. Discovering a tool does not guarantee permission to run it; access checks still apply.

MCP Offers More Than Tools

MCP also defines resources and prompts. These words have specific meanings in the protocol:

The MCP server concepts guide describes these as model-controlled tools, application-controlled resources, and user-controlled prompts. These describe the intended interaction patterns. They do not remove the application's permission checks.

An MCP prompt template is not automatically a skill. A skill can package a longer procedure, references, and scripts. It may tell the agent how to use tools provided through MCP, a direct connector, or local functions.

Try a Read and a Write

This example uses the same fictional tracker through two routes. Change the route, operation, or access level, then run the request. For a write, try both approving and declining it.

search_issues({
  "query": "open bugs"
})

The read and write modes here belong to our example integration. Real permissions can be more specific. MCP gives the two sides a common protocol. It does not decide whether your account can write to the project or whether the app should ask you first. Authentication establishes identity; authorization determines allowed access. A separate approval can confirm a particular action. Remote HTTP integrations can use the MCP authorization framework; the details depend on the integration.

Prompting an Agent That Has Tools

Tell the agent what information to look for, how to use it, and which actions you expect. Avoid assuming that a connection exists or that a tool supports every operation in the service.

Check the bugs and sort everything out.

Search the connected project for open bugs about empty search results. Summarize the relevant issues and include their IDs. Draft a follow-up issue if needed, but ask before creating it. If the connection or required tool is unavailable, explain what is missing. Do not claim an issue was created without a successful tool result.

A reusable triage skill could add the method: check for duplicates, compare reproduction steps, follow the project's issue template, and report unresolved questions. The tool provides the operation. The skill explains how to use it well.

Tool output still needs judgment. An issue comment, a document, or a search result can contain mistakes or text that looks like an instruction. Treat retrieved content as data, rather than allowing it to change the user's request or the application's rules. MCP support alone does not make a server or its contents trustworthy.

If a read fails, the agent can report the error or try a reasonable alternative. If a write times out, it should check whether the change happened before repeating it. Otherwise, a retry might create a duplicate issue. Credentials belong in the integration's connection setup, not in the task prompt.

The next chapter, The Harnesses, looks at the software that coordinates these connections, instructions, and tool results across a whole task.