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

Even with readOnlyHint and idempotentHint annotations, the description adds important behavioral detail: default limit of 50, maximum of 100, newest-first ordering, and the crucial appeared-vs-edited distinction. This prevents false expectations about what 'what's new' means. No contradiction with annotations exists.

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 front-load the core purpose, then state constraints (limit, ordering), then close with an honest caveat. Every sentence earns its place with no filler or repetition of schema fields.

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 carries the burden of explaining what the agent will get, and it does so for the key dimensions: scope, record categories, ordering, limits, and semantic boundary. It does not specify the exact response shape or behavior when neither slug nor company is provided, but these are minor for a simple change-feed tool.

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 coverage is 100%, so the schema already documents all four parameters. The description reinforces that slug and company correspond to 'one company or one conference' but adds no per-parameter semantics beyond what the schema provides. Baseline 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 query resource—changes since a date for one company or conference—and enumerates exact record types: sponsors, exhibitors, speakers that appeared, and editions that were edited. This clearly differentiates it from sibling tools like company_events or search_conferences by scope and change-tracking angle. The 'Honest limit' caveat further sharpens what the tool does and does not report.

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: use this for one company or conference over a date range, with concrete defaults and limits. It also explicitly warns that sponsor tier changes won't appear, helping agents avoid using it for edit-detection. It does not name sibling alternatives, so it stops short of explicit when-to-use-versus-other-tools guidance.

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