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

With no annotations provided, the description carries the full burden. It discloses two important behaviors: geography filters are OR-ed, and there is a credit cost of '1 credit per event plus 1 per person.' These go beyond typical descriptions and help an agent gauge both logical behavior and resource usage. However, it omits other details like whether results are read-only, pagination behavior, and output structure, though the disclosed specifics are valuable.

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 zero waste. The core purpose is front-loaded, and the geographic behavior and credit cost are stated succinctly. Every sentence earns its place, and the structure is easy to parse quickly.

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?

Given 12 parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain the meaning or expected format of most parameters, nor the return structure (beyond events/people/sponsors), nor any default behavior. An agent would need to rely on schema names and external knowledge to call this correctly, which is a significant gap.

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 25%, so the description must compensate. It clarifies that geography filters (regions, countries, us_states) are OR-ed and points to get_taxonomy for allowed values, which helps for some parameters. But it leaves many parameters unexplained (to, from, topics, personas, audiences, industries, include_online, people_per_event), and does not add meaning for them, failing to offset the low schema coverage.

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 clear, specific purpose: 'Describe who you sell to and get upcoming events ranked by fit, each with the matching people on stage and the sponsors.' It distinguishes itself from sibling tools like search_events by focusing on ranking by fit and mentioning get_taxonomy for allowed values, which orients an agent on the tool's unique niche.

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 one explicit usage directive: 'Use get_taxonomy for allowed values,' which tells the agent to fetch valid taxonomy values first. However, it does not contrast icp_match with sibling tools like search_events, icp_infer, or get_event, nor does it state when this tool is preferred over alternatives. This leaves the agent to infer usage context.

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