Messe Atlas

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

Annotations cover safety (readOnly/idempotent/non-destructive), but the description adds substantial context beyond them: determinism ('no AI'), the account/rate-limit regime per tier, the 24-hour SVG preview URL, the returned fields, and hard input bounds (convex polygons, ≤2,000 objects, ≤160,000 m²). This is rich behavioral disclosure well past the annotation bar.

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?

Front-loads the account requirement then the rule list, the coordinate contract, the plan shape, the return payload and the limits in a logical order. Dense and mostly every sentence earns its place, though the plan-shape prose partially duplicates the schema and could be trimmed.

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 still names what is returned (ok, per-rule results with rule/value/limit/source, summary, limits_status, preview_url, disclaimer), states the input limits, the coordinate system, and the quota behavior. An agent has everything needed to call and interpret this 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 coverage is 100% for the top-level params, so baseline is 3, but the description meaningfully supplements the nested shapes it doesn't detail: coordinate origin (hall's north-west corner), axis directions (x east, y south), exit kind values, exit endpoint pairs, and door_side placement. The full L2 plan alternative is also disambiguated. Slightly short of 5 only because some of this detail could be pushed into 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 and resource — checking an exhibition floor plan against published safety/layout limits — and enumerates exactly which rules are evaluated (stand overlaps, gangways, travel distance, exit width, etc.). No sibling tool does anything similar, so the agent can distinguish it immediately.

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?

Explains that a free Messe Atlas account is required and sign-in is prompted, and points to get_venue_spaces as the source of space_id. Monthly quota tiers (3/30/unlimited) and the note that invalid plans are not counted further inform the decision to call. No explicit when-not-to-use or alternative routing is given, but no sibling alternative exists.

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 cover the safety profile (readOnly, idempotent, non-destructive), so the description's contribution is the auth requirement and the sign-in friction, which annotations cannot express, plus what is actually counted in each mode. It does not mention rate limits, caching, or ordering of the returned ranking.

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, no filler. The prerequisite is stated first, then the two output modes are contrasted in parallel 'Without X / With X' form that an agent can parse at a glance.

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?

There is no output schema, so the description shoulders return-value disclosure and does it: it names the six counted entity types and the top-20 cap. With one optional parameter and those return semantics covered, nothing needed to invoke it correctly 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?

Schema coverage is 100% and the ISO-3166 alpha-2 format is documented there, so the schema carries format duty. The description adds the piece the schema cannot: the semantic consequence of omitting the optional parameter entirely. Baseline 3 is exceeded because the with/without distinction is genuinely behavioral meaning, not restatement.

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 concrete resource (country totals) and spells out two distinct behaviors: top 20 countries by events when `country` is omitted, and per-country counts across six entity types when it is supplied. That two-mode framing lets an agent tell it apart from generic siblings like search_events or list_leaderboards without opening the schema.

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?

It gives explicit selection guidance for the one real decision here — omit `country` for a global top-20 ranking, supply it for a single-country breakdown — plus the prerequisite of a free Messe Atlas account. It stops short of naming any alternative sibling when a different tool would be better.

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 cover safety (readOnly, idempotent, non-destructive), and the description adds substantial extra context: a plan gating requirement, newest-first ordering, a 20-per-page limit, and the history_truncated caveat for very large histories. These are exactly the behavioral traits an agent needs and none are derivable from the structured fields.

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?

Front-loads the gating constraint ('Requires a Pro plan'), then the return shape and pagination, with no filler sentences. It is dense but every clause earns its place; the long enumerated field list is justified because no output schema exists.

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 return-value burden and does so fully: it lists returned fields (event, year, dates, city, country, tier, booths, as_of), explains ordering, page size, cursor pagination, and the truncation flag. An agent has everything needed to call and interpret this 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 description coverage is 100%, so role, cursor, company, to_year and from_year are already fully documented in the schema. The description echoes the role/year filtering and cursor usage but adds no syntax, format, or edge-case detail beyond what the schema provides, so baseline 3 applies.

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+resource: 'Every edition one company exhibited at or sponsored.' An agent can immediately distinguish this per-company cross-edition history from the per-edition sibling list_edition_exhibitors, and the field list clarifies what it returns.

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?

