Eventee MCP by usefulapi

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

Annotations already declare write, non-idempotent, non-destructive behavior; the description adds that check-in sets checked_at to now, supports undo, and fails for non-participants. It does not spell out repeated check-in semantics, but otherwise adds meaningful behavioral context beyond annotations.

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?

Four short sentences, front-loaded with WRITE and the action, with no wasted words. The endpoint is included as useful implementation context without bloating the description.

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 two-parameter mutation with annotations and no output schema, the description covers the input source, write effect, undo behavior, failure condition, and endpoint. It does not describe the response payload, but that is not essential for correct invocation.

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 both parameters are documented in the schema. The description still adds value by explaining where attendee_id comes from and that checkin=true sets checked_at to now, beyond the schema's simple true/false toggle.

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 action (check a participant in at the event) and its inverse (undo the check-in), plus the PATCH endpoint. This clearly distinguishes it from sibling tools like remove_attendee, register_people, and create_* operations.

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?

Tells the agent to source the participant id from eventee_list_participants and notes that the call fails if the person is not a participant of the event. Clear usage context, though it does not explicitly name alternative tools for adjacent workflows.

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=false, openWorldHint=true and idempotentHint=false, so the description's 'WRITE:' adds little on its own. The genuinely valuable disclosure is the side effect: the day is 'created if missing' when the break is added, which is not encoded anywhere in the schema or annotations. Return values and error behavior remain unstated.

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 compact sentence with the operation type front-loaded, followed by the resource, examples, and the key side-effect caveat. Nothing is redundant or padded.

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 4-parameter write tool with full schema coverage and no output schema, the description covers operation type, target resource, time semantics, and the auto-create side effect. It stops short of saying what is returned (e.g., a break identifier) or whether the event must already exist, which matters for chaining calls.

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 baseline is 3; the description earns above that by clarifying that `start` does more than mark time — it determines which program day the break is placed on (and whether that day is auto-created). The optional `description` and `end` fields are left entirely to 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 ('add a break ... to the event program') and gives concrete examples ('coffee, lunch'), which cleanly separates it from siblings like eventee_create_session or eventee_create_hall. The 'WRITE:' prefix plus endpoint makes the operation type immediately obvious.

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 examples ('coffee, lunch') imply the use case, but there is no explicit statement of when to use this instead of eventee_create_session or how breaks relate to sessions in the program. An agent must infer that breaks are non-session program entries.

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=false, idempotent=false, destructiveness and open-world, so the safety profile is covered. The description adds the useful behavioral fact that it returns an id to be reused, plus the endpoint. However it doesn't cover error behavior, required permissions, or return-shape detail, so credit is moderate.

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 clauses, front-loaded with the WRITE flag, then the action, then the downstream usage. Zero waste and well ordered.

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 create tool with no output schema, the description supplies the essential return-value hint (id reuse) and the endpoint. Nothing critical is missing, though a note on permissions or failure modes would round it out.

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%, with both name and order fully documented in the schema including defaults and bounds. The description adds no per-parameter meaning beyond what the schema already provides, so the 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 ('add a hall') and clarifies what a hall is (room, stage or virtual space) within an event. A clear 'WRITE:' prefix flags the operation type. It doesn't explicitly distinguish itself from siblings like create_session, but the resource is 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?

'Use the returned id as hall_id for sessions' gives concrete downstream usage, implicitly signalling this is a prerequisite step before creating sessions. Lacks explicit when-not-to-use or alternatives, but the context is clear enough for an agent to know when to call it.

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=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the write semantics are covered structurally; the 'WRITE:' prefix and POST endpoint merely restate that. It does add one piece of behavioural value the annotations lack: that the response carries an id to be consumed by sessions.

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, front-loaded with the operation type and the resource, then the follow-up usage tip, then the endpoint. No filler, and the most decision-relevant information comes first.

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 create tool with full schema coverage and no output schema, this is nearly complete: it says what is created, that an id is returned, and where that id goes. Minor gaps are the absence of failure conditions or whether duplicate names are allowed.

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 name, color and order are all fully documented with constraints (hex pattern, max length, 0-10000 ordering, default position). The description adds nothing beyond 'with a colour', so baseline 3 applies and the schema does the work.

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 ('add a label (track) for sessions') and even disambiguates the domain term by equating label with 'track'. Combined with the endpoint line, an agent knows exactly what this creates and that no sibling tool does the same job.

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 downstream guidance ('Use the returned id in label_ids of a session'), which implies the workflow ordering, but it never states when to create a new label versus reusing an existing one, nor any prerequisite (e.g., existing event/workspace context). Usage is implied rather than spelled out.

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?

