Skip to main content
Glama
yashisrani
by yashisrani

search_templates

Find documentation templates by keyword, document type, or task description to match the content you need to create.

Instructions

Search for the best documentation template based on keywords, document type, or task description (e.g. 'rest api', 'quick onboarding', 'bug tracking', 'installation', 'changelog', 'how to run docker').

Input Schema

NameRequiredDescriptionDefault
queryYesThe search query or description of the document you want to create

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden and says nothing about behavior: whether it is read-only (implied but unstated), how results are ranked ("best" suggests ranking but no criteria), how many results come back, or whether an empty result is possible. Only the ranking hint is added value.

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?

One front-loaded sentence with the action first and the examples trailing in parentheses. The example list is slightly long but each sample illustrates a different query axis, so it mostly earns its space.

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?

For a one-parameter search tool with no output schema, an agent still lacks return-shape and ranking expectations; the description covers intent but not what comes back or how to interpret ordering. Adequate but with clear gaps.

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

Parameters4/5

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

Schema coverage is 100% for the single required `query` parameter, so the baseline is already 3. The description goes beyond the schema by showing the kinds of strings that work well ('rest api', 'quick onboarding', 'bug tracking'), which genuinely guides query construction.

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?

States a specific verb and resource ("Search for the best documentation template") and enumerates the axes of search (keywords, document type, task description). It is clearly distinguished from get_template/list_templates by the word "Search", though it never names a sibling to route away from.

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?

The example queries imply when to use it — when you have a fuzzy description of the doc you want — but there is no explicit statement of when to prefer list_templates or get_template instead, nor any prerequisite/order guidance.

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