Gives a clear prerequisite ('Requires a Pro plan') and the pagination flow ('pass cursor from the previous answer for the next page'), plus filter options by role and year range. It does not explicitly name an alternative sibling or state when-not to use it, so it falls short of a 5.

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 show a non-read-only, non-destructive write, and the description adds real detail beyond that: a CSV is written to workspace exports, the returned link works for 24 hours without signing in, rows count against the plan's daily export allowance, and per-source caps (1,000/part, 200, 1,000, 500/part) are disclosed. Quota and expiry behavior go well past what the annotations 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?

Single front-loaded paragraph that leads with the plan gate and output behavior before the source catalog. Density is high and nothing reads as filler, though the long run-on source enumeration is harder to scan than a short list.

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 return-value burden and does so (download link, 24h validity, remaining allowance). Combined with prerequisites, quotas, and pagination semantics, an agent has everything needed to invoke this correctly for a 4-parameter, nested-object 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 baseline is 3, but the description adds genuine meaning: it explains cursor round-tripping ('pass next_cursor back as cursor') for the paginated sources, defines what each `source` value returns, and ties `prospects` to the find_prospects argument shape. Meaningful value on top of an already well-documented 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 and resource ('Export a list as CSV') and then enumerates the four exact sources (edition_exhibitors, edition_sponsors, prospects, reveals), which maps directly to the `source` enum. An agent can distinguish this from siblings like list_edition_exhibitors or find_prospects without opening any schema.

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?

Prerequisites are explicit (Pro plan, 'atlas.reveal' permission, personal connection) and each source is described with its condition (prospects mirrors find_prospects args; reveals is Team plan and up and unavailable when contacts are kept out of AI conversations). It does not, however, explicitly tell the agent when to export vs. use the sibling list/read tools that return the same data.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real operational context beyond them: the Pro-plan requirement, fixed 20-per-page pagination, the result ordering (most editions attended, then most recent), the too_broad refusal for oversized editions, and the default of an event's latest 5 past editions.

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?

Front-loaded with the Pro-plan requirement and the core set logic, and every clause (defaults, caps, ordering, returns) carries information. It is dense and relies heavily on parentheticals and dashes, which slightly hurts scannability but not correctness.

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 still enumerates the returned fields (company, hits, last edition and url, total_about, editions_used with as_of) and covers plan gating, pagination, defaults, limits, and failure modes. Nothing an agent needs to call this correctly appears 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: that `country` is HQ-based, that `event` without `years` defaults to its latest 5 past editions, and that each side is capped at 5 editions with oversized ones refused. It stops short of documenting the cursor reuse constraint or the role enum values beyond what the schema already states.

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 ('Prospect lists: companies at any `include` edition and at none of the `exclude` editions'), and the set-difference semantics ('at A or B, not at C') separate it cleanly from siblings like search_companies or list_edition_exhibitors without opening either schema.

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?

Gives clear context for when this tool applies (cross-edition attendance prospecting) and states the gating prerequisite ('Requires a Pro plan'), plus the too_broad refusal condition. It never explicitly names an alternative tool or a when-not-to-use case, so routing still requires inference.

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?

Goes well beyond the annotations by disclosing the free-account auth requirement, the two-state screening semantics (match=likely vs check with reasons, plus not_matched reasons), the returned fields (url, apply_url, as_of, stale), and an explicit 'not advice' caveat. This is rich context the structured fields do not provide.

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?

Front-loads the auth requirement, then screening logic, then return values, then disclaimer. Dense but each sentence carries real information; only mildly long.

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 steps in to describe return structure (benefits, amounts, url, apply_url, as_of, stale) and match states. Combined with the auth note, an agent has everything needed to call and interpret it.

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 every parameter is already documented in the schema. The description only loosely echoes country scoping and event types, adding little syntax or format meaning beyond what the schema supplies. Baseline 3 applies.

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 (find) and resource (subsidies / convention-bureau and tourism-board support schemes) scoped to MICE event types. No sibling tool covers subsidies, and the description makes the domain and output framing unmistakable.

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?

Clearly frames the context (an exhibition, conference, meeting or incentive, optionally in one country) and flags the sign-in prerequisite. It doesn't name a competing tool or state when-not to use it, but there is no overlapping sibling to route against.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new operational context – the free-account/sign-in requirement – which the agent needs before calling. It stops short of describing pagination or rate limits, but for a single-record read that is minor.

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, no filler, and the returned-field list is compact. Minor deduction because the auth prerequisite is placed before the purpose rather than leading with what the tool does.

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?

