Skip to main content
Glama

search_docs

Read-onlyIdempotent

Search documentation for ranked snippets that answer your query, then follow up with reading full pages.

Instructions

Search the documentation. Returns ranked snippets, not full pages.

Use this first for any question about a documented tool. Follow up with read_doc on the paths it returns.

If a NOTE says one of your words missed, believe it. Matching is OR, so a distinctive word can be outvoted by the common ones next to it — the note names the pages that word really lives on. Read one before you conclude the feature does not exist.

Pass source whenever the question names one product. These doc sets cover the same ground in different words, so an unfiltered search spends slots on the wrong products: a question about Claude Code hooks will also return Cursor's and Codex's. Omit source only to compare products, or when you genuinely do not know which one holds the answer.

A search costs ~500 tokens. Budget for two. The first query is the one you can phrase; the second is the one the docs would. If the rows do not cohere around your question — they name adjacent features, or only things you already knew — do not answer from them. Guess what the docs call the thing and search again. limit which model an org member can select returns org roles and spend limits and warns about nothing; model access control — the docs' own name for it — returns the right page first. You can usually produce that name; the cost of trying is one more search.

Query in English. The indexed docs are English and matching is lexical, so a question in another language finds nothing — translate it to English keywords first ("훅 이벤트 목록" -> "hook events list").

Keyword-style queries work best and filler words are dropped. Symbols are fine here — AGENTS.md, PreToolUse, --flag-name, spec_version all match, because punctuation is treated as a word boundary rather than dropped. Do not reach for grep_docs just because the query contains one. There is no fuzzy matching, so a typo finds nothing.

Indexed sources: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sourceNoOne of: claude-code (Claude Code), codex (OpenAI Codex), cursor (Cursor), opencode (opencode), xai (xAI / Grok)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), description discloses key behaviors: returns ranked snippets, matching is OR, no fuzzy matching, tokens cost ~500, symbols treated as word boundary, and that a note may indicate a word missed. Adds value beyond annotations.

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

Conciseness4/5

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

The description is long but well-structured and front-loaded with purpose and return type. Every section earns its place (usage, behavior, query strategy, sources). Could be slightly more concise, but no wasted sentences.

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?

Given the tool's complexity and presence of output schema, the description is highly complete: covers usage flow, query formulation, handling misses, token costs, source filtering, and cross-references sibling tools. Leaves no significant gaps.

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

Parameters5/5

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

Despite low schema description coverage (33%), the description adds rich meaning: explains query format (English keywords, filler words dropped), limit range (1-8), and source usage (filter by product, omit only to compare or when unsure). Provides context not in 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?

The description states the tool searches documentation and returns ranked snippets (not full pages), clearly distinguishing it from sibling tools like read_doc and grep_docs. It explicitly contrasts with grep_docs, saying not to use grep_docs just because the query contains a symbol.

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?

Provides explicit guidance on when to use this tool first (for documented tools) and when to follow up with read_doc. Gives detailed advice on when to pass source vs omit, and strategies for re-querying when initial results don't cohere. Also notes token cost and recommends budgeting for two searches.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kiyeonjeon21/anydocs'

If you have feedback or need assistance with the MCP directory API, please join our Discord server