Adds real behavior beyond the annotations: the session appears in the event app for attendees, and the event day is derived from `start` and auto-created if missing — a non-obvious side effect on a parent resource. It also names the underlying endpoint POST /public/api/v1/lecture, but does not mention failure modes or what a rejected payload returns.

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?

Four short sentences, front-loaded with a WRITE marker, then purpose, then the side effect, then prerequisites and the endpoint. No sentence is redundant and the riskiest detail (implicit event-day creation) lands early.

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 15-parameter create tool with no output schema, the description covers purpose, dependency ordering and the implicit event-day creation, which is the information an agent cannot get from the schema alone. It omits any sense of the return value/created id, which matters for follow-up calls attaching speakers or labels.

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 one of the 15 parameters is already documented in-schema, including enum values, formats, defaults and the workshop-only constraints. The description only echoes the hall/speaker/label id concept ('pass their ids') without adding format or ordering detail beyond the schema's baseline.

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?

Opens with a specific verb and resource: 'WRITE: add a session (lecture or workshop) to the event program.' The parenthetical scope distinguishes it from a break-type entry, but it never names eventee_create_break or eventee_update_session to draw a hard boundary between the three program-item tools.

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 states preconditions: 'The hall, speakers and labels must already exist (create them first and pass their ids)' and points to eventee_get_program for hall ids, which tells the agent the correct call ordering. It stops short of saying when to prefer this over the sibling update or break tools.

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=false, destructive=false, idempotent=false, and openWorld=true, so the safety profile is covered. The description adds genuinely new behavior beyond the schema: Eventee fetches the photo server-side from photo_url, an external side effect an agent should know about. It stops short of stating duplicate-email behavior or permission requirements, which matters given idempotentHint=false.

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 WRITE marker, then the workflow link, then the one non-obvious parameter caveat. No filler and nothing to trim.

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 14 params, no output schema, and only one required field, the description covers the essentials plus the return-value hint ("returned id"), which is valuable since no output schema exists. The remaining gap is error/duplicate behavior for a non-idempotent write.

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% with 14 well-documented properties, so the schema carries the parameter burden. The description adds real meaning only for photo_url (server-side download), leaving the other 13 fields entirely to the schema — appropriate, but the baseline is the correct score.

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?

Opens with an explicit verb+resource marker ("WRITE: add a speaker profile to the event") plus the user-visible consequence ("shown in the event app"). Among siblings it is unmistakably the speaker-creation tool versus create_session/create_hall and the read-only list_* tools, and it names the downstream link to sessions.

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 forward-looking workflow guidance ("Use the returned id in speaker_ids of a session"), which tells the agent where this fits in a sequence. However, it never states when not to use it, what to do if the speaker already exists, or whether a separate update path exists — usage is implied rather than specified.

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 destructiveHint and non-readOnly, and the description adds the value the annotations cannot: the exact blast radius (questions, polls, workshop bookings, ratings) plus the dry-run/preview behavior of omitting confirm. This is precisely the 'what gets destroyed' disclosure the rubric rewards.

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?