There is no output schema, so the description's field enumeration usefully compensates by telling the agent what comes back. The auth note covers the main operational surprise; nothing critical is missing for a single-record lookup.

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% and the single parameter is documented in the schema ('Slug or uuid, as returned by the search tools'). The description merely repeats 'slug or uuid' without adding format, resolution order, or error behavior, so baseline 3 applies.

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+resource ('One company by slug or uuid') and enumerates what is returned (description, tags, parent, subsidiaries, sponsorships, total editions, last seen date). It does not explicitly name search_companies as the way to obtain the slug/uuid, so sibling differentiation is left implicit.

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 an authentication prerequisite ('Requires a free Messe Atlas account (sign in when prompted)') but offers no explicit when-to-use guidance or steering away from search_companies or get_organizer. Usage is only implied by the requirement of a slug/uuid.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that by disclosing the breadth of the returned payload (nested organizer/venue/tags and per-edition counts), which matters because there is no output schema. It does not mention errors (e.g., not-found on a bad slug) or auth needs.

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 front-loaded sentence with the resource first and the payload enumeration after; the trailing cross-tool pointer is separated cleanly. Slightly list-dense, but every clause carries information an agent needs.

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 and only one required param, the description carries return-shape information and does it well by naming the included sub-objects and the per-edition counts. It stops short of stating error behavior or whether the response is a single object, but it is adequate for a simple id lookup.

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% and the single parameter already documents itself as 'Slug or uuid, as returned by the search tools.' The description only restates slug-or-uuid acceptance and adds no format or source detail beyond the schema, so the baseline 3 applies.

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 resource ('One event series') retrieved by a specific key ('by slug or uuid') and enumerates the payload: organizer, venue, tags, editions with counts. That makes the id-lookup nature clear, distinct in practice from search_events / upcoming_events, though neither sibling is named 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?

It gives one concrete usage path ('Use an edition id with list_edition_exhibitors') but never says when to call this vs. search_events or upcoming_events, nor that it accepts an already-known slug/uuid. Usage is only implied by the 'by slug or uuid' framing.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the genuinely new behavioral fact that a free Messe Atlas account is required and a sign-in prompt may appear — useful auth context an annotation cannot express.

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 padding and no repetition of the title. The auth prerequisite leads and the payload description follows, which is a reasonable ordering though slightly less front-loaded on 'what it does' than ideal.

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 one-parameter read with no output schema, the description compensates by summarizing the return shape (organizer description, parent company, top event series) and the auth requirement. With annotations covering safety and the schema covering the identifier, an agent has enough to call 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 coverage is 100% and the single parameter already documents 'Slug or uuid, as returned by the search tools.' The description's 'by slug or uuid' repeats the schema rather than adding format, casing, or lookup guidance, so the baseline 3 applies.

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+resource ('One organizer by slug or uuid') and names the fields the single result carries (description, parent company, top event series), which separates it from list/search siblings like search_organizers. It stops short of explicitly contrasting itself with the other get_* tools, but the resource noun does the disambiguating work.

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 — fetch one organizer by identifier — and the account/sign-in prerequisite is stated. There is no explicit when-to-use guidance, no mention that search_organizers is the way to obtain the slug/uuid for this call, and no exclusion of alternatives.

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 cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower. The description adds genuinely useful context beyond them: a free Messe Atlas account is required and sign-in is prompted on demand, plus it discloses what comes back (bio and the session list with event/edition/year/title).

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, and the payload contents are front-loaded into the same sentence as the lookup. The auth caveat leads, which is slightly less important than the purpose but still compact enough to be efficient.

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 steps in to name the returned fields (bio plus sessions with event, edition, year, title), and the auth prerequisite is disclosed. For a one-parameter read tool this is close to complete, with only explicit sibling routing 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?

