Evenium MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior — that a duplicate may be silently created and that it hits POST /contacts. It stops short of describing the response (e.g. returned contact id) or any auth/scope requirements, which keeps it off 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?

Three tight sentences with the write nature and resource front-loaded, followed by the routing caveat and the duplicate warning. Every clause carries actionable information and nothing repeats the schema.

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 7-param mutation with no output schema, the description covers purpose, routing, and the main risk (duplicates). The remaining gap is what comes back after creation — an agent cannot tell whether a contact id is returned for chaining into evenium_create_guest.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29% across 7 params, so the description must compensate; it does name most of them (name, email, company, custom id, fields) but adds no semantics beyond the property names. The 'gender' enum and the ext:<id> mechanics of custom_id 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?

Opens with an explicit verb+resource ('add a contact to the address book') and enumerates the payload it accepts (name, email, company, custom id, fields). It also names the sibling it is not (evenium_create_guest), so the agent can distinguish it from guest-creation tools without opening a 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?

Explicitly states a when-not ('Does not invite them to an event') with the alternative tool named, plus a precondition workflow ('search with evenium_list_contacts first') to avoid duplicates. Both the exclusion and the recommended prerequisite are spelled out rather than implied.

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 write/idempotent/openWorld profile, and the description adds genuinely new behavior: creating a guest may also create a new contact, and the invitation emails sent may follow Evenium's own rules. Useful side-effect disclosure for a mutation. It stops short of saying what happens on a duplicate invite or what the response contains.

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, front-loaded with the 'WRITE:' marker so the mutation semantics land first, followed by the mode split and the status caveat. The trailing 'POST /events/{eventId}/guests' restates the operation rather than adding agent-relevant information, which is the only wasted line.

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 an 8-parameter mutation with no output schema, the description covers the mode decision, the contact-creation side effect, and the email-behavior caveat, which is most of what an agent needs before calling. Gaps remain around duplicate/already-invited handling and the result payload, but the core call decision is well supported.

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 only 38%, so the description has to carry more weight: it does explain the contact_id vs. name-field fork and elaborates on status as the registration status influenced by event email rules. But gender, company, and email constraints are left entirely to the bare schema, and the description never states which from-scratch fields are actually required.

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 ('invite a person to an event') and immediately decomposes it into its two distinct modes: inviting an existing contact via contact_id, or creating a guest from scratch via name/email fields. An agent can distinguish this from evenium_create_contact and evenium_update_guest_status 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 two invocation paths are stated with their selecting parameters ('Either invite an existing contact (contact_id) or create a guest from scratch (...)'), which is explicit when-to-use guidance. It lacks a negative case, e.g. when to prefer evenium_create_contact first and then invite, so it falls short of the full when/when-not/alternatives bar.

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, so safety is covered. The description adds that specific fields are returned (helpful since there is no output schema) and the underlying endpoint, but says nothing about not-found behavior, permissions, or whether ext: lookups differ.

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 fragments with the purpose and id forms front-loaded ahead of the field list. The trailing 'GET /contacts/{contactId}' is marginally redundant for an agent but harmless.

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 tool with full annotation coverage, the description supplies the returned field set that the missing output schema would otherwise carry. Remaining gaps (not-found behavior, ext: lookup nuances) 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% and the schema description already fully explains both accepted id forms including the `ext:<customId>` convention. The description restates the same id semantics without adding format, validation, or lookup-behavior detail, 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?

States a specific verb+resource: retrieves a single contact, and enumerates the returned fields (name, gender, email, company, fields), which separates it from evenium_list_contacts by singularity. It doesn't explicitly name the sibling it contrasts with (e.g. evenium_get_guest), 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 singular phrasing implies 'use this to fetch one known contact', but there is no explicit when-to-use or when-not guidance. Given the crowded sibling set (get_guest, list_contacts, get_contact_events), the description offers no rule for choosing between contact and guest lookups.

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, so the safety profile is covered. The description adds the return shape (per-event registration status, post status, category), which is genuinely useful given there is no output schema, but says nothing about ordering, pagination, or behavior for an unknown contact.

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 what is returned and what can be filtered. The trailing REST path is arguably redundant but harmless context; nothing else 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?

With no output schema, the description usefully enumerates the fields attached to each event, and the 100%-covered schema carries the parameter detail. Gaps remain around pagination/result-size behavior and error cases for a 7-parameter read 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% and every date parameter is fully documented in the schema with RFC 3339 format and CET fallback. The description only summarizes the filter families (start/end/creation), adding no semantics beyond what the schema already provides, 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?

