sitemap_lastmod

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

With no annotations, the description carries the full disclosure burden. It does transparently reveal the core decision logic — content is hashed, compared to the stored hash, and the date advances only on real change — which is the tool's essential behavioral trait. But it omits the return value format, first-seen behavior when previous_hash is null, and failure modes for malformed strip_patterns.

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?

Three sentences with the purpose front-loaded in the first, the mechanism in the second, and a brief rationale in the third that explains why the behavior matters. No filler; every sentence 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?

The tool has 6 parameters, no annotations, and no output schema, so the description must disclose the return contract — but it never states what the function returns (a date string? a boolean? a full update?) or how it handles first-run cases (null previous_hash / null previous_lastmod). These are essential for an agent to invoke it correctly.

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%, putting the baseline at 3. The description's narrative adds an interaction model beyond the individual schema entries: body is hashed after stripping, compared against previous_hash, and previous_lastmod advances to today only on genuine change. This workflow-level meaning connects the parameters in a way the schema alone does not.

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-resource pair — 'Decide a sitemap lastmod date honestly' — and explains the mechanism (hash content, compare with stored hash, move the date only on genuine change). This clearly differentiates the tool from sibling check_* tools and content_hash: the siblings inspect content or compute hashes, while this one decides a date.

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 use case is implied — computing honest lastmod dates during sitemap builds — and the anti-pattern ('Stamping today's date on every URL every build') is described well. However, the description never explicitly names an alternative or states when not to use this tool (e.g., when only a raw hash is needed, use content_hash), leaving the routing guidance implicit.

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