Schema description coverage is 100% and the single parameter is already documented as the slug or uuid returned by the search tools. The description's 'by slug or uuid' restates the schema rather than adding format or validation detail, so baseline 3 applies.

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 ('One speaker by slug or uuid') and enumerates the returned payload (bio, sessions spoken at with event/edition/year/title), which clearly separates it from the search_speakers sibling. It does not name the sibling explicitly, so it stops short of a 5.

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 a single-entity lookup keyed by an identifier obtained elsewhere ('by slug or uuid'), and the auth prerequisite is stated. However it never explicitly says when to use this versus search_speakers or list_edition_sponsors, leaving routing to inference.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds two things the annotations do not: an authentication prerequisite ('free Messe Atlas account, sign in when prompted') and the truncation/scope behavior of the return ('upcoming editions (next 20)').

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, no padding, and the auth prerequisite is front-loaded before the content description. The second sentence is dense but readable; slightly more structure could separate the identifier form from the returned 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 describing returns and does so at a useful level (city, website, hosted event series, next 20 upcoming editions) while also flagging the auth requirement. It is complete enough to call correctly, though it says nothing about behavior for an unknown slug/uuid or rate limits.

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% and there is a single parameter, so the schema already documents id_or_slug as a slug or uuid. The description's 'by slug or uuid' merely restates that and adds no format, casing, or resolution detail beyond it.

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 ('One venue by slug or uuid') and enumerates the payload scope (city, website, event series, next 20 editions), so it is clearly distinct from search_venues and get_venue_spaces. It does not name those siblings explicitly, which keeps it short of a 5.

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 only implied: 'one venue by slug or uuid' tells the agent this is a single-entity lookup rather than a search, and the account requirement sets a precondition. There is no explicit statement of when to prefer this over search_venues or get_venue_spaces, nor any exclusion guidance.

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 establish read-only, idempotent, non-destructive behavior, and the description goes well beyond them: sign-in/auth requirement, the 180-day `stale` convention, the meaning of a null figure ('not published'), the fact that drawings are not served, and the role of `geometry_status`. This is exactly the kind of operational context an agent needs before calling.

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?

Everything is packed into one dense paragraph, front-loaded with the auth prerequisite and then the returned field inventory. There is little waste, though the very long field enumeration makes the sentence harder to scan than a short lead plus a list would be.

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 entire return-value burden, and it does so: it enumerates the hall/room attributes, documents the per-row `source_url` and `as_of` staleness semantics, and clarifies what a null figure means. For a one-parameter, read-only tool this is essentially complete.

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% and the single `venue` parameter is fully documented in the schema (slug or uuid, from search_venues/get_venue). The description repeats that provenance ('slug or uuid from search_venues') but adds no format or constraint detail beyond it, so the schema is doing the work. Baseline 3 applies.

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 names the exact resource and scope: 'the halls and rooms of one venue', with a parenthetical pointing at the sibling that produces the slug/uuid (search_venues). That cleanly separates it from venue-level tools like get_venue. It stops short of explicitly contrasting itself with search_venue_spaces, so sibling differentiation is implied rather than stated.

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?

It tells the agent the input must come from search_venues/get_venue and that an account sign-in is required, which is useful pre-call context. It never states when to choose this tool over search_venue_spaces (single venue vs. cross-venue search), so the selection rule is left to inference.

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 indicate read-only, non-destructive, idempotent behavior, so the bar is lowered. The description adds meaningful context beyond annotations: the account requirement, page size, and free-tier row limits. It does not mention rate limits or timeout behavior, but this is a substantial addition.

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 compact, front-loading the account requirement and then the core behavior and return fields. Every sentence adds information, though the account requirement could be seen as slightly buried before the main purpose.

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 the tool has no output schema and schema coverage is 100%, the description is complete enough: it covers auth needs, pagination, return fields, and free-tier limits. It does not discuss error handling or edge cases (e.g., invalid edition_id), but those are minor.

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 both parameters fully; the description adds no new parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting. The mention of '20 per page' aligns with the schema but adds no extra meaning beyond what's already specified.

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?

Clearly states a specific verb and resource (list exhibitors at one edition) and enumerates the returned fields, so an agent understands the tool's function. However, it does not explicitly distinguish itself from the closest sibling (list_edition_sponsors), leaving some ambiguity about exhibitors vs. sponsors.

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 usage (get exhibitors for a given edition) and includes pagination and account details, but never explicitly states when to use this tool versus alternatives like exporter/export_list or list_edition_sponsors. The guidance is contextual but not prescriptive.

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?