States a specific resource and relationship — the events a contact is invited to — and adds that each entry carries that contact's registration (status, post status, category), which is distinct from plain event listing. It does not explicitly name a sibling it competes with (e.g. evenium_list_events or evenium_get_guest), so differentiation is inferable 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?

'Filter by event start, end or creation date' tells the agent what the filters do, but there is no guidance on when to choose this tool over evenium_list_events or evenium_get_contact. Usage is implied by the resource scope rather than 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by listing returned fields and the underlying GET endpoint, but it says nothing about authentication, error cases, or how missing IDs are handled.

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 definition is a single front-loaded sentence followed by the endpoint, with no wasted preamble. The trailing "..." and "..." style is slightly informal, but the content is appropriately sized for a simple lookup tool.

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-only lookup with full schema coverage and annotations, the description is reasonably complete: it states the resource, required identifier, returned fields, and endpoint. The absence of an output schema is partly compensated by the field list, though it remains non-exhaustive.

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 schema itself explains that event_id may be an Evenium id or an `ext:<your own event id>` value. The description adds no meaningful parameter semantics beyond "by id", 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?

The description states a specific verb+resource ("Get one event by id") and enumerates the returned fields (title, description, dates, status, site path, fields), which clearly distinguishes it from list-oriented siblings such as evenium_list_events. However, it does not explicitly name a sibling alternative the way a 5 would.

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 phrase "One event by id" implies a single-record lookup, so an agent can infer this is the right tool when an event id is known. But there is no explicit when-to-use/when-not guidance and no mention of alternatives like evenium_list_events for browsing.

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, so safety behavior is covered. The description adds the HTTP endpoint and enumerates returned fields, which is useful because there is no output schema, but it does not describe error behavior, permissions, or rate limits.

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 two compact fragments with no wasted wording: the entity, id-based scope, returned fields, and endpoint are all front-loaded. Nothing extraneous is present.

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 read-only single-record GET with fully documented parameters, the description is largely complete and lists the returned fields in lieu of an output schema. Minor gaps remain around not-found behavior and explicit sibling routing, but nothing essential to invoking the tool 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%, with both event_id and event_part_id fully documented in the schema, including the ext: prefix convention and the source of event_part_id. The description adds only 'by id' and does not extend parameter meaning 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?

The description identifies a specific resource and scope: one event part (session) retrieved by id, with the exact endpoint and returned fields. It is clearly distinguishable from the sibling list tool evenium_list_event_parts because it fetches a single part by id.

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 phrase 'by id' implies a single-record lookup, and the schema notes that event_part_id comes from evenium_list_event_parts. However, the description itself does not explicitly state when to use this tool instead of the list tool or what failure cases mean, so usage guidance is only implied.

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, non-destructive profile, and the description adds real context beyond them: the exact REST endpoints, the fact that REGISTRATION means session registrations, and that event-only fields are flagged. It stops short of describing error behavior for invalid ids or missing guests.

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 dense sentences, front-loaded with the resource and payload, then the optional includes and endpoints. The trailing GET paths are somewhat redundant with the schema parameters but still orienting; nothing 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, the description carries the return-value burden and does so by naming the fields returned. Combined with the include options and lookup keys, an agent has enough to call it correctly; only the dual-key conflict rule 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 a bump by expanding the opaque 'include' enum values into meaning ('REGISTRATION (registrations to sessions), PRESENCE and SIGNATURE data'), which the schema only labels as 'Extra data to return.'

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 guest of an event') and enumerates the returned fields (name, email, status, category, fields). The phrase 'event-only fields flagged' implicitly distinguishes it from evenium_get_contact, and 'One guest' contrasts with evenium_list_guests.

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 indicates the two lookup keys ('by contact id or by guest code') but never says when to prefer this tool over evenium_get_contact or evenium_list_guests, nor what to do if both keys are supplied. Usage is implied by the retrieval phrasing rather than 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value with the platform-availability restriction and the return-field list, but says nothing about empty/missing-result behavior or pagination.

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 payload is front-loaded: what is returned, then the availability caveat, then the underlying endpoint. Two compact sentences and a path line, none of which is redundant, though the endpoint line adds little for an agent that already has the parameter names.

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 only two required, fully documented parameters, a read-only annotation set, and no output schema, the description covers the essential gaps by listing the returned fields and the platform restriction. Only the edge-case behavior (no booking present) is 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 description coverage is 100%, so both parameters (event_id, contact_id) are fully documented in the schema, including the `ext:` id forms. The description only restates the event/guest scoping and adds no syntax or format detail beyond that, which is the expected 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?

