eb_event_description

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

Annotations declare readOnlyHint=true and the 'Get' verb is consistent with that, so the safety profile is covered and there is no contradiction. The description adds one small behavioral signal — the response is HTML rather than plain structured data — which matters to callers who may need to render or sanitize it. It says nothing about payload size, auth needs, or rate limits, but the annotation lowers the bar and the description clears it adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero filler, and the core action is fully front-loaded. It cannot be shortened without losing meaning, and the rich view-parameter documentation in the schema lets the short description get away with being minimal. It could carry slightly more value (e.g., a sibling contrast) without becoming bloated, but as written it is efficiently sized.

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 2-parameter read tool, the schema plus annotation covers the invocation essentials: the required event_id type is documented and the view enum is fully specified. However, with no output schema and no guidance distinguishing this from eb_event_details or eb_event, an agent facing the large sibling set could plausibly invoke the wrong tool. Adequate, but with a real ambiguity 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% for both parameters, so per the baseline the description need not compensate for schema gaps. The schema's view parameter documentation is unusually strong, explaining the compact/full response shapes and why the server deliberately avoids field projection, while event_id is documented as 'Numeric event id'. The tool description itself adds no parameter meaning beyond the schema, which is acceptable at this coverage level.

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 ('Get') and a specific resource ('an event's full HTML description'), so an agent knows this fetches the HTML body of an event listing — distinct in resource from the venue, organizer, and order tools. It stops short of 5 because it does not differentiate from the closely related siblings eb_event and eb_event_details, which also target event data, leaving an agent unable to tell them apart without opening 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?

The description offers no when-to-use guidance, no exclusions, and no named alternatives. With 30 siblings including eb_event and eb_event_details in the same event-data domain, the one-line purpose statement gives an agent no basis for selecting this tool over them. Any when-to-use signal is purely implicit in the tool's name and purpose.

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