Beyond the readOnly/idempotent annotations, it discloses the access requirement (Pro plan), the ordering rule ('highest tier first'), the pagination ceiling (20 per page, up to 200), and the data-freshness semantics (as_of, refreshed at full publish). These are real behavioral traits an agent cannot get from the structured fields.

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?

Compact and mostly front-loaded, with the plan requirement and the expected return shape stated up front. The mid-sentence colon list and the trailing id-sourcing clause are slightly dense but each 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?

For a simple two-parameter read tool with no output schema, the description covers what is returned, how results are paged, how they are ordered, how fresh the data is, and the entitlement needed. Nothing required to call it correctly 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?

Schema coverage is 100% and the schema already documents '1-based page, 20 rows each' and 'Edition uuid from get_event'; the description largely repeats that (20 per page, id from get_event). It adds only the ordering hint, so the baseline 3 applies.

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?

Names a specific verb and resource (sponsors of one edition) and enumerates the returned fields (company, public tier label, HQ country and url), so it is clearly not the generic organizer/exhibitor listing. It does not explicitly distinguish itself from the close sibling list_edition_exhibitors, which is the only gap.

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?

States a prerequisite ('Requires a Pro plan') and tells the agent where to source the required id ('Takes an edition id from get_event'), which is a concrete routing cue. No when-not-to-use guidance or comparison against the other edition-scoped listing is given.

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 the read-only, idempotent, non-destructive nature. The description adds valuable context beyond annotations: the requirement of a free Messe Atlas account and the output fields (rank, name, value, slug) for typed calls. It could mention pagination or limits, but for a simple list tool this is solid.

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 short sentences, front-loaded with the account requirement, then the two behavioral modes. No filler or redundancy; every sentence carries necessary 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?

Given the low complexity (one optional parameter, no output schema) and annotations that already cover safety, the description is complete. It tells the agent about authentication, both call modes, and return fields, leaving nothing critical unspecified.

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 has 100% coverage and already documents the `kind` parameter, including its pattern and an example. The description adds meaning by explaining the effect of including vs omitting `kind`, which helps an agent invoke the tool correctly. Slight additional value beyond 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 clearly describes what the tool returns in both modes: available leaderboard kinds when called without `kind`, and ranked rows when called with `kind`. The verb 'list' is implied by the name and the resource is unambiguous. It does not explicitly differentiate from sibling tools, though none overlap with leaderboards.

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?

It gives a clear two-step usage flow: call without `kind` to discover available kinds, then pass a `kind` to retrieve rows. This is strong contextual guidance. However, it does not state when not to use it or name alternatives, keeping it from a 5.

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 cover the read-only, idempotent, non-destructive profile, and the description layers on genuinely useful context: a sign-in prerequisite and the exact shape of the returned watch data including plan-tier-dependent channels (webhooks on Team and up). It does not mention pagination or failure modes, but the auth and plan-gating disclosure adds real value.

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 dense sentence that front-loads the auth prerequisite and then the payload contents. Slightly list-heavy but every clause carries information and nothing is redundant.

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 appropriately spells out what a caller receives (watches, usage, digest date, channels) and the account requirement. For a zero-parameter read listing, this is close to complete; only pagination/ordering behavior is left unspecified.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies.

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 names the resource ("AI watches") and enumerates what is returned: watch type/id/name, plan usage count, next digest date, and alert channels. This clearly separates it from the mutation siblings watch/unwatch, though the core verb is only implied rather than stated.

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 context is implied by the surrounding watch/unwatch/listing siblings and by naming the account prerequisite, but the description never states when to call this versus alternatives or any conditions under which it should not be used.

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?

Discloses rich behavioral detail well beyond annotations: credit consumption triggers (only when email/phone is returned), free re-views of already-revealed contacts, zero-cost refusals (opted out, restricted, unavailable, nothing on file), permission and terms prerequisites, and per-plan daily caps. This is exactly the mutation/consumption context the readOnlyHint=false annotation leaves open.

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?

Front-loaded with the plan requirement and core action, and every clause carries distinct information (credits, free re-views, refusals, permission, terms, caps, usage restriction). The single dense paragraph would scan better as structured bullets, but there is no filler to cut.

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?

