Build your own tool
The ten built-in tools cover most needs, but they are general. If your team keeps asking the same specific question — "what changed between these two releases and what do I have to rewrite?" — you can describe that tool in a sentence or two and MCP Studio will build it for you.
| Audience | MCP creators who want a tool shaped around one recurring question |
|---|---|
| Prerequisites | At least one source added in the wizard's Sources step |
How it works
In the wizard's Tools step, choose Build my own tool. A chat window opens. Describe what the tool should do, press Enter, and it appears in the picker alongside the built-ins, already selected.
Building takes a few seconds. You will see progress in the chat while it happens.
What makes a good description
Say what question an AI agent is trying to answer and what it should get back. Be specific about the subject; you do not need to describe how retrieval should work.
"A tool that finds every breaking change and migration step between two versions of our SDK. When an agent asks about upgrading, it should return the relevant changelog entries, the deprecated methods, and the code needed to replace them."
That works because it names the subject (migrations, breaking changes, deprecations), the trigger (an agent asking about upgrading), and the expected result (changelog entries and replacement code).
Descriptions that produce weak tools are the vague ones — "a tool for our docs"
gives nothing to specialise on, and you already have search_docs for that.
What a custom tool actually does
This is the most important thing to understand, because it sets the boundary on what you can ask for.
A custom tool searches the sources you connected. That is the whole of it. It is a specialised search: it takes the agent's question, adds terms that steer retrieval toward your subject, searches your indexed content, and returns the matching passages with their source URLs.
Every tool you build uses one of three retrieval styles, chosen for you from your description:
| Style | Searches | Chosen for |
|---|---|---|
| Documentation | Indexed prose | Most tools. Guides, references, explanations. |
| Code examples | Code blocks and snippets | Implementations, signatures, configuration syntax. |
| Schemas and types | Both together | Type definitions and data models, where the answer is a snippet plus the paragraph explaining it. |
What it cannot do
A custom tool cannot:
- Write, edit, or delete anything
- Call an external API or service
- Send email, open tickets, or trigger a workflow
- Run code, scripts, or commands
- Search anything you have not added as a source
If you describe a tool that needs one of these, you will still get a tool — the closest useful search tool for that subject — but it will not perform the action. Its description will say what it actually returns.
Tools are built from a description typed into a text box, so a tool is never generated as runnable code. It is a retrieval recipe that MCP Studio interprets. That is what makes it safe to let anyone build one without a security review, and it is why the boundary is search rather than actions.
Changing a tool after you build it
There is no edit. To change a tool, delete it and build a new one.
- In the wizard's Tools step, find the tool under Your Tools.
- Select Delete.
- Choose Build my own tool and describe it again, with the change.
Your original description is saved with every tool, so rewording it is usually a matter of adjusting one sentence rather than starting over.
A custom tool belongs to your account, not to one server, so the same tool can be attached to several MCP servers. Deleting it detaches it from all of them. Those servers keep working and keep every other tool — they simply stop offering that one, on the next request, with no redeploy needed.
Tools are set when you deploy
Which tools an MCP server offers — built-in or custom — is decided in the wizard and fixed at Deploy. The dashboard does not currently have a tools panel, so you cannot add or remove tools on a server that already exists by clicking through the app.
That has two practical consequences:
- Build the custom tool before you deploy the server you want it on.
- To change the tools on an existing server, either create a new server with the selection you want, or use the API (see below).
Sources are different: you can add and remove those from the dashboard at any time, and a custom tool immediately searches whatever the server currently indexes.
PATCH /api/mcp/{id}/tools changes the enabled tools on a live server, including
custom ones, and takes effect on the next request with no redeploy. It
authenticates with an account API key, which you can create under Account → API
keys.
Limits
| Limit | Value |
|---|---|
| Custom tools per account | 5 |
| Tools per MCP server | 3 to 10, custom and built-in combined |
| Builds per hour | 15 |
| Parameters per custom tool | 1 to 4 |
Custom tools count toward the 3–10 tools on a server exactly as built-ins do.
What to expect from the result
Set your expectations here honestly, because a custom tool is a retrieval tool and inherits the strengths and limits of one.
It will be noticeably better than a generic search for the subject you described, because it biases every query toward that subject. It returns passages with source URLs and version labels, so the agent can cite what it used, and it appears in your dashboard analytics like any other tool.
It will not invent an answer. If your sources do not cover the question, the tool says so rather than guessing — the same behaviour as every built-in tool. A tool about migrations is only as good as the migration content you indexed.
It may need a second attempt. The build is deterministic for a given description, so if the tool it produced is not what you pictured, rewording the description is the way to change the outcome. Naming the vocabulary your documentation actually uses helps most.
A tool built during the wizard works immediately, but until indexing completes it falls back to a simpler live search of your source pages. Results get better once your sources finish indexing — watch progress on the dashboard.
Related
- Choose tools — picking from the ten built-ins
- Tools reference — what each built-in tool does
- Adding sources — what a custom tool searches
- How indexing works — why results improve over time