The description names the specific resource ('hotel room bookings of one guest at an event') and enumerates the fields returned (room id, check-in/check-out, status), so the agent knows exactly what data comes back. It is distinguishable from siblings like evenium_list_hotels and evenium_get_guest by being guest-and-event scoped.

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: fetch accommodations for a known guest within a known event. The one explicit constraint, 'Not available on the evenium.net platform,' is a useful eligibility caveat but not a when-to-use rule. No sibling alternative (e.g. list_hotels for hotel inventory) is named or excluded.

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, so the safety profile is covered. The description adds genuine value by enumerating the three possible return values (UNKNOWN, NO_SHOW, PRESENT), which tells the agent what to expect and how to handle the result, though it says nothing about permissions, rate limits, or behavior when no attendance record exists.

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

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

One sentence plus the endpoint path, with the core purpose and the return-value enum front-loaded. Nothing extraneous, and the endpoint reference is a compact way to anchor the resource hierarchy.

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 read-only lookup with full schema coverage, annotations, and no output schema, the definition covers the essentials and pre-answers the return-value question. It is slightly thin on the boundary case (what 'UNKNOWN' means or whether it is returned when no scan occurred) and on distinguishing this from evenium_get_guest_status.

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% – both event_id and contact_id document the Evenium id form and the `ext:` custom-id alternative in detail. The description mentions nothing about parameters, so the baseline 3 applies; the schema does all the semantic work 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 resource and scope: the attendance/post status of one guest, with the exact enum of possible outcomes and the underlying endpoint path. It implicitly separates itself from the similarly named evenium_get_guest_status by framing this as 'attendance (post) status after the event', but never names that sibling to make the contrast explicit.

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 phrase 'after the event' implies the temporal condition under which this is the right tool, but there is no explicit when-to-use statement, no exclusions, and no pointer to evenium_get_guest_status or evenium_update_guest_post_status as alternatives. Usage must be inferred from the tool name and sibling list.

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 and destructiveHint=false, so safety is covered. The description adds the status vocabulary (CONFIRMED, DECLINED, CANCELED), which is genuinely useful, but says nothing about behavior for a guest with no registration or an invalid contact id.

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 the purpose front-loaded and examples immediately after. The trailing endpoint reference is mildly redundant given the schema, but costs little.

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 read-only lookup this is close to adequate, and the example status values partially compensate for the missing output schema. It still leaves unclear whether the response is the status alone or a broader guest object, and how it differs from the post-status 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% and both parameters document the `ext:` alternate-id forms, so the schema carries the load. The description's `{eventId}/{contactId}` path notation merely mirrors those parameters without adding format or constraint detail.

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 ('registration status of one guest at an event') and even enumerates example values, so the retrieval is unambiguous. It does not, however, distinguish itself from close siblings like evenium_get_guest or the easily-confused evenium_get_guest_post_status.

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?

No indication of when to use this versus evenium_get_guest (full guest record) or evenium_get_guest_post_status (a different status dimension). Given how similar the sibling names are, the absence of routing guidance is a real gap.

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 and destructiveHint=false, so the safety profile is covered. Beyond that, the description discloses the returned field set (id, custom id, name, email, company, fields) and the filterable dimensions, and pins the underlying call to GET /contacts, which is useful context an agent cannot get from the 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?

Three short clauses with the resource front-loaded, followed by return fields and filterable fields, and ending with the endpoint. Nothing is padded, though the trailing GET /contacts is the least essential 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?