No output schema exists, and the description compensates by naming the returned data (business email and phone) plus provenance fields (source, as_of). Combined with credits, permissions, and usage limits, an agent has everything needed to call 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 coverage is 100% and the description essentially restates the schema's meaning for person_id (id or slug from search_speakers / get_speaker). It adds the scope note that the target is 'one public speaker', but no format or constraint detail beyond the schema, so baseline 3 applies.

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: reveals the business email and phone of one public speaker. The 'person_id or slug from search_speakers / get_speaker' clause and the credit semantics distinguish it from the free sibling lookup tools, so an agent can tell it apart without opening schemas.

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?

Gives clear context: requires Pro plan, needs 'atlas.reveal' permission plus one-time data-terms acceptance, and restricts use to business-to-business outreach. It implies the discovery path (search_speakers / get_speaker) for obtaining person_id, but never explicitly says when to prefer a free sibling instead of spending a credit, so no true when-not guidance.

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 readOnly/idempotent/openWorld=false, and the description goes well beyond them: it discloses the free-account auth requirement, the ~200-match cap, the default ordering, the A–Z continuation across pages, and that each answer carries order/max_page. This is rich behavioral disclosure an agent cannot get from structured fields alone.

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?

Front-loads the auth requirement, then purpose, then filtering/pagination behavior, then return fields. Dense but every clause carries information; only the return-field list is slightly list-like.

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 compensates by enumerating the returned fields (id, slug, name, kind, domain, HQ, industry, size band, editions), and it covers auth, result caps, and pagination. An agent has what it needs to call and interpret the 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 documents q, page, and country. The description still adds value by explaining the no-q path and its ordering/pagination semantics, though it doesn't restate the ISO-3166 or page-size details.

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+resource (search canonical companies by name, full-text) plus scope (best 200 matches, optional HQ-country filter). It distinguishes the search behavior clearly but never names the sibling it replaces, so an agent must infer its relationship to get_company, find_prospects, or semantic_search.

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?

Gives conditional behavior for the q-absent case ('most active first') and the country filter, which implies usage. However it never names alternatives or states when to prefer this over get_company, find_prospects, or semantic_search, leaving the routing decision to inference.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value by disclosing what each returned row contains (edition count, last/next start dates, largest exhibitor count) — useful behavior beyond the annotations, especially with no output schema.

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: the first front-loads what can be searched, the second front-loads what comes back. No filler or redundancy.

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 and a simple 4-param read tool, the description covers the search dimensions and the row shape well. It omits any note on result limits or how to page through beyond what the schema specifies, a minor 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 100%, so every parameter (q, page, country, vertical) is already documented with format, pattern and range. The description only restates the filter dimensions (name, country, vertical) without adding syntax or matching semantics, so the baseline 3 applies.

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 (Search) and resource (event series) plus the three filter axes — name, country, vertical. An agent can identify it as the text/geo lookup entry point, though it never names the sibling tools (get_event, upcoming_events) it differs from.

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 only implied by the phrase 'Search event series by name, country or vertical'; there is no explicit when-to-use, when-not, or routing to get_event for a single record. Siblings exist but are never referenced.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description does add real context the annotations lack: a free-account authentication requirement and the fact that results carry an event-series count. It says nothing about rate limits, pagination limits beyond page 250, or empty-query 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?

Two short sentences with the authentication prerequisite front-loaded and no filler. The second sentence is grammatically a fragment, which slightly hurts readability, but nothing is wasted.

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?

No output schema exists, and the description only names one returned field, leaving the rest of the result shape unknown. Pagination and filtering semantics come entirely from the schema; the description never resolves whether a filter is required, which is the main ambiguity for a 3-parameter, zero-required search.

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 q/page/country are fully documented in the schema and 3 is the baseline. 'By name and/or country' loosely confirms the two filters can combine, but adds no syntax or matching detail (e.g. phrase vs substring) beyond the schema's own wording.

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?

Names the resource (event organizers) and the two filter dimensions (name and/or country), plus the payload field it returns (number of event series). It is a sentence fragment with no explicit verb, but it is distinguishable from search_companies / search_events / search_speakers at a glance.

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 only guidance is the account prerequisite ('sign in when prompted'). There is no statement of when to use this versus get_organizer (single lookup) or find_prospects, and no indication whether at least one filter is expected or a bare call returns everything.

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 cover the safety profile (readOnly, idempotent, non-destructive). The description adds genuinely useful non-annotation context: an account/auth requirement and an output-privacy guarantee that email and phone are never returned. That is exactly the kind of behavioral context annotations cannot 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?

