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, covering the read-only nature. The description adds behavioral context by specifying that it returns 'main content as Markdown' (implying filtering of navigation elements) and mentions pagination with offset for long pages, which goes beyond the annotation coverage.

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, front-loaded with the main action, no wasted words. It efficiently communicates the purpose and the key pagination behavior.

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 two parameters and no output schema, the description is adequate. It specifies the return format (Markdown), the pagination mechanism, and the base URL. It does not explain error handling or what happens for missing pages, but those are not critical for a read operation with read-only annotation.

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 parameters are already documented. The description adds a small clarification that offset is used for pagination of long pages, reinforcing the schema's 'Character offset for long pages'. This adds marginal value 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?

The description states a specific verb 'Fetch' and a specific resource 'a page from https://sitemcp.dev/' and specifies the output as 'main content as Markdown'. It clearly differentiates from sibling tools like get_page_info (likely metadata) and list_pages (listing) by focusing on content retrieval.

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 implies its usage: to fetch page content, but it does not explicitly mention when to use this tool over alternatives such as get_page_info or list_links. No exclusions or conditions are provided, leaving the agent to infer from the description alone.

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, covering the safety and external-access profile. The description adds 'returns matching pages with snippets' as a behavior but does not disclose additional traits like result limits, sorting, or external site behavior beyond what the schema already hints.

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 short sentences with no fluff. The action and target are front-loaded, and the return type is stated clearly. Minor redundancy between 'pages relevant to a query' and 'matching pages' does not detract from overall efficiency.

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 search tool with annotations covering read-only and open-world behavior, the description is sufficient. It states the target site and return content (pages with snippets). It does not fully describe the result format, but the lack of an output schema makes the brief summary acceptable.

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 carries the burden of explaining parameters. It only echoes 'query' indirectly and says nothing about max_results. The schema's constraints (default 5, max 10) offer some clue, but the description adds no meaningful value beyond the parameter names.

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 (search), the target resource (https://sitemcp.dev/), and the outcome (matching pages with snippets). It is easily distinguished from siblings like list_pages, read_page, and get_page_info, all of which serve different purposes.

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' and condition 'relevant to a query' imply this tool is for query-driven discovery. However, there is no explicit guidance on when to use it versus list_pages (broad listing) or read_page (specific retrieval), and no alternatives are named.

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