MCP and Custom Tools in Your Editor

Your coding agent can read and edit files, run tests, and grep the repo. It cannot see the ticket that describes the bug, query the staging database, or tell you whether the last deploy is green. So it guesses, and you spend your time pasting that context in by hand.

There is a cleaner way. You can give the agent tools of your own, wired to your internal systems, using the same protocol that connects any other MCP host. This article shows what to expose and how to wire it in.

The agent starts with a fixed toolbox

As covered in how AI coding tools actually work, a coding tool is an agent: a model in a loop with tools. Out of the box those tools are all about the filesystem and shell:

read_file(path), read a file
edit_file(path, changes), change one
search(query), find code across the repo
run_command(cmd), run tests, a build, a script

That set is enough to write code. It is not enough to work the way you do, because your job is not only code. It is code plus the ticket, plus the API contract, plus what production is actually doing right now. None of that lives in the repo, so none of it is in the toolbox.

Custom tools close that gap. You expose your own systems as tools the agent can call, and the vendor of your editor does not have to build a single integration for it.

MCP is the way you add tools

MCP (the Model Context Protocol) is an open standard for connecting an AI application to external tools and data. The application is the host; each integration is a server. Coding tools like Cursor, Claude Code, and Windsurf are all MCP hosts, so anything you expose as an MCP server becomes a tool the agent can call.

The value is that one server works everywhere. Write it once, and the same issue-tracker server plugs into your editor today and any other MCP host tomorrow. You are not coding to Cursor’s plugin API or Claude Code’s plugin API; you are coding to the protocol.

flowchart LR
    AGENT[Editor agent] -->|built in| FS[Files, shell]
    AGENT -->|MCP| ISSUES[Issue tracker]
    AGENT -->|MCP| API[Internal API]
    AGENT -->|MCP| DB[Database, read only]
    AGENT -->|MCP| DEPLOY[Deploy tooling]

What to expose, with concrete examples

The best custom tools answer a question the agent keeps having to guess at, or perform an action it currently asks you to do by hand. Four that pay off fast:

An issue tracker. A get_issue(id) tool that returns the title, description, acceptance criteria, and linked PRs. Now “fix the bug in PROJ-482” starts with the agent reading the actual ticket instead of you copy-pasting it. Add search_issues(query) and it can find related work on its own.

An internal API. Wrap the endpoints you already have. A lookup_customer(id) or get_feature_flags(env) tool lets the agent check real values instead of inventing plausible ones. This is the pattern in wrapping an API as an MCP server: the endpoint exists, you are giving the agent a typed door into it.

A database, read only. A run_query(sql) tool scoped to a read replica lets the agent check a schema, confirm a column type, or count rows before it writes a migration. Keep it read only and pointed at a replica; more on that below.

Deploy tooling. A deploy_status(service) tool answers “is staging green?” without you leaving the editor. A trigger_deploy(service, env) tool goes further and lets the agent ship, though that one you gate carefully.

How you wire a server in

Wiring an MCP server into a coding tool is the same shape as connecting any MCP host: you name the server and tell the tool how to start or reach it, in a config file. Most editors read a JSON block like this:

{
  "mcpServers": {
    "issues": {
      "command": "python",
      "args": ["-m", "company_issue_mcp"],
      "env": { "ISSUE_API_TOKEN": "${ISSUE_API_TOKEN}" }
    }
  }
}

That entry says: to use the issues server, run python -m company_issue_mcp and pass it a token from the environment. The editor launches the process, speaks MCP to it over stdio, and the tools that server advertises (get_issue, search_issues) show up in the agent’s toolbox. Remote servers look almost identical; you give a URL instead of a command.

How does the agent know when to call my custom tool?

The same way it knows when to call read_file.

Each MCP tool ships with a name, a description, and a typed schema for its arguments. The host loads those descriptions into the model’s context alongside the built-in tools. When your request matches what a tool’s description says it does, the model calls it.

So the description is not documentation, it is the routing logic. “Fetch a single issue by its ID, including description and acceptance criteria” gets called at the right moment. “Issue tool” does not. Writing good tool descriptions is the highest-leverage thing you do when building the server.

Once the config is in place, restart or reload the editor and the tools are live. From then on the agent decides when to call them, the same as it decides when to read a file.

Why this changes the work

Without custom tools, you are the integration layer. The agent hits the edge of the repo, and you fill the gap: you read the ticket to it, you run the query and paste the result, you check the dashboard and report back. Every one of those is a chance for you to summarize wrong or leave something out.

With custom tools, the agent reaches your systems directly. It reads the real ticket, runs the real query, checks the real deploy status. It stops guessing about the parts of your world that were previously invisible to it, and it can act on them in the same loop where it writes the code.

sequenceDiagram
    participant You
    participant Agent
    participant Issues as Issue tracker (MCP)
    participant DB as Database (MCP)
    You->>Agent: Fix PROJ-482
    Agent->>Issues: get_issue("PROJ-482")
    Issues-->>Agent: Title, repro steps, schema note
    Agent->>DB: run_query("describe orders")
    DB-->>Agent: Column types
    Agent->>You: Diff, grounded in real context

The result is fewer round trips and fewer wrong assumptions. The agent that can see your ticket and your schema writes a diff that fits the actual problem, not a plausible-sounding version of it.

This article is about consuming MCP servers inside your editor. Building one is its own topic: start with what MCP is for the protocol, then wrapping an API as an MCP server for the concrete build.

Common beginner mistakes

Exposing write access too early. Start with read-only tools. A trigger_deploy tool is powerful and dangerous; earn trust with deploy_status first.
Pointing a database tool at production. Use a read replica and a read-only role. The agent will run queries you did not anticipate.
Vague tool descriptions. “Database tool” will not get called at the right time. The description is the routing logic; write it like it matters.
Handing the server a broad token. Scope credentials to exactly what the tool needs. The token in your MCP config is as sensitive as any other secret.
Installing every server you find. Each server adds tools, and every tool description spends context. More tools is not better; relevant tools are.

Questions you will face in production

“Is it safe to give an agent a tool that can run SQL or deploy?” Read-only tools against a replica are low risk; treat them like giving a junior engineer read access. Write and action tools (deploys, mutations) are a different tier: gate them behind approval, scope the credentials tightly, and log every call. Default to read-only and add write access deliberately, one tool at a time.

“Do I have to build a separate integration for each editor?” No, that is the whole point of MCP. Write the server once against the protocol and it works in any MCP host: Cursor, Claude Code, Windsurf, and others. The only per-editor step is the config entry that tells each one how to start the server.

“The agent has my tool but never calls it. Why?” Almost always the tool description. The model routes on the description text, so if it is vague or does not match how you phrase requests, the tool sits unused. Rewrite the description to say plainly what the tool does and when to use it, then try again.

What to remember

Coding tools ship with file and shell tools; everything else is something you add
MCP is the standard way to expose your own systems as tools the agent can call
Good candidates: issue tracker, internal API, read-only database, deploy status
Wiring a server in is a config entry, the same shape as any MCP host
With custom tools the agent reaches your systems directly instead of guessing
Start read-only, scope credentials tightly, and write tool descriptions carefully

What to study next

Once your agent can reach your systems, the next question is how a whole team uses these tools safely: shared config, guardrails, and review. That is team workflows and guardrails. If you want to build the servers themselves rather than just consume them, go to what MCP is and then wrapping an API as an MCP server.