Tools reference

Each MCP server can include 3 to 10 tools. Tools determine how AI agents use the right context from your sources.

Audience	MCP creators, developers, and AI workflow owners
Prerequisites	A planned MCP server and selected source content

Tool	Description
search_docs	Full-text search across all indexed sources. Returns the most relevant passages.
query_source	Query a specific source URL for targeted results.
get_code_examples	Extract code snippets and examples from your sources.
summarize_content	Summarize the content of a specific source page.
find_api_reference	Find API endpoints, parameters, and documentation.
get_changelog	Read a changelog or release-notes page, newest entry first.
search_issues	Search for known issues, bugs, and their solutions.
get_quickstart	Get setup guides, installation steps, and quickstart content.
extract_schema	Extract type definitions, data models, and schemas.
ask_question	Natural language Q&A across all indexed sources.

Asking what is new

If one of your sources is a changelog or release-notes page, questions like "what is new", "what changed recently", or "what shipped this week" are answered from that page directly, with the entries in the order they were published rather than in order of how well they match the question. The newest entry comes first, which is what makes a question about a specific week answerable.

This applies to ask_question and search_docs as well as to get_changelog, so an agent that does not pick the changelog tool still reaches the right page.

get_changelog takes an optional page to read, which matters when one server covers more than one product and has indexed a changelog for each. Any part of the URL is enough:

{
  "name": "get_changelog",
  "arguments": { "source_url": "docs.example.com/sdk" }
}

Pass version alongside it to keep only the entries naming that release. If your sources contain no changelog page, get_changelog falls back to searching them.

Reading one page

query_source and summarize_content take a source_url and read it from your indexed content rather than fetching the page again. You can pass any URL that appears in a citation, including a section anchor and, for a repository source, a file URL with or without its line range:

{
  "name": "query_source",
  "arguments": {
    "source_url": "https://docs.example.com/guides/auth",
    "question": "which scopes are required"
  }
}

With a question on query_source or a focus on summarize_content, the parts of that page most relevant to it come first, so a long page does not return its introduction when you asked about something further down. Without one, the page is returned in its own order.

Because these read your index, they work for private sources and uploaded files, and they return what was indexed rather than whatever the page shows today. Re-run indexing if a page has changed since.

When your sources do not cover a question

If nothing in your indexed content closely matches what was asked, the response says so before the passages, and the passages are labelled as the nearest available rather than as the answer. Agents are asked to report that instead of inferring an answer from unrelated text.

A second, narrower notice covers the harder case: your content is clearly about the subject, but does not state the specific thing that was asked. A question about retention policy against documentation that describes uploads thoroughly and says nothing about deleting them will retrieve passages that look right and are not the answer. Where the retrieval stage can tell, the response says the area is covered while the specific point may not be, and asks the agent to check the passages against the question before relying on them.

This is worth reading as a signal about your sources: a question your team asks often that keeps coming back this way is usually a gap in the documentation rather than a problem with the question. The Content gaps view in Action and Predictive analytics collects them.

How passages are chosen

Every tool here searches the same index and shares one ranking path, so a question that works through ask_question ranks the same way through search_docs. Keyword and meaning-based matching run together, a relevance model reorders the candidates when the leading scores are close, your current documentation is preferred over archived versions, and a weak match is disclosed. How it works covers each stage.

Two consequences are worth knowing when you pick tools:

• A tool with a narrower purpose, such as find_api_reference, expresses that purpose as a ranking preference rather than by adding words to your query. Searching for createUser searches for createUser, and the reference-shaped passages are preferred among the matches.
• query_source and summarize_content rank passages within the page you name, so the page argument decides the answer rather than merely filtering it.

Choosing the right tools

See Choosing Tools for recommendations based on your use case.

Custom tools

The ten tools above are available on every server. You can also describe a tool in your own words and have MCP Studio build it against your sources — useful when a recurring question is more specific than any built-in targets. A custom tool behaves like the built-ins in every respect: it appears in the agent's tool list, returns passages with citations, and is logged in your dashboard. It counts toward the same 3 to 10 selection.

See Build your own tool for what they can and cannot do.

How tools are called

When an AI agent connects to your MCP server, it sees the tools you selected in its tool list. During a conversation, the agent decides which tool to call based on the user's question. The tool executes a search against your indexed sources and returns the relevant content.

Each tool call is logged in your Dashboard with the query, tool name, sources referenced, response time, and status.