Skip to main content
Glama

Search the docs

search_docs
Read-only

Full-text search over the FrontMCP docs, by section: page titles, section headings and prose. Returns up to limit sections, best first, each with its page, heading, path (with the #anchor) and the start of its text. Read one with get_page. For an API, option or error code by name, lookup_api is more precise.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many sections to return.
queryYesWords to look for, like "rate limit", "deploy to cloudflare" or "elicit".
sectionNoOnly this part of the docs. Choose blog explicitly for dated articles.
versionNoA documented FrontMCP version, like "1.9.4", or a minor, like "1.9", for its newest patch. Pass the version resolve_version found for the project. Defaults to the version this endpoint serves.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / section / description
      Previous value: -"Only this part of the docs."New value: +"Only this part of the docs. Choose blog explicitly for dated articles."
    • changedInput schema / properties / section / enum
      Previous value: -[
      -  "learn",
      -  "reference",
      -  "examples",
      -  "compare"
      -]New value: +[
      +  "learn",
      +  "reference",
      +  "examples",
      +  "compare",
      +  "blog"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / version / description
      Previous value: -"A documented FrontMCP version, like \"1.9.4\", or a minor, like \"1.9\", for its newest patch. Defaults to the version this endpoint serves."New value: +"A documented FrontMCP version, like \"1.9.4\", or a minor, like \"1.9\", for its newest patch. Pass the version resolve_version found for the project. Defaults to the version this endpoint serves."
  3. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=true, while the description adds significant behavior: best-first ranking, a limit cap, and per-result fields including page, heading, anchored path, and text snippet. It does not cover error or empty-result behavior, so it is strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the search purpose, followed by return behavior and alternative-tool routing. There is no filler or redundant text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter read-only search with full schema coverage and no output schema, the description supplies the missing return-shape details and sibling routing. Nothing critical to correct invocation is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so query, section, version, and limit semantics are already fully documented. The description mainly reinforces the limit behavior and section-oriented search scope, adding little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full-text search over the FrontMCP docs') and scopes the search to page titles, section headings, and prose. It distinguishes from get_page and lookup_api by naming their use cases, so an agent can select it without opening sibling schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes follow-up reading to get_page and named API/option/error lookups to lookup_api as a more precise alternative. This gives clear when-to-use and alternative conditions for the main sibling paths.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources