AddEvent MCP by usefulapi

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the bar is lower; the description still adds real value by clarifying that nothing existing is modified and nobody is notified, plus the POST endpoint. It stops short of stating idempotency/retry behavior or auth requirements.

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

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

Three compact, front-loaded segments — operation class, effect/scope, required input, endpoint — with no filler. Every clause adds distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter create tool with no output schema, the description covers the operation's effect and required input well, and the schema carries the parameter detail. It could still hint at what is returned (e.g. a new calendar id) since no output schema exists, but 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 description coverage is 100% and all 9 parameters are documented in the schema, so the baseline is 3. The description only adds 'Needs a title', which the schema's required list already conveys; none of the other eight parameters (timezone, templates, custom_data) are elaborated on.

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 ('creates a new calendar in the AddEvent account') and immediately scopes it ('a new, empty calendar'), which cleanly separates it from addevent_create_event and addevent_update_calendar. The 'WRITE:' prefix signals the operation class up front.

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 implied usage context ('a new, empty calendar; nothing existing is changed') and a required precondition ('Needs a title'), but never names an alternative or an exclusion, e.g. to modify an existing calendar use addevent_update_calendar. Usage is inferable but not explicit.

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, but the description goes well beyond them: it discloses side effects (public event landing page and share links are created) and the notification model (no e-mail is sent, though feed subscribers see it on next sync). This is exactly the kind of consequence-level context a write tool needs.

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

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

Front-loads the WRITE marker and core purpose, then behavior, then requirements and the HTTP method. It is dense but each clause carries information; slightly long sentences keep it from being maximally tight.

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 20-parameter mutation tool with no output schema, it covers the essentials: required fields, default target, and side effects. It does not mention the returned identifier/object shape, but with no output schema that omission 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%, so every parameter is already documented, setting the baseline at 3. The description adds only the calendar_id default behavior and the two required fields, both of which the schema already states, so it does not meaningfully exceed the structured data.

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 ('creates a new event on a calendar') and roots it in the sibling landscape implicitly by clarifying the calendar target versus the other create_* siblings (calendar, rsvp_attendee). An agent can distinguish it from addevent_update_event/addevent_get_event 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?

It clarifies the key selection detail (default calendar when calendar_id is omitted) and the required inputs, which hints at how to invoke it. However it never routes the agent away from alternatives (e.g. update_event for modifying, or which sub-create to pick), so usage is only implied rather than explicit.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds genuinely non-obvious behavioral facts not derivable from them: this server suppresses confirmation/organizer notification e-mails but the event's own reminder and follow-up e-mails will later reach the address, and the e-mail must be unique per event. That is exactly the kind of consequence disclosure an agent needs before writing personal data.

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 sentences plus an endpoint: the WRITE marker and the resource are front-loaded, and each sentence carries distinct information (scope, e-mail side effects, uniqueness). Slightly dense but no filler; the trailing endpoint line is arguably redundant with the tool's function.

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 100% schema coverage, the description's job is mainly to explain consequences and constraints, which it does. It covers scope, uniqueness, and e-mail behavior; it does not say what happens on a duplicate e-mail (error vs. update) or what identifying data comes back, which an agent might want 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%, so the schema already documents email, event_id, attending and rsvp_form_data; the enum and the nested form object are self-describing. The description echoes 'one e-mail address, personal data' and the uniqueness rule but adds no format, syntax or form-key guidance beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource and an explicit cardinality/scope: 'WRITE: adds ONE RSVP attendee (one e-mail address, personal data) to an event.' It even pins the underlying endpoint (POST /events/{id}/rsvps), which cleanly separates it from the sibling update/list/get RSVP 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?

It gives a real condition for use rather than just a definition: 'only add someone who really RSVP'd.' That is a meaningful when-to-use constraint for a tool that will trigger downstream e-mails. It stops short of naming alternatives (e.g. update_rsvp_attendee for changing an existing response), so it is clear context without explicit 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds real value by disclosing the response shape (title, timezone, week start, template ids, counts, links, custom data) that no output schema provides.

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 compact sentence plus the HTTP endpoint; zero waste and the identity of the resource is front-loaded. Nothing could be trimmed without losing 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 field enumeration is what tells the agent what comes back, and it is present. What is missing is any note on error behavior for an unknown id, but that is a minor gap for a simple 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 coverage is 100% and the single parameter is fully documented in the schema, including the pointer to addevent_list_calendars and the accepted string/integer forms. The description adds only 'by id', 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 ('One calendar by id') and enumerates the fields returned, so it is clearly distinguishable from addevent_list_calendars. The trailing 'GET /calendars/{id}' pins the exact operation.

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 'by id' versus the sibling list tool, but no alternative is named and no condition or prerequisite is stated. An agent can infer the intent but is not explicitly routed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the record contains personal data with IP address and coordinates removed, and it names the underlying endpoint. It does not mention pagination or auth, but those are minor for a single-record fetch.

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 key scope front-loaded and zero filler. The trailing 'GET /subscribers/{id}' is slightly redundant with the tool name but useful for API mapping, keeping it just short of perfect.

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 carries the return-value burden, and it does flag the PII redaction (IP and coordinates removed), which is the key thing an agent needs to know about the response. It stops short of describing the full returned fields, but for a simple get-by-id tool this is close to 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 the single subscriber_id parameter (its pattern, length bounds, and cross-reference to the list tool) is already fully documented. The description's 'by id' adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope: retrieves one calendar subscriber by id, distinguishing it implicitly from the list_calendar_subscribers sibling. However, it does not explicitly name the list alternative, so it stops just short of full sibling differentiation.

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 calendar subscriber by id' implies the single-record use case versus the list tool referenced in the schema, but there is no explicit statement of when to use this versus addevent_list_calendar_subscribers or other get_* siblings. Usage 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 declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so safety is covered. The description adds the returned-field inventory and confirms a REST GET mapping, but says nothing about auth requirements, rate limits, or not-found behavior.

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

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

A single compact sentence with the resource and identifier front-loaded, followed by the returned-field scope and endpoint. It earns its place, though the trailing 'GET /events/{id}' is modestly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully lists the return payload (description, organizer, reminder, recurring rule, RSVP settings/stats, custom data, share links), giving the agent a sense of what it gets back. Missing only edge-case behavior such as not-found handling.

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 event_id parameter is already fully documented including its example and cross-reference. The description only echoes the 'evt-...' prefix format, adding no syntax or constraint detail 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 verb/resource ('One event by id (evt-...)') and enumerates the fields returned, so the agent immediately knows this is the single-record fetch. It is clearly distinguishable from the sibling list_events, which returns multiple records.

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?

'One event by id' implies the single-record use case versus listing, and the schema points to addevent_list_events for discovery. However, there is no explicit statement of when to prefer this over list_events or what to do if the id is unknown; usage must be inferred from the name.

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 genuinely useful behavior beyond that: it discloses that e-mail and form answers are returned as personal data, and that IP address and coordinates are deliberately removed — a meaningful privacy/redaction note for the caller.

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?

Extremely tight — a single sentence plus the endpoint. The key scope qualifier ('One', versus the list sibling) is front-loaded and no sentence is wasted, though the telegraphic fragment style borders on under-specification.

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 usefully compensates by naming what the response contains (e-mail, form answers) and what is stripped out. For a single-parameter read tool with full schema coverage and annotations, this is close to sufficient; only response shape/structure is left implicit.

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

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

Schema description coverage is 100% and the single parameter already documents that it is an RSVP attendee id pointing at addevent_list_rsvp_attendees. The description adds nothing about id format or accepted types (string vs integer) beyond 'by id', 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 resource and scope: 'One RSVP attendee by id', which distinguishes it from the sibling list tool addevent_list_rsvp_attendees by implying a single-record fetch. It even names the HTTP endpoint, though it does not explicitly name the sibling it differs from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'by id' phrasing implies you already have an identifier and use this for a single lookup, but there is no explicit when-to-use or when-not-to-use guidance versus the list tool. The reference to addevent_list_rsvp_attendees lives in the schema, not the description, so it isn't doing routing work here.

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 behavioral context beyond that: the default sort is newest-first, the result set is account-scoped, and the shape of what each calendar record contains. It does not discuss pagination behavior beyond what the schema says.

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 tight sentence that front-loads the scope and default ordering, then lists returned fields, followed by the endpoint. No filler or restatement of the tool name.

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 compensates by enumerating the returned fields and the default ordering, which is the key information for a read-only listing tool. Filtering and pagination semantics live in the schema; the only minor gap is any mention of total counts or how to page through large accounts.

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 page, page_size, sort_by, sort_order and calendar_ids are all documented in the schema itself. The description only echoes the default ordering (which maps to sort_by=created), adding marginal meaning. Baseline 3 is correct.

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 (List) and resource (the account's calendars), enumerates the returned fields (id, title, timezone, default flag, landing-page links, event/subscriber counts), and names the endpoint GET /calendars. An agent can distinguish it from the singular addevent_get_calendar and from addevent_list_calendar_subscribers 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?

Usage is implied by the list-shaped purpose and by the default ordering note, but there is no explicit when-to-use guidance, no statement of when to prefer addevent_get_calendar or the subscriber listing instead, and no prerequisites or scope limits mentioned. Minimum viable.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), and the description adds genuinely non-obvious behavior: page cap of 20, and that IP address and coordinates are stripped from results. It stops short of covering default status filtering or sort behavior, which live only in 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 the operation and target, followed by data shape, paging, privacy note, and endpoint in two tight sentences. The 'paged, 20 at most' clause slightly duplicates the schema but earns its place as a top-level constraint.

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 returned fields and privacy redaction. It leaves the status-omission default and sort defaults to the schema, which is acceptable given the high schema coverage, so an agent has enough to call 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 83%, so the schema already documents page, page_size, status, sort_by, sort_order and calendar_ids thoroughly. The description only echoes the page-size cap already stated in the schema, adding no new syntax or filtering semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('List people subscribed to the account's calendars'), states the returned data shape, and gives the underlying route (GET /subscribers). This distinguishes it clearly from the singular get_calendar_subscriber sibling.

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 notes paging limits but never says when to use this tool instead of get_calendar_subscriber or list_calendars, nor does it mention the status/omitted-filter caveat that drives pagination strategy. No explicit when/when-not guidance is present.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description only needs to add context. It does: it discloses the sort order ('newest first'), the returned fields (id, name), and the underlying endpoint GET /calendars/templates. Pagination behavior is not mentioned, which is the only notable gap.

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 with no filler; the resource and its distinguishing detail lead, and the follow-up guidance trails. Nothing redundant or misplaced.

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 present, the description usefully supplies the return shape (id, name) and ordering. It stops short of stating result cardinality or pagination, which for a list endpoint is the one remaining thing an agent would want.

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

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

Schema description coverage is 100% and the single optional parameter is an enum fully documented in the schema. The description restates both modes ('calendar landing page templates or embeddable calendar templates') but adds no format or defaulting detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (the account's calendar landing page and embeddable calendar templates) and its returned fields (id, name), with ordering (newest first). It is clear what the tool returns, though it never explicitly distinguishes itself from the sibling addevent_list_event_templates, 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?

The second sentence gives a downstream workflow cue: 'Use the id as landing_page_template_id / embeddable_calendar_template_id on a calendar.' That implies when the IDs are needed, but there is no explicit when-to-use or when-not, and no comparison against list_event_templates or list_calendars.

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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real value beyond them: default ordering (newest created first), the sort shift when a date filter is applied, and an explicit inventory of returned fields (title, start/end, RSVP stats, landing-page links). It omits auth/rate-limit behavior, but the core operational traits are disclosed.

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 purpose and ordering, then filters. No filler, and the endpoint tag (GET /events) is a useful trailing anchor.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing returned fields, and all 11 parameters are fully documented in the schema. Pagination mechanics are covered by the schema. Only minor gaps remain, such as guidance on combining filters or expected result-size limits.

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

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

Schema coverage is 100%, so the baseline is 3. The description earns a bump by documenting behavior the schema does not: that results are 'newest created first' by default but switch to ordering by start time once a date filter is used, which clarifies the interaction between the date params and sort_by.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search the account's events') and enumerates the returned fields, so the agent immediately knows this is a filtered read over the event collection. It never names an alternative sibling (e.g., addevent_get_event for a single event), so it falls short of full sibling differentiation.

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 ('calendar, event ids, text, date window or a custom_data pair') implies when this tool is appropriate, and the sort note implies how it behaves under a date filter. However, there is no explicit when-to-use vs when-not guidance and no pointer to sibling tools like get_event or list_calendars.

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. Beyond that, the description adds the return fields (id, name), the sort order (newest first), and the underlying API route, which is real context since no output schema exists. It omits pagination/auth details, keeping it from 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 short sentences, each earning its place, with the resource and return shape front-loaded before the downstream usage tip. Zero waste.

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 parameterless list tool, the description covers what it returns, the ordering, and how to use the result, while annotations cover the safety profile. Only minor gaps (pagination, auth) remain.

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

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

The tool takes zero parameters, so the schema has nothing to document and the baseline is 4. No parameter text is needed or missing.

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 (the account's event landing page templates) and scope, with a clear listing verb implied by the name. It does not explicitly differentiate from the similarly named sibling addevent_list_calendar_templates, 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?

It gives a useful downstream hint ('use the id as landing_page_template_id on an event'), but says nothing about when to pick this tool versus the calendar-templates or other list siblings. Usage is implied rather than guided.

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, openWorldHint=true and destructiveHint=false, yet the description adds real behavioral value: the payload contains personal data (e-mail addresses, RSVP form answers), the max page size is 20, and IP addresses and coordinates are stripped from the reply. Rate limits and permission requirements are not mentioned, keeping it short of 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?

Four dense sentences that are front-loaded with the resource and privacy note, and each sentence carries information (scope, filters, paging, data redaction). The trailing "GET /rsvps." is near-redundant 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?

With no output schema, the description carries the burden of describing the return, and it does so adequately: the fields of interest (emails, form answers), the redaction of IP/coordinates, and the paged 20-per-page shape. Only omission is the default page size and the empty-filter behavior, both partly covered by 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 86%, so the schema already documents paging, sorting, and the id arrays. The description only restates the filterable dimensions (calendar, event, response going/maybe/not-going) without adding syntax, defaults, or interaction rules beyond what the schema provides; 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 gives a specific verb+resource ("List RSVP attendees") and immediately scopes it with the data returned and the supported filters. It is clearly distinguishable in practice from addevent_get_rsvp_attendee (singular) and addevent_create_rsvp_attendee, but it never explicitly routes the agent away from those 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?

"Filter by calendar, event or response" plus "read only what the task needs" implies when and how narrowly to call it, but this is guidance about parameters rather than tool selection. No alternative tool is named and no when-not-to-use condition is 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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds return-field shape (id, name), ordering (newest first), and the underlying GET endpoint, but says nothing about pagination or result size for a list operation. Useful additions above the annotation baseline, but 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 clauses, zero filler, and the core resource plus return shape is front-loaded before the workflow hint and endpoint. Every sentence earns its place.

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?

A zero-parameter read-only tool whose annotations cover the safety profile and whose description covers the return fields and the intended downstream use. The only omission is pagination/result-limit behavior for a list call, 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?

The tool takes zero parameters, so there is no parameter surface to document and the baseline is 4. The description's explanation of returned fields (id, name) is output-related rather than parameter-related, but that does not detract from an already-complete zero-param contract.

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 account's RSVP forms), names the projected fields (id, name), and gives ordering (newest first). It is immediately distinguishable from the other list_* siblings, which cover calendars, events, attendees, and templates.

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 provides real workflow context: 'Use the id as rsvp_form_id on an event,' telling the agent this is a discovery/ID-lookup step feeding a subsequent call. It lacks an explicit when-not or an alternative tool, but the usage is clearly framed.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful fact that entries include a current UTC offset and cites the underlying endpoint, but says nothing about pagination or default return volume despite the limit parameter.

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

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

Three compact sentences with the core purpose front-loaded and no wasted wording; the endpoint reference is a minor but harmless addition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read-only lookup with full schema coverage and annotations supplying the safety profile, the description covers what the tool returns and how values are used. Only pagination/volume behavior for the limit parameter is left unstated.

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 are already documented in the schema. The description notes an optional text filter on the name, which mildly reinforces the 'search' parameter but adds no syntax or caveats beyond what the schema provides — the baseline is appropriate 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 and resource — listing timezone names AddEvent supports — and clarifies the content (current UTC offset). It is trivially distinguishable from all sibling tools, which deal with calendars, events, and RSVP entities rather than static reference data.

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 'use them as the timezone of events and calendars' explains what the returned values are for, which is helpful context, but there is no explicit guidance on when to call this tool or how it relates to alternatives. Usage is implied 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?

Goes well beyond the annotations: it spells out patch semantics (omitted fields stay), which mutations are externally visible and can propagate to calendar-feed subscribers, and that the operation is not undoable because no previous values are retained. The annotations flag destructiveHint/idempotentHint generically; the description explains the actual blast radius.

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

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

Front-loaded with the operation type and scope, then risk, then the endpoint. Every sentence carries distinct information and nothing is 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 10-param mutation with a nested custom_data object and no output schema, it covers the essentials an agent needs (what changes, what stays, what leaks publicly, irreversibility) and the annotations cover the safety profile. It remains thin on the nested custom_data semantics and the template-id fields.

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?

With 60% schema coverage across 10 params, the description adds meaningful semantics: the partial-update rule tells the agent that any parameter it omits is preserved, which is the key behavioral fact for a 10-field PATCH. It also groups title/description/timezone as publicly visible, though it says nothing about custom_data, weekday_begin, or the template-id fields.

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 WRITE marker and a specific verb+resource ('changes fields of an existing calendar'), and the partial-update scope is stated immediately. It is unambiguously distinct from the sibling create_calendar and update_event 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?

Gives a clear prerequisite ('read the calendar first' because prior values are not kept), which routes the agent to the get_calendar sibling. It does not state when NOT to use this tool or name an alternative for related-but-different operations, so it falls short of full when/when-not guidance.

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

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

Annotations already flag destructiveHint=true, but the description adds the crucial consequence: changes go live on the landing page and share links, and subscribers are notified on next sync. It also warns that no previous values are kept, which is behavior beyond the annotation. It even describes the side effect of time/location changes notifying real people.

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 dense sentences plus an endpoint tag. It is front-loaded with the operation type (WRITE) and partial-update rule, then consequences, then the read-first prerequisite. Slightly long but every clause is informative.

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, open-world update tool with no output schema, it covers the critical behavioral aspects: partial update, live effect on shared links and subscribers, irreversibility requiring prior read, and the endpoint. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 21 parameters in detail. The description only adds the partial-update semantics and the PATCH endpoint, but does not provide additional parameter-level guidance. A baseline 3 is appropriate when the schema carries the full parameter documentation.

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: 'changes fields of an existing event', and immediately specifies partial-update semantics ('only the fields you pass; the rest stay'). It maps to PATCH /events/{id}. It is easily distinguished from the sibling create_event and update_calendar.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear operational instruction: 'No previous values are kept: read the event first.' This tells the agent to call get_event before updating to avoid data loss. However, it does not name the get_event sibling explicitly or discuss alternatives like re-creating an event.

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 side-effect semantics: changing the stored e-mail redirects reminder/update e-mails to that person, and the server never fires confirmation or organizer-notification e-mails. These are exactly the non-obvious consequences an agent needs before mutating an attendee and are not present in the readOnly/destructive/idempotent hints.

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:' intent marker and closing with the endpoint. Every clause carries distinct information (scope, field behavior, e-mail routing, notification non-behavior) with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with annotations and no output schema, the description covers safety-adjacent side effects, partial-update semantics and e-mail routing well. It stops short of describing failure modes (e.g. invalid attendee_id) or the response payload, but those are minor given the annotation coverage.

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?

With 75% schema coverage the schema already documents most parameters, but the description maps the editable fields ('email, response or form answers') onto the params and adds the partial-update rule that only supplied fields change. It also names the 'attending' enum conceptually as 'response', compensating somewhat for that undocumented parameter.

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 ('changes'), a precise resource ('ONE RSVP attendee') and explicit scope ('email, response or form answers; only the fields you pass'), plus the underlying endpoint PATCH /rsvps/{id}. An agent can distinguish this update tool from the sibling list/get/create RSVP tools without reading 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?

'only the fields you pass' implies this is a partial-update tool, which is useful context. However it never names or contrasts alternatives such as create_rsvp_attendee or get_rsvp_attendee, nor states when this tool should be preferred, so usage remains implied rather than explicit.

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