With no output schema, the description usefully characterizes the shape of each returned contact. It covers filtering and return content; pagination is left entirely to the schema, which is an acceptable but minor gap for a paged list 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 every parameter is already documented, including pagination via max_results/first_result and the RFC 3339 pattern for updated_since. The description's filter list roughly echoes what the schema says and adds no format or semantics 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 ('List the contacts of the address book') and enumerates the returned attributes, so it is clearly a collection read rather than the single-record evenium_get_contact. It does not explicitly name a sibling to distinguish against, keeping it just 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 names which fields can be filtered on (name, email, company, last update), which implies the use case, but gives no explicit when/when-not guidance or routing to alternatives such as evenium_get_contact for a single lookup.

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, so the safety profile is covered. The description adds genuine value by explaining that include_deleted surfaces records with status DELETED, but says nothing about permissions, rate limits, or ordering of results.

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 plus the endpoint reference, with the returned-fields summary front-loaded and no filler. The only cost is that the terse phrasing reads more like data notes than a call instruction.

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 correctly compensates by listing the returned fields, and pagination semantics are carried by the schema's next_first_result hint. What is missing is any statement about ordering or result volume, but for a filtered list operation this is largely 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 event_id, event_part_id, pagination and updated_since are already fully documented. The description only reinforces include_deleted (deleted rows come back with status DELETED), a marginal add over the schema's own wording. 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 specific resource (registrations for one session) and enumerates the core returned fields (contact id, status, attendance, category, dates), plus the underlying endpoint. It is clearly distinct from the guest/contact list siblings, though it never uses an explicit verb like 'list' to anchor it.

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 by scoping to a single event part, and include_deleted gives one concrete behavioral choice, but there is no explicit 'use this when...' framing or pointer to alternatives such as evenium_list_guests or evenium_list_event_parts. An agent must infer the routing itself.

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, so the safety profile is covered structurally. The description contributes the returned field set (title, dates, nature, code, location) and the underlying GET path, but says nothing about pagination limits or total-count behavior beyond what the schema already implies.

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 plus the path: purpose and returned fields first, filters second, endpoint last. No filler and nothing buried.

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 10-parameter read tool with no output schema, the description supplies the shape of the returned records and the filter axes, which is most of what an agent needs. It stops short of describing paging behavior, but the schema already spells out max_results, first_result and the continuation value.

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 one of the 10 parameters is already documented, including RFC 3339 formats and the next_first_result continuation hint. The description only restates the filter dimensions at a high level, which is the expected baseline 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?

The description gives a specific verb ("List") and resource ("event parts"), then parenthetically enumerates what those are (sessions, workshops, activities) and which fields come back. The plural list framing separates it cleanly from the singular sibling evenium_get_event_part without having to compare 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?

"Filter by title and start/end/update dates" implies when the filters apply, and mentioning the endpoint implies the read context, but there is no explicit guidance on when to choose this over evenium_list_event_part_registrations or evenium_get_event_part, and no exclusions or prerequisites.

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, so safety is covered. The description adds that results are scoped to the account and cites the underlying endpoint 'GET /events', but says nothing about permissions, rate limits, or pagination behavior even though the schema hints at a next_first_result. Adequate, not rich.

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 with zero redundancy: what it returns, what it filters on, and how the id is reused. Purpose is front-loaded before filters and the hand-off, which is the right order for scanning.

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 10-parameter read tool with full schema coverage, full annotations and no output schema, the definition covers purpose, returned fields, filtering and the event-id hand-off. The only shortfall is that pagination (next_first_result, total counts) is left entirely to the schema rather than being explained in prose.

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 ten parameters are already documented with formats, enums, defaults and the next_first_result pagination hint. The description only restates the filter categories (title partial match, status, start/end/creation dates) without adding 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?

Specific verb+resource ('List the events of the Evenium account') with the returned fields spelled out (id, title, dates, status, creation date) and the supported filters named. It is clearly a collection query, but it never explicitly distinguishes itself from the sibling evenium_get_event, so the agent must infer single-vs-many from the names.

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 by the filter list and by the forward hand-off 'Use an event id with the guest and session tools', which tells the agent this is an entry point. There is no explicit when-to-use/when-not statement and no named alternative for the single-event case.

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, so the safety profile is covered. The description adds the returned field set and the REST path, but says nothing about pagination semantics, result caps, permissions, or ordering beyond what the schema already encodes.

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 sentences lead with what is returned and follow with the filters, then a terse endpoint reference. Nothing is wasted, though the raw path adds little for an agent that already has the tool bound to that endpoint.

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 returned fields (name, email, company, status values, category, fields), which is the main gap it needed to fill. Remaining gaps are minor: no explicit pagination/next_first_result narrative and no sibling routing, both of which are partly recoverable from the schema.

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 is already documented with its own semantics. The description reinforces the filterable dimensions but adds no syntax or format detail beyond the schema, and its generic 'name' filter glosses over the separate first_name/last_name parameters. 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 ('List the guests (invited contacts) of an event') and enumerates the returned fields plus the underlying endpoint. It is clearly distinguishable from the single-record siblings like evenium_get_guest, but it never explicitly contrasts with the nearby evenium_list_contacts or evenium_list_event_part_registrations.

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 filter list ('Filter by status, name, email, company or last update') implies how to narrow results, but there is no statement of when to prefer this over evenium_list_contacts or evenium_get_guest, and no prerequisites or exclusions are 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds non-annotation context: the platform availability constraint, the underlying GET endpoint shape, and the fact that location and rooms are only returned when explicitly requested — real behavioral information a caller would otherwise lack. It stops short of noting auth requirements or rate limits.

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 an endpoint reference — the returned fields are front-loaded and the platform caveat follows immediately. Minimal waste; the trailing endpoint string is the only element that is more implementer-facing than agent-facing.

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 what comes back and correctly signals that location/rooms are opt-in. Combined with full schema coverage and read-only annotations, an agent has what it needs; only the relationship to evenium_get_guest_accommodations remains unexplained.

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 both parameters (event_id, include) are already fully documented with enums and formats. The description's 'if asked, full location and rooms' loosely maps to the include parameter but largely restates the schema's own enum descriptions, 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 (hotels of an event) and enumerates the fields returned — name, group, stars, contact details, and optionally location and rooms — which lets an agent distinguish it from sibling list tools like list_guests or list_contacts. The verb is only implied by the name/title rather than written into the description, keeping it just 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?