Three tight sentences with no filler, and the auth prerequisite is front-loaded before the substantive scope. Minor nit: leading with the account requirement rather than the purpose slightly delays what the tool actually finds.

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 3-parameter, no-output-schema search tool, the description covers prerequisite auth, query scope, and output exclusions. An agent has enough to invoke it correctly; only the get_speaker routing distinction is left implicit.

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 the schema already documents q, page, and country including the minLength and ISO-3166 pattern. The description restates the name-prefix and country semantics without adding syntax beyond the schema, so 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?

States a specific resource (people on the public record as speakers) and the exact filter mechanism (name prefix and/or country). It distinguishes itself from get_speaker by describing a filtered lookup rather than single-record retrieval. It never literally uses the verb 'search,' but the title and filtering semantics make the purpose unambiguous.

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?

'By name prefix (≥ 2 letters) and/or country' implies the query modes, and the account requirement is flagged. However, it gives no explicit when-to-use guidance versus the sibling get_speaker, nor when one filter should be preferred over the other. 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.

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, non-open-world), so the bar is lower. The description adds useful behavioral context beyond them: the auth requirement, the relevance ordering, and the case-insensitive prefix matching semantics.

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 tight sentences with no filler; the account requirement and match semantics are front-loaded. Slightly fragmentary phrasing ('Venues by name prefix and/or country') but nothing wasteful.

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?

No output schema exists, so the description carries the return-shape burden and does so adequately by naming the ordering and the series count per venue. Auth, matching, and scoping are all covered; only sibling routing is thin.

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 every parameter is already documented, including the 100-match cap and ISO-3166 pattern. The description reinforces q's prefix/case-insensitive behavior and supplies examples, but adds little syntax the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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 resource (venues) and search axis (name prefix and/or country), plus the ordering rule (most event series first) and result content (series count). An agent can distinguish it from get_venue and search_venue_spaces, though it never names 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?

Discloses a real prerequisite (requires a free Messe Atlas account, sign in when prompted), which is genuine when-to-use context. However, it never states when to prefer this over get_venue (single lookup) or search_venue_spaces, so routing among siblings is left to inference.

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?

Goes well beyond the readOnly/idempotent annotations: it discloses the auth requirement, the result ordering (smallest published area that meets the filters), page size (20) and cursor mechanics, the per-row fields (fit reasons, waste_pct, source_url, as_of, stale), and an important exclusion rule (spaces not publishing a filtered figure are dropped). That is real behavioral context an agent cannot get from the structured fields.

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?

Dense but front-loaded: the prerequisite opens the description, then filters, then ordering/pagination, then row shape. Every clause carries information, though the long single paragraph packs several distinct concerns (auth, filters, ranking, paging, exclusions) together without separation.

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 must carry the return shape, and it does: row fields, ordering, page size, cursor, and exclusion behavior are all covered, plus the account prerequisite. Nothing an agent needs to call and interpret this correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds a coupling rule not obvious from the schema: min_capacity applies to only 'one kind' of capacity_kind, and it frames the filters as a size requirement. It also explains that cursor pages are only valid with the same arguments, reinforcing the schema note. Marginally more than the schema alone.

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 halls/rooms) scoped to a country with size filters, and the 'best fit first' ranking makes the retrieval intent unambiguous. It separates itself from search_venues/get_venue_spaces by describing the returned unit (spaces/rows) rather than venues. An agent can tell what it returns without opening the schema.

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?

It states the prerequisite (free Messe Atlas account, sign in when prompted) and the implicit use case (find a hall that meets area/height/capacity constraints), but never names an alternative tool or a when-not condition. Usage is inferable from the filter semantics rather than explicitly routed.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds two things annotations cannot: an auth prerequisite ('requires a free Messe Atlas account, sign in when prompted') and the return shape ('closest matches with a similarity score'). It stops short of covering ranking/score behavior or limits, so not a 5.

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?

Front-loads the auth requirement, then purpose, examples, return value, and the alternative in four tight sentences. Slightly dense, but every sentence carries information and none is redundant.

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 supplies the return format (matches plus similarity score). All parameters are schema-documented, auth is disclosed, and the sibling routing is explicit. Nothing an agent needs to invoke this correctly 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?

