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

Beyond the read-only and non-destructive annotations, the description discloses a non-obvious behavior: matching happens against sitemap URL paths, not page content, and results should be verified via Fetch. This adds meaningful behavioral context without contradicting the annotations.

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?

Two concise sentences, front-loaded with the primary purpose and immediately clarifying the non-full-text constraint. The second sentence adds actionable follow-up guidance, and every phrase earns its place.

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?

For a simple one-parameter, read-only tool with no output schema, the description covers what is searched, what is not searched, and the recommended verification step. It does not describe the result shape or pagination, but those are lower risk given the open-world and read-only annotations.

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 only defines a bare 'query' string, so the description must supply semantics. It does: query terms are words matched against sitemap URL paths, not full-text. It stops short of specifying exact syntax (single vs. multiple words, case sensitivity, substring behavior), but for one required parameter this is adequate.

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 opens with a specific verb and resource ('Find public SLGP pages') and defines the exact matching scope ('words in sitemap URL paths'), explicitly ruling out full-text search. This distinguishes it from a generic search tool and from sibling tools like list_public_pages, which likely list pages without path-word filtering.

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 gives clear context for when to use search: when the goal is to locate public pages by words in URL paths, not full-text content. It also instructs to use Fetch to verify titles and content, which is an explicit workflow cue, though it does not enumerate alternatives like list_public_pages for unfiltered listing.

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