Skip to main content
Glama

Search the docs

search_docs
Read-onlyIdempotent

Search Anahita documentation by keywords to find relevant sections first, each with its page, section, and a preview line. Filter by Services or Web docs and set result limits.

Instructions

Searches Anahita's docs by words and gives the best sections first, each with the page and section to read and a line of it.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many sections, 8 if left out
queryYesWords to look for, such as "custom feed weights" or "federation opt-in"
sourceNoOnly the docs of Anahita Services ("services") or Anahita Web ("web")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

The annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context: results are ranked by relevance ("best sections first") and each hit carries a page, a section, and a snippet line — enough to know the response shape without an output schema.

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?

A single front-loaded sentence that leads with the verb and resource, then immediately describes the return shape. No filler, no restatement of the title.

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

Completeness3/5

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

The three parameters are fully documented in the schema and the description covers the response shape, which is enough to invoke it correctly. What is missing is routing context — the sibling set includes list_docs and read_doc, and the description never explains when a search is better than browsing or fetching a known page, nor what happens when there are no matches.

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, limit, and source are fully self-documenting; baseline 3 applies. The description adds only that matching is on "words" — it does not clarify ranking interaction with limit or what source filtering does beyond the enum descriptions.

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

Purpose4/5

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

"Searches Anahita's docs by words" gives a specific verb and resource, and the clause about returning the best sections first with page/section/snippet tells the agent what comes back. It is distinct from list_docs and read_doc by implication of ranked keyword retrieval, though it never names those siblings explicitly.

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

Usage Guidelines3/5

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

Usage is only implied: the word "Searches" and "by words" signal keyword lookup rather than browsing or full reads, which the schema's query examples reinforce. There is no explicit statement of when to prefer this over list_docs or read_doc, and no exclusions.

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