搜索接口

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

With no annotations, the description carries the full burden. It discloses matching modes (exact, wildcard, fuzzy, path segment) with concrete examples like '/api/users/*' and 'daren/influencer', which is substantive behavioral information beyond the schema. However, it does not mention case sensitivity, pagination, error behavior, or result format, leaving some gaps.

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

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

The description is well-structured with bullets and front-loaded purpose, making it easy to scan. It is slightly longer than minimal but every section (use cases, matching modes) adds necessary guidance. No redundant sentences found.

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

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

The tool is simple (1 parameter, no output schema, no annotations), but the description provides solid use-case triggers and matching behavior. However, it does not describe what the tool returns or its limitations (e.g., no results, ordering, pagination), and it fails to distinguish itself from smart_search_api. Given no output schema, some return-value context would complete the picture.

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

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

The schema already covers the single parameter 'pattern' with a clear description, and schema coverage is 100%. The tool description adds extra value by enumerating specific matching modes and examples, enriching the meaning of the parameter beyond the schema's generic definition.

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

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

The description clearly states the tool's function: searching APIs by URL pattern, and calls itself the preferred tool for finding APIs. It distinguishes from list-by-tag/folder sibling tools by focusing on URL patterns, but does not explicitly contrast with smart_search_api, so sibling differentiation is slightly incomplete.

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

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

The description provides explicit use cases: automatically call when the user mentions an API path/URL, when asking about a feature's API, and when needing to know a module's APIs. This gives clear context on when to use, but it does not mention exclusions or alternatives like smart_search_api, so it lacks explicit comparison with overlapping siblings.

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