One front-loaded sentence with the risk label (WRITE, IRREVERSIBLE) first, the delete and cascade scope second, the confirm safety valve third, and the raw endpoint last. Zero filler.

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, but none is needed: the preview-vs-delete behavior is stated, both parameters are covered, and the destructive consequence is fully described. An agent has everything required to call 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 description coverage is 100% and both parameters are documented in the schema (confirm's preview semantics are spelled out there verbatim). The description restates the confirm rule without adding format or syntax detail beyond the schema, so the baseline of 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?

Specific verb+resource ("delete a session") with explicit parenthetical scope ("lecture or workshop") and the cascade targets named. It is unambiguously distinct from the sibling create_session / update_session tools 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?

The description explains the confirm gate precisely: without confirm:true nothing is deleted and a preview is returned, and it tells the agent to ask the user to approve first. It gives clear context but does not name alternative tools (e.g. update_session for reversible edits).

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 only declare readOnly/openWorld/no-destroy; the description goes much further, disclosing response clipping (description_max), per-part paging via limit/offset, the `more` continuation map, a reply size budget that truncates results, and that times are in the event's time zone. These are non-obvious behaviors an agent would otherwise discover only by trial.

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?

Content is front-loaded (what is returned first, then how to use it, then reply mechanics). It is one packed paragraph with deeply nested parentheticals that are slightly hard to parse, but no sentence is filler.

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 no annotations about returns, the description carries the full burden and does so: it names the response parts, explains paging and continuation, discloses truncation by description_max and by a size budget, and states the time zone. Nothing material is left for the agent to guess before calling.

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 cross-parameter semantics the schema cannot: offset applies to all parts simultaneously, clipping is governed by description_max, and `parts` is the way to work around the size budget. It does not add much on `date` or `with_overlapping` beyond the schema, keeping it short of 5.

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 ('whole program of the event the API token belongs to') and enumerates the exact parts returned (halls, days, sessions, workshops, breaks, speakers, labels), including the type-0/type-1 distinction for sessions vs workshops. An agent can immediately tell this apart from the create_*/delete_*/list_* 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?

'Use it to read back ids (hall_id, speaker ids, label ids, session ids) before changing anything' gives concrete when-to-use guidance tied to the write siblings. It also prescribes a strategy for large events ('read one part at a time with `parts`'), but gives no explicit when-not-to-use or named alternative.

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 that invalid entries and admins/moderators are skipped silently, that the first 25 are processed immediately and the rest in the background, that tickets replace existing tickets, and that confirm-less calls return a preview without side effects. It also tells the agent to re-read eventee_list_participants to verify, which is exactly the post-mutation guidance an agent needs for a destructiveHint=true tool.

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 WRITE marker and the core action, then layers in gating, side effects, and pagination-in-batches details. It is dense and slightly run-on, but nearly every clause carries operative information; only the raw endpoint path is close to filler.

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 destructive, non-idempotent, no-output-schema mutation, the description covers side effects, confirm gating, silent failures, background processing, and how to verify results. Nothing an agent needs to invoke it safely 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 real semantics: tickets replace existing ones, confirm is only required with send_email=true, and group can be set per person or as a default. It stops short of explaining the phone/company/position fields, which the schema already covers.

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?

Opens with a specific verb+resource+scope ("WRITE: add up to 100 people to the event as attendees") and states the mechanism for both existing-account and new users. It does not, however, distinguish itself from the sibling eventee_register_people, which an agent could reasonably confuse with this tool.

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 states the conditions for the two modes: send_email=true triggers invitation emails and requires confirm: true, while omitting confirm produces a preview with nothing sent or added, plus explicit advice to ask the user to approve recipients. It lacks an explicit "use X instead when..." routing against eventee_register_people.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds value beyond them by disclosing the shape of the payload (per-group feature flags, auto-assignment ticket names, default group flag) and the underlying GET endpoint, which helps the agent reason about side-effect-free, cacheable reads. It says nothing about pagination limits or response size, which the schema partially covers via limit/offset.

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 plus the endpoint, front-loaded with the returned resource content and followed by the actionable usage hint. The parenthetical feature list ('(agenda, questions, polling, networking, ratings, ...)') is slightly sprawling but earns its place by signalling the payload's variable-width nature rather than abstracting it away.

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 return values and does so thoroughly (features, ticket mappings, default flag, ids). Since it is a simple 2-param read tool with full annotation coverage, the remaining gap — pagination/cursor behavior and whether results are event-scoped implicitly — is 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 description coverage is 100% and both parameters (limit, offset) are documented in the schema, including the 'pass the previous reply's next_offset' convention, so the description properly defers to the schema. The description mentions 'ids' only in the context of output usage, adding nothing about limit/offset semantics. 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 precisely enumerates what the resource contains (app features per group, ticket-name auto-assignment rules, the default group), which makes it clearly distinguishable from siblings like eventee_list_participants or eventee_list_partners. It lacks an explicit verb ('List...') and relies on the title/name for the action, but the noun phrase is specific enough that an agent knows exactly what it gets back.

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?

'Use the ids as group_id when inviting or registering people' explicitly ties this tool to the downstream invite/register flows (eventee_invite_attendees, eventee_register_people), giving real context for when to call it. There is no statement of when not to use it or of any prerequisites (e.g., event id / auth scoping), so it stops short of full routing 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 read-only and non-destructive behavior, and the description adds useful context: role encoding, checked_at null semantics, anonymous/deleted placeholder emails, omitted personal app link, and filter-after-read behavior. It does not cover auth or rate limits, but it adds substantial behavioral detail beyond annotations.

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 front-loads what is returned, then packs role codes and data caveats into a few dense sentences with no filler. The endpoint reference at the end is compact and useful.

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 list key fields and quirks, plus pagination guidance. It could be stronger by specifying pagination metadata like next_offset or sort order, but it is sufficient for correct invocation.

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 parameters are already well documented in the schema. The description adds some context around pagination and response role codes, but little parameter-specific detail beyond what the schema provides.

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 that it returns event participants and enumerates the included data fields and role codes, making the resource specific. It does not explicitly distinguish itself from siblings such as eventee_list_registrations or eventee_list_groups.

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?

Offers pagination guidance for large events and explains that filters apply after the full list is read. However, it does not say when to use this tool instead of related listing tools or mention preconditions.

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, non-destructive and open-world, so the safety profile is covered. The description adds value by naming the returned data (company details, contact data, code, page sections) and the underlying public endpoint, but says nothing about volume, ordering, or how paging behaves in practice.

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 compact fragments, front-loaded with the resource and its disambiguation; nothing is wasted, though the raw endpoint path is of marginal value to an agent.

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 shape of the returned records, and pagination is fully handled by the schema. Only the lack of scope/volume context keeps it from being 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%, so limit/offset, their ranges and the next_offset chaining hint are already fully documented. The description adds no parameter-level detail beyond what the schema provides, which is the expected baseline here.

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 ('Partners of the event') and disambiguates the term by glossing it as sponsors and exhibitors, plus enumerates the payload's contents. It stops short of naming any sibling or distinguishing this list from other list_* tools.

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?

There is no guidance on when to call this versus the many other list_* siblings (participants, registrations, groups, reviews), no prerequisites, and no statement of default scope.

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 this is a read-only, non-destructive, open-world operation. The description adds important behavioral context beyond annotations by disclosing that filtering happens after the full list is read, which has performance implications, and that pagination should be used for large events.

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: the resource and returned fields are front-loaded, followed by the filtering/pagination caveat and endpoint. No sentence 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 usefully lists the main returned fields. It does not describe the response envelope or pagination metadata explicitly, but the offset parameter references next_offset, which covers the key pagination detail.

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 each parameter. The description still adds useful meaning by explaining that filters are applied after the full list is read and that limit/offset are the mechanism for large events.

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?

Identifies a specific resource, event registrations, and enumerates what is returned: status, group, contact details, and form answers. It also distinguishes registrations from generic participants by saying “people who registered or were pre-registered,” though it does not explicitly name the sibling list tool to use instead.

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 one clear operational guideline: filters are applied after the full list is read, and limit/offset should be used for large events. It does not explain when to use this tool instead of sibling tools such as list_participants or list_groups.

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, destructiveHint=false, and openWorldHint=true. The description adds important non-obvious behavior: filtering happens after reading the full list, summaries cover only the 50 most reviewed sessions, and summary_truncated indicates omissions.

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 and front-loaded, starting with what the tool returns before adding summary and filter behavior. Every sentence contributes useful information without repetition.

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?

Despite no output schema, the description sufficiently explains the return shape: individual reviews with rated sessions plus per-session summaries and truncation signaling. With annotations covering safety and schema covering parameters, the definition gives an agent enough to call the tool 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%, so limit, offset, star filters, and session_id are already fully documented in the schema. The description reinforces session_id usage and filter order, but does not add much parameter-specific syntax beyond 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 resource and scope: session ratings from attendees, including review fields and per-session summaries. It also references the related session_id source and the API endpoint, making it clearly distinguishable from session mutation and program tools.

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 filters apply after the full list is read and that session_id should be used for a specific session. This gives clear usage context, though it does not explicitly name when to prefer this over every sibling tool.

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 flag destructive/openWorld, and the description adds real substance beyond them: upsert semantics, the email side effect and its default, the confirm gate that downgrades the call to a read-only preview, and the fact that invalid entries are silently skipped. That last point is a critical behavioral trait an agent cannot infer from the 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?

Front-loaded with a 'WRITE:' marker, then the limit, then the side-effect rules in descending importance, ending with the verification hint and endpoint. Dense but every clause carries decision-relevant 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?

With no output schema, the description correctly explains what comes back in the no-confirm case (a preview, nothing sent or registered). For a destructive batch-write tool with a side-effecting email path, nothing an agent needs to call it safely 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 cross-parameter meaning the schema does not: the confirm/send_email dependency and the group_id-as-default relationship. The endpoint reference is also useful for debugging.

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 ('pre-register up to 100 people for the event') plus the crucial upsert nuance (existing email is updated, not duplicated). It does not, however, distinguish itself from the sibling eventee_invite_attendees, which an agent could easily confuse with this tool.

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 operational conditions: send_email defaults to false, requires confirm: true, and without confirm you get a preview only; it also tells the agent to re-read eventee_list_registrations to verify. Missing is any guidance on when to pick this over eventee_invite_attendees.

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 past the destructiveHint/idempotentHint annotations by enumerating what is destroyed (participation, invitation, tickets), what is preserved (the account), and the non-obvious silent-success behavior when the email matches nobody. The confirm-gated preview path is a behavioral trait an agent could not infer from annotations 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 two highest-risk facts ('WRITE, IRREVERSIBLE') in the first three words, then packs scope, edge-case behavior, and the confirm requirement into a single dense paragraph with no filler. The endpoint suffix is the only mildly redundant element.

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, yet the description still covers the two response shapes that matter: successful deletion and the silent-success-on-no-match case, plus the preview returned without confirm. Nothing an agent needs in order to call this destructively and safely 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 interpretive value: the silent-success note tells the agent that an unknown email is not an error, which changes how the email argument should be validated and reported. The confirm gate is restated from the schema rather than extended, keeping this below a 5.

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 ('remove the person with this email from the event') and immediately delimits the blast radius: participation, invitation and tickets for this event are deleted while the Eventee account survives. That scope statement is what separates it from registrations-level siblings such as eventee_remove_registration.

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 concrete operating precondition — 'Needs confirm: true (without it: a preview, nothing removed)' and 'ask the user to approve first' — which tells the agent exactly how to sequence the call. It never names an alternative sibling or an explicit when-not-to-use case, 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 already flag destructive/irreversible, and the description adds context they cannot carry: Eventee returns success even when no such registration exists, and omitting confirm yields a preview with nothing deleted. Those are non-obvious failure and gating semantics that materially change how an agent should interpret the response.

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 'WRITE, IRREVERSIBLE' and then the confirm gate, in a compact single passage with no filler. The trailing REST endpoint is mildly redundant but harmless context.

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 destructive operation, the description covers everything an agent needs: irreversibility, the confirm precondition, what a non-confirmed call returns, and the misleading-success behavior. Nothing essential 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 both parameters are already documented in the schema, including the confirm gate. The description restates the confirm behavior and identifies email as the deletion key but adds no format, lookup, or matching semantics 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?

States a specific verb and resource scoped by an identifier: 'delete the registration with this email'. That cleanly separates it from siblings such as eventee_remove_attendee, eventee_list_registrations and eventee_register_people, which operate on attendees or lists rather than a single registration.

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 spells out the precondition that selects real deletion versus a no-op preview ('Needs confirm: true... without it: a preview, nothing deleted'), which is exactly the guidance an agent needs before calling. It stops short of pointing to an alternative (e.g. list_registrations to find the email), so it is clear context but not full when/when-not 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?

Annotations already flag destructive=true and idempotent=true, but the description goes well beyond them by disclosing the reset-what-is-omitted behavior field by field, that an empty list removes all speakers/labels, and that start must fall on an existing event day. This is exactly the kind of consequence detail an agent needs before calling a destructive full-replace.

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 and front-loaded with 'WRITE' then the core replace semantics, then the reset warning. It is a long run-on sentence that repacks the same field list twice (prose and inline code), costing some readability, but no clause is filler.

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 15-parameter destructive full-replace with no output schema, the description supplies the get-first workflow, the required-field rationale, the removal convention, and the preserved fields. Nothing an agent needs to call it safely and 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; the description earns extra by explaining that type/speaker_ids/label_ids/capacity/discussion/moderating/polling are required due to reset semantics, and that [] clears a list. It does not respecify formats for name, description, or stream_url, which is fine since the schema covers them.

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?

Opens with an explicit verb and resource ('replace a session') and immediately qualifies the update mode ('full update, not a patch'), which is the single most important disambiguation against a hypothetical patch-style sibling. The HTTP method and path reinforce the semantics without ambiguity.

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 instructs the agent to read the session first via eventee_get_program and pass the current values, naming the sibling tool and the exact workflow. It also states the conditional behavior for optional fields (hall and live stream kept when omitted), which is real when-to-do-what guidance.

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