Công cụ, MCP và Trình kết nối

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.

Skills Can Travel With the Server

Until recently, these two pieces usually arrived separately. A server could give an agent its tools, while the know-how for using them well lived somewhere else: in a skill installed on its own, a README, or the user's prompt. When the service changed, those instructions could quietly fall behind.

MCP's official Skills extension, finalized in September 2026, closes much of that gap. A server can now offer not only its tools but also the skills that explain how to use them, written in the same SKILL.md format described in Agents & Skills. Tools tell an agent what it can do. Skills tell it how to do the job well. Now both can come from the same server, so the instructions live beside the service they describe and can be kept current by the people who maintain it.

The mechanism builds on pieces you have already met. Each file in a skill is exposed as an MCP resource, conventionally with a skill:// URI. A client can list a server's skills with skills/list, fetch one with skills/get, and read its supporting files with resources/read.

The tracker server exposes search_issues and create_issue. The triage method (check for duplicates, follow the issue template) has to come from a separately installed skill or from your prompt, and it can drift when the service changes.

The same server also offers an issue-triage skill. The host sees only its name and description at first and loads the full instructions when a task calls for them. When the maintainers change the service, they can update the skill alongside it.

The host still decides how a skill reaches the model. The model might choose one by its name and description, or the user might pick it directly. Either way, the full instructions enter the context only when they are needed, and reading a SKILL.md file does not activate the skill by itself.

When a Tool Needs Time or an Answer

Most tool calls are brief exchanges: the agent asks, the server answers, and the work moves on. Some jobs do not fit that rhythm. A deep research run, a large report export, or a build can take many minutes, and some jobs reach a point where only the user can decide what happens next. MCP offers two ideas for these moments: Tasks, for work that needs time, and elicitation, for work that needs a person.

The official Tasks extension (io.modelcontextprotocol/tasks) changes how a slow tools/call ends. Instead of holding the request open until the job is done, the server can reply right away with a durable task handle, a little like the ticket you get at a coat check. The client can look in on the task with tasks/get, send updates or answers with tasks/update, stop it with tasks/cancel, and collect the result when it is ready. Meanwhile, the agent is free to keep working and come back later, which matters most for always-on bots that run jobs while you are away. Tasks are opt-in on both sides: the client declares support with each request, and the server decides, request by request, whether to create a task. Existing tools do not gain this ability on their own; the server's author has to add it.

The agent calls export_report and waits. The request stays open for minutes. If the connection drops, no one knows whether the export finished, and the agent can do nothing else until it returns.

The agent calls export_report and gets a task handle back at once. It moves on to other work, checks the task with tasks/get, and fetches the finished report when it is ready. If plans change, tasks/cancel stops it.

Elicitation lets a server pause and ask the user for structured input: "Deploy to staging?", "Confirm this refund?", or a missing detail the job cannot continue without. The host shows a small form, and the user can answer, decline, or cancel. Declining is a valid answer too, and the server decides what to do next. The two ideas meet naturally: a running task can pause in an input_required state and ask the user something mid-flight. Before a write, a question like this is a natural human-in-the-loop checkpoint, placed exactly where the decision matters.

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. These rules matter even more when a bot uses tools on a schedule while you are away, as described in Always-On Bots.

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