Customize the MCP tools
By default, Kapa exposes the hosted MCP server's search tool as search_<PRODUCT_NAME>_knowledge_sources and the documents tool as get_<PRODUCT_NAME>_knowledge_documents, each with a description written to work well across clients. These defaults are a good fit for most projects, so change a tool name or description only when you have a concrete reason to (see When customizing helps); otherwise, leave them as is. You can change both in the Tools section of your MCP integration settings, where the current default descriptions are also shown. Before you do, it helps to understand what the model actually sees.
How an agent sees the tools
When a client connects, it loads each tool's name, description, and input schema into the model's context window, alongside every other tool available in that client or agent. During generation, the model relies on that text, and only that text, to decide whether to call your tools, which tool to call, and what arguments to pass.
The names and descriptions therefore determine whether your knowledge base is used at all.
When customizing helps
- The tools search something other than your product documentation. The default descriptions are written for the most common setup, indexing the knowledge sources that document your product, so they are framed around your product. If your server instead indexes a different collection, for example internal go-to-market material or the documentation for your engineering team's upstream dependencies, that framing no longer describes what the tools search. Rename the tools and rewrite the descriptions so they tell the client what the collection actually contains.
- Your users and agent use different vocabulary than the default. If people refer to your documentation by a specific name, or your product has terms the defaults do not mention, adding those terms to the descriptions improves the chance the model reaches for the tools on a relevant question.
- You want to frame a tool's job differently. By default the search tool description tells the model to use the tool for questions about your product. You might want a different policy, for example calling it regardless of user intent, or using it only as a last resort. The description is where you set that expectation. This behavior is usually split between the tool description and the surrounding instructions, whether that is the system prompt in an agent you build or a skill in a client like Claude Code, but the tool description often carries part of it.
When you do change a description, keep it concise. It is sent on every request, so a long description spends tokens and can dilute the signal that makes the model choose the tool.
Changing a description is safe at any time: connected clients pick it up on their next tool refresh. Changing a tool name is a breaking change for clients that already cached the old name. Agents will not find the tool until they reconnect and rediscover tools, and any tool name hard-coded in your code or _meta calls must be updated. Treat a name change like an API change that you roll out deliberately. The same logic applies to the optional documents tool: enabling it carries no risk, but disabling it once agents rely on it is a breaking change.