Site MCP

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

Annotations already mark this as read-only and open-world, and the description adds meaningful behavioral detail: it lists the exact metadata returned and clarifies that full text is intentionally omitted. This goes beyond what the annotations alone convey.

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 sentences with no filler: the first defines scope and content, the second states the use case. Key distinctions like 'without its full text' are front-loaded.

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 read-only metadata tool with one well-documented parameter, the description is complete: it enumerates return fields, clarifies what is excluded, and provides a clear decision-oriented use case. No output schema is present, but the listed fields fill that gap adequately.

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 documents the single parameter fully, including the path format and accepted URL form. The description adds nothing beyond the domain context (sitemcp.dev), which is already present in the tool name and schema, so the baseline of 3 is appropriate.

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 states a specific action and resource: it returns metadata for one page on sitemcp.dev. It explicitly excludes full text, which distinguishes it from read_page and list_pages without requiring the schema to be opened.

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 a clear usage context: decide whether a page is worth reading. It implies rather than names alternatives like read_page for full content, so it lacks an explicit when-not-to-use statement but is still practically useful.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety and dynamic-data profile. The description adds the concrete informational scope of the read, but does not disclose additional behavioral details such as freshness, rate limits, or output format.

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?

A single sentence that front-loads the purpose, lists the returned content categories, and ends with a clear directive. There is no filler or repetition.

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 zero-parameter read-only orientation tool, the description fully covers what the agent will receive and when to call it. The annotations cover the open-world and read-only semantics, so nothing essential is missing.

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?

This tool accepts zero parameters, so parameter semantics are trivially satisfied. The description appropriately avoids inventing parameter-related details where none are needed.

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 identifies a site-level orientation resource and enumerates the specific data returned: title, description, language, sitemaps, robots.txt, pages discovered, and search-index status. This scope distinguishes it from the page-, link-, and search-oriented sibling tools.

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 instruction 'Call this first' provides explicit usage context for when to invoke the tool, establishing it as the initial orientation step before lower-level tools. It does not name alternatives or exclusions, but the site-level framing makes the intended starting position clear.

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

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

Annotations already declare readOnlyHint=true removal of the safety burden in that regard. The description adds useful behavioral context beyond the schema: it returns link text and an internal/external classification, and it is positioned as a navigation aid rather than a raw scraper.

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 tight sentences with no filler. The first sentence front-loads what the tool returns, and the second gives concrete usage guidance. Every phrase adds value.

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 read-only tool with optional parameters, the description is complete: it names the page scope, the returned fields, and the intended use case. Even without an output schema, an agent knows what to expect and how to use the two parameters.

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 describes path and gives scope an enum with a default, so the description does not need to re-explain them. With 50% schema coverage, the description only mildly reinforces the 'one page' idea and does not add direct parameter detail beyond what the schema provides.

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?

States the exact resource (one page on sitemcp.dev) and the precise output: every link with its text and whether it stays on the site. This clearly distinguishes it from siblings like list_pages, which would list pages rather than links.

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?

Explicitly says to use it for navigating the site instead of guessing URLs, which gives a clear positive use case. It does not enumerate when to prefer siblings like read_page or search_site, but the instruction is practical and unambiguous.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context about the source ('from its sitemap, or links on the homepage'), but does not disclose other behavioral traits such as pagination, ordering, or whether results may be incomplete or dynamic.

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 a single front-loaded sentence with no filler. The parenthetical about the data source is valuable and earns its place, and the description remains appropriately compact for a simple tool.

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 low-complexity, optional-parameter tool with read-only and open-world annotations, the description is mostly complete: it states the action, resource, and source. It lacks usage guidance relative to siblings and an explicit statement of return format, but the phrase 'List page URLs' reasonably covers the return value.

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?

Schema description coverage is only 50%: filter has a schema description, but limit has only numeric constraints. The description adds no meaning for either parameter, so it fails to compensate for the undocumented limit parameter or enhance understanding of how filter interacts with the URL list.

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 identifies the action ('List') and resource ('page URLs on https://sitemcp.dev/'), which is specific and useful. However, it does not explicitly differentiate from the sibling tool list_links; the reader must infer that 'page URLs' and the sitemap/homepage source distinguish it.

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 no guidance on when to use this tool versus alternatives like list_links or search_site. It states a data source, but no conditions, exclusions, or preferred scenarios are given, so an agent receives no routing help.

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

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds real context: the fetch is live rather than cached, the response includes read time and the page's own last-changed time, and long pages paginate. It stops short of saying how to detect that more content remains or any rate/error behavior.

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?

A single sentence, front-loaded with the core action and resource, that also folds in return shape and pagination without any filler. Every clause carries information.

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?

With no output schema, the description responsibly covers return values (Markdown content, read timestamp, last-changed timestamp) and the pagination mechanism. It is slightly incomplete on how an agent knows pagination is exhausted or what offset to resume from.

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?

Schema description coverage is 100%, so both path and offset are already documented in structured form, which sets the baseline at 3. The description adds only a light rationale for offset (long pages are paginated), without syntax or ordering details beyond the schema.

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?

States a specific verb (fetch) and resource (a page from https://sitemcp.dev/), plus the output form (main content as Markdown). It implicitly separates itself from get_page_info by emphasizing content rather than metadata, but it never names or contrasts with its siblings explicitly.

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?

Usage is implied by the content-vs-info framing, and the pagination note hints at how to read long pages, but there is no explicit when-to-use guidance or named alternative (e.g., use get_page_info for metadata, search_site for discovery). Nothing is misleading, just inferred.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real value beyond them by describing the return content: matching pages with snippets and two freshness timestamps ('when it was read' and 'when the page says it last changed'), which is behaviorally meaningful for judging result staleness.

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 tightly written sentences with zero filler: the first covers action and source, the second covers the return shape. Information is front-loaded and every clause 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?

With no output schema, the description does a decent job describing results, and annotations cover safety. However, for a 2-parameter tool it omits 'max_results' entirely and gives no result-limit or pagination behavior, leaving a gap an agent would need to fill by reading the schema.

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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does not. 'query' is referenced only obliquely ('relevant to a query') with no syntax, matching, or required/non-empty semantics, and 'max_results' (default 5, max 10) is never mentioned at all.

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?

States a specific verb and resource ('Search https://sitemcp.dev/ for pages') plus the key qualifier 'relevant to a query.' This clearly distinguishes it from read_page and list_pages in spirit, though it never names or contrasts 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.

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

The verb 'search' implies when to use it (retrieval by keyword rather than enumeration), but there is no explicit when-to-use guidance and no mention of alternatives like list_pages for browsing or read_page for fetching a known page. Usage is inferable but not stated.

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