It gives one explicit exclusion — 'Not available on the evenium.net platform' — which is genuinely useful when-to-use context. However, it offers no routing versus evenium_get_guest_accommodations, the closest sibling (guest-level hotel/room data), so the agent must infer that this tool lists event-level hotels while the sibling reports per-guest stays.

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=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely non-obvious context: only supplied fields are sent, and the change propagates to the contact's guest records everywhere — useful scope disclosure for a destructive mutation. Missing auth/rate-limit or reversal info keeps it at 4.

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 sentences, front-loaded with the WRITE marker and ending with the endpoint path. No filler; each clause carries meaning.

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 mutation with no output schema, the description supplies the essentials: partial-update semantics, blast radius across guest records, and the underlying endpoint. It omits edge-case behavior (clearing a field, email uniqueness conflicts), which prevents a 5.

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 50% and the description restates the three optional attributes already declared in the schema without adding format or constraint detail. The valuable parameter documentation (contact_id formats, the {name,value} field pairs) lives in the schema, not the description, 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 ('change') and resource (a contact) and enumerates the mutable attributes: email, company, fields. The 'WRITE:' prefix and 'change' clearly separate it from the sibling read tools and from evenium_create_contact, though no 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?

'Only what you pass is sent' establishes partial-update semantics, which implies when this is appropriate versus a full replacement. However, it gives no explicit when-to-use/when-not guidance relative to evenium_create_contact or evenium_update_guest_status.

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?

The annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=true; the description's 'WRITE:' prefix and PUT verb are consistent with them but largely restate that. It adds nothing about the destructive implication — that an existing attendance record is overwritten — nor about prerequisites such as the guest/contact needing to exist.

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 clauses: the 'WRITE:' marker and the action lead, followed by values and endpoint. Every element earns its place and nothing is buried.

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 three-parameter mutation with full annotation coverage and no output schema, the description covers intent and legal values. It still omits what the call returns and whether prior attendance data is lost, which matters given destructiveHint=true.

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 67% and both id parameters are well documented there. The description repeats the post_status enum values without adding format or constraint detail, and does not clarify the `ext:` id form or what UNKNOWN means versus clearing the status.

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?

A specific verb (set) plus resource (guest attendance/post status), with the three legal values spelled out and the underlying endpoint named. It usefully disambiguates 'post' as attendance rather than HTTP POST, but it never explains how this differs from the sibling evenium_update_guest_status, which an agent could easily confuse with it.

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 parenthetical 'for example after check-in' gives a concrete usage context, but there is no explicit when-not guidance and no mention of evenium_get_guest_post_status for reading the current value or evenium_update_guest_status as the alternative. Usage is implied rather than 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 declare write/destructive/idempotent/openWorld, so the bar is lower, and the description still adds real value by warning that setting a status "can trigger Evenium's own workflows" — a side effect not encoded in the annotations. It does not spell out that the previous status is overwritten or that triggered workflows may notify guests, which would be the next useful detail.

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 safety prerequisite, then the endpoint. No filler or 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?

For a 3-parameter mutation with annotations covering the safety profile and no output schema, the description covers what it does, the prerequisite read, and the workflow side effect. Missing only the irreversibility/overwrite consequence, which matters given destructiveHint=true.

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 67% and the schema already documents event_id/contact_id formats and the full status enum. The description's status examples (CONFIRMED, DECLINED, CANCELED) largely restate the enum rather than adding new meaning, so it neither compensates for the gap nor adds much 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?

"WRITE: set the registration status of a guest at an event" is a specific verb+resource with concrete enum examples and the underlying endpoint. It clearly separates this from the read path (evenium_get_guest_status), but does not disambiguate against the very similar sibling evenium_update_guest_post_status, which an agent could easily confuse it with.

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 tells the agent to read the current value first with evenium_get_guest_status, which is a concrete prerequisite and names the alternative read tool. It stops short of stating when *not* to use this tool or when the post-status variant is preferred.

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