Schema description coverage is 100%, so each of the three parameters (kinds, query, country) is already documented with format hints. The description adds no per-parameter detail beyond reinforcing the natural-language style of `query`, so the baseline 3 applies.

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 (search) and resources (companies and events) with a clear scope qualifier: 'by meaning rather than keywords'. The contrast with keyword/exact-name search makes it distinct from the many search_* siblings.

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 routes the agent: 'Use search_* for exact names' names the alternative family and the condition that selects it. Concrete example queries ('flame-retardant composites suppliers') make the intended input style unmistakable.

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 idempotentHint=true and destructiveHint=true, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the account requirement, the 'atlas.reveal' permission, and a plain-language restatement of the idempotent behavior ("Removing something not watched changes nothing").

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 compact sentences with no filler, each carrying distinct information (auth, action, idempotency, permission). Minor weakness: it leads with the account prerequisite before the action, so the core operation is not 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 two-parameter mutation with no output schema, the description covers auth, permission, scope, and idempotency behavior adequately. Only the success/failure response shape is left unaddressed, which is minor here.

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% and the enum is fully specified, so the baseline is a 3. The description adds value by telling the agent where valid values come from ("as list_watches shows them"), which helps ensure correct invocation beyond the raw field types.

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 ("Removes") and resource ("one item from your workspace's 'AI watches'"), making the operation unambiguous. It clearly contrasts with the watch sibling, and the entity_type/id scoping ties it to a single tracked item.

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?

Gives clear context: it references list_watches as the source of the arguments and explains that removing a non-watched item is a no-op. It stops short of an explicit "use watch to add items" routing statement, so it lacks full when/when-not alternative framing.

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. Beyond that, the description discloses sort order (soonest first) and pagination mechanics via cursor, which are genuine behavioral traits the annotations don't carry.

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: the first front-loads what is returned and how it is ordered/filtered, the second gives usage and paging. No filler or restatement of the title.

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 usefully enumerates the row fields (event, dates, city, country, venue, organizer, source_url, as_of) and explains pagination, which is what an agent needs. Minor gap: it doesn't state whether results are capped or how empty windows behave, but the definition is otherwise self-sufficient.

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 all six parameters (including defaulting rules for from/to and the origin of venue/cursor values) are already documented in the schema. The description only adds the cursor-paging hint, which is already implied by the schema's 'opaque cursor from the previous page'. 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?

States a specific verb+resource: trade-show/exhibition editions within a date window, returned soonest-first, with optional country/vertical/venue filters. The combination of date-window scoping, sort order, and filter dimensions makes it clearly distinct from get_event and search_events.

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?

Gives an explicit triggering context ('what shows are on in …' questions) and instructs how to page by passing the previous answer's cursor. It does not explicitly say when to prefer get_event or search_events over this tool, so it stops short of full alternative routing.

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?

Goes well beyond the annotations: states the free-account sign-in requirement, the 'atlas.reveal' permission need, plan-based watch quotas (1/100/500), and the two delivery channels. The 'watching the same thing twice changes nothing' line corroborates idempotentHint=true and destructiveHint=false rather than contradicting them.

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?

Front-loads the account requirement and the action, then layers quota and delivery facts; nearly every sentence carries information an agent needs. The quota sentence and permission clause crowd the tail slightly, but nothing is truly wasted.

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 still covers what happens after the call (digest, webhooks), authorization, quota ceilings, and idempotency — everything needed to invoke a mutation correctly. No meaningful gap remains.

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% and the enum is self-documenting, so the schema already carries the parameter burden. The description echoes the same entity list and the ISO/slug forms rather than adding format or validation detail beyond it, so baseline 3 applies.

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+resource: adding an event, edition, company, organizer, country or vertical to the workspace's 'AI watches' list. The watch-list framing and the idempotency note make it clearly distinguishable from siblings like unwatch and list_watches without needing their schemas.

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?

Gives clear context for why and when to use it (subsequent changes arrive via weekly digest and signed webhooks on Team+), plus prerequisites. It stops short of explicitly naming unwatch/list_watches as the removal/inspection counterparts, so the when-not path is left implicit.

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