Schedule it MCP by usefulapi

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the description earns credit for adding what they don't: the created event becomes visible to all users with schedule access, and Schedule It may fire notifications to linked resources under the account's own settings. Both are real side effects beyond the structured hints. It stops short of describing failure behavior, permission requirements, or what the call returns.

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

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

Three tight sentences plus the endpoint, front-loaded with the WRITE marker and the resource, then side effects, then the pre-call caution. Every clause carries information; nothing is redundant with the title or 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 10-parameter create tool with a nested custom_fields object, the description supplies the operation's meaning and side effects, and the schema carries the parameter burden. The remaining gap is the return value: with no output schema, the description never says whether the new event (or its id) is returned, which the agent needs to chain into a follow-up get or update.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all ten parameters including the REPLACES-or-clear semantics for resource_ids, notes and custom_fields. The description only gestures at 'title, dates and resources' as the fields to confirm, adding no format or syntax information 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?

The description opens with a specific verb and resource ('WRITE: create a new event') and enumerates the domain shapes (booking, shift, job, task), so the agent knows exactly what object is produced. Because every sibling operates on a different resource (group, resource, get/list/update/delete), the create-a-new-event framing is unambiguous without needing to name a 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?

It gives an explicit pre-call instruction ('Confirm the title, dates and resources with the user first') and states the outcome of a successful call (visible to everyone with schedule access), which tells the agent the stakes of the operation. It doesn't explicitly contrast with scheduleit_update_event or state when-not to use this, so it falls short of the full when/alternatives treatment.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the description's 'WRITE:' prefix largely restates the mutation behavior. It adds some value by naming the underlying endpoint (POST /api/groups), but says nothing about failure modes such as duplicate names, required permissions, or whether the new group is returned.

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 terse fragments that front-load the write intent and the resource, with zero filler. The endpoint reference is mildly redundant for an agent but not wasteful; the only criticism is extreme brevity rather than verbosity.

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 seven-parameter creation tool with no output schema, the description conveys the core action but omits what the agent gets back, such as the new group's identifier, and offers no guidance on validation or duplicate handling. It is adequate for calling the tool but not for interpreting the result.

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 each of the seven properties carries its own description with constraints such as color patterns and 0-means-no-limit semantics, so the schema does the heavy lifting. The description adds no additional parameter meaning, which makes the baseline 3 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?

The description uses the specific verb 'add' with the resource 'resource group', making the create semantics unambiguous and contrasting implicitly with the sibling update_group. It stops short of naming siblings explicitly, but an agent can readily distinguish it from get_group, list_groups, and update_group.

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 'WRITE: add a new resource group' phrasing implies this is the creation path, which is useful context, but the description never states when to prefer it over update_group or what prerequisites apply, such as whether the group name must be unique. The usage guidance is inferable 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 already cover the safety profile (not read-only, not idempotent, not destructive, open-world), so the description's job is to add context – and it does: creation may consume a licensed resource/user slot, and details should be confirmed with the user before writing. It does not state what happens if a duplicate name already exists, which is the main remaining behavioral unknown.

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: action and scope first, licensing caveat second, confirmation requirement third, endpoint last. No filler, and the most important constraints are front-loaded.

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

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

The schema is rich and annotated, but with no output schema the description never says what a successful create returns (e.g. the new resource id) or how to reference the resource afterwards, which matters for a non-idempotent create with 7 fields including a nested object. Coverage of inputs and licensing is otherwise adequate.

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 nested details object (data1..data10) is fully documented in the schema, so the description owes little. It adds no field-level semantics beyond the schema, which is the baseline-3 case.

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 (add/create) and resource (person, room, equipment) in a named account, plus the underlying endpoint POST /api/resources. An agent can distinguish it from scheduleit_create_event and scheduleit_create_group 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 'Confirm the details with the user first' line gives a useful pre-call instruction, and the WRITE prefix implies this is the creation path. However, it never names the sibling to use instead for modifying an existing resource (scheduleit_update_resource) or for checking for duplicates (scheduleit_list_resources / scheduleit_get_resource), so the when-not case must be inferred.

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 readOnlyHint=false, but the description adds value beyond them by stating the deletion is irreversible ('cannot be undone through the API') and restating the user-confirmation requirement. The leading 'WRITE, DESTRUCTIVE' label merely repeats the annotations, so it earns no extra credit, and no cascade/side-effect details are given.

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

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

Four short sentences with the destructive/irreversible warning front-loaded, followed by the usage gate and endpoint. Nothing is padded and the ordering matches decision priority.

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 2-parameter delete with full schema coverage, rich annotations, and no output schema, the description covers the only things an agent could get wrong: irreversibility, single-target scope, and the need for explicit user intent.

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 the confirm const are fully documented in the schema. The description adds only the implicit 'one event per call' framing, 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?

Specific verb + resource ('permanently delete one event or task') with scope ('one'), immediately distinguishing it from the create/get/update/list siblings. The DELETE endpoint path reinforces 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?

Explicit precondition: 'Only call this when the user clearly asked for this event to be deleted' — a real guardrail against speculative deletion. It doesn't name a sibling alternative (e.g., update_event if the user only wants a change), so it stops short of full routing guidance.

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

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

The annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false. The description adds that all fields come back, including custom fields, and it names the underlying endpoint GET /api/events/{id}. It says nothing, though, about what happens when the id is unknown or unsupported (an error versus an empty result) or about access permissions.

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 terse sentences with no filler: the scope plus the returned-field list comes first and the endpoint reference comes last. Every clause adds 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?

Because there is no output schema, the parenthetical field list usefully tells the agent what to expect from the response. With one required parameter and annotations covering the safety profile, the definition is close to complete; the only real gap is error or not-found behavior.

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 input schema has a description coverage of 100% with a single well-documented required integer event_id, so the baseline is 3. The description's "by id" adds no format, range or validation detail beyond what the schema already states.

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

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

The description gives a specific verb (retrieval), resource (event or task) and retrieval key (by id), and enumerates the fields returned, which clearly separates it from the group/resource getters among its siblings. It never explicitly contrasts itself with scheduleit_list_events, so it just misses the top score.

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

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

"By id" implies the usage context: call this when you already hold an id that a list or create call returned. There are no explicit when/when-not rules and no mention of the alternative call scheduleit_list_events, so the guidance stays implicit.

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 by structured data. The description adds one genuinely useful behavioral fact — that the response includes ALL fields, so no follow-up call is needed for a complete record — but says nothing about auth requirements, error behavior for unknown ids, or how it differs from a filtered read.

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, and the most decision-relevant fact ('ALL its fields') is front-loaded. The trailing 'GET /api/groups/{id}' is mild redundancy against the tool name, though it does help an agent map the tool to the underlying API surface.

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 single-parameter read with annotation coverage and no output schema, the description supplies what an agent actually needs: that it returns a complete record for one id. No output schema exists, so the 'ALL its fields' note does the job that a return-value description would otherwise do.

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 carries its own description ('Schedule It group id'), so the baseline is 3. The description's 'by id' restates the obvious and adds no format, range, or sourcing guidance (e.g. how to obtain a valid group_id) 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 and resource ('Get group' implied by 'One resource group by id') plus scope: a single group, not a collection, with 'ALL its fields'. This contrasts implicitly with the list_groups sibling. It stops short of naming the alternative tool outright, so it lands just below top marks.

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: an agent can infer it should call this when it has a group id and needs the complete record rather than a list. There is no explicit when-to-use statement, no exclusion (e.g. 'use list_groups to find ids first'), and no note about behavior on a nonexistent id.

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 openWorldHint=true, so safety is covered. The description adds genuinely useful behavior: it enumerates the returned field set (name, email, groups, details 1-10, colours, skills), which matters because no output schema exists. It omits error behavior for an unknown 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 short sentences, front-loaded with the resource and scope, plus the endpoint. No filler or repetition of the title.

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

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

For a simple one-parameter read with no output schema, listing the returned fields is the key missing piece and the description supplies it. Only minor gaps remain, such as behavior when the id does not exist.

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?

There is only one parameter and schema description coverage is 100%, so the schema fully documents resource_id. The description's 'by id' adds nothing beyond that, which is the expected baseline for a single fully documented 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 and resource: fetch one resource by id with all its fields. The word 'One' implicitly contrasts with the sibling scheduleit_list_resources, though it never names it 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?

Usage is implied by 'one resource by id' – an agent can infer this is for looking up a single known resource. There is no explicit statement about when to prefer list_resources or get_event over it, and no prerequisite or not-found 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 cover the safety profile (readOnlyHint, destructiveHint=false), and the description adds genuinely non-obvious behavior: default date range, default limit of 100, no paging at all, and that the API returns only a short summary unless fields are named. The semantics of the returned `owner` field are also 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?

Single tight paragraph, front-loaded with purpose then defaults, field selection, paging constraint, and the polling warning. The trailing 'GET /api/events' is the only marginally expendable fragment.

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 12 optional parameters and no output schema, the description carries the return-shape burden well by explaining that replies are short summaries and how to expand them. It never touches `workspace_id` scoping or `event_ids` vs filter interplay, but the schema documents both adequately.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: the distinction between `resource_ids` as a filter and `owner` as the returned resource linkage, and the strategy 'narrow with the filters instead' of paging given the hard `limit` cap. It does not explain `tasks_only` / `no_date_only` semantics further than the schema already does.

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

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

Opens with a specific verb+resource ('List scheduled events and tasks') and immediately clarifies the domain vocabulary (bookings, shifts, jobs). It explicitly contrasts itself with the sibling get_event, which returns ALL fields of one event, so an agent can route without opening either schema.

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

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

Gives explicit guidance on defaults ('Without date_from/date_to Schedule It uses its default date range'), on how to broaden the reply ('pass fields'), on the alternative tool for full detail ('get_event returns ALL fields of one event'), and an explicit anti-pattern with a replacement ('Do not call this repeatedly to watch for changes (use modified_after)').

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 bar is lower. The description still adds real behavioral context: without `fields` you get only a short summary, and it discloses the underlying endpoint GET /api/groups. Pagination/limit behavior is left to 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?

Two compact sentences: the resource definition is front-loaded, followed by the most decision-relevant parameter behavior and the endpoint. No sentence is filler.

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

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

For a five-parameter listing tool with full schema coverage, annotations, and no output schema, the description gives enough to call it correctly. It hints at the short-summary default, though it could say more about what the summary contains or how filtering combines.

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, establishing a baseline of 3. The description only restates the `fields` parameter pattern that the schema already explains, adding no extra semantics for name, limit, group_ids, or workspace_id.

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 resource groups') and parenthetically defines what a group is with concrete examples (Staff, Rooms, Vehicles), which separates it conceptually from labels and resources. It does not explicitly name sibling tools like list_label_groups to disambiguate, so it falls 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?

There is no statement of when to use this tool versus list_resources, list_labels, or list_label_groups, and no prerequisites or exclusions. The note about passing `fields` is a parameter tip, not usage guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value by disclosing that the default response is a truncated 'short summary' and that `fields` is needed for full records, but it omits pagination/limit behavior despite exposing a 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 short clauses, front-loaded with the purpose and the concept definition before the practical hint. No filler, though the raw endpoint path is of marginal value to an agent versus the rest of the sentence.

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, zero-required-parameter list tool with no output schema and full schema coverage, this covers what the agent needs: what the resource is, and that the default result is abbreviated unless `fields` is supplied.

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%, documenting both `limit` (1-1000, default 100) and `fields` with the pattern and example. The description's `fields` example duplicates the schema; it adds the rationale (summary vs full) but nothing about `limit`.

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 label groups) and adds a clarifying gloss that distinguishes them from labels themselves, which implicitly separates it from the sibling list_labels. It does not explicitly name that sibling, so it stops short of full 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?

It gives one actionable usage cue — pass `fields` when the short summary is insufficient — but says nothing about when to choose this tool over scheduleit_list_labels or scheduleit_get_group, and offers no 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 the safety profile is covered. The description adds only that the default response is a 'short summary' and the underlying endpoint; it says nothing about pagination behavior or result ordering beyond what the schema states.

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 the core purpose front-loaded, followed by the optional-detail hint. The trailing 'GET /api/labels' is mild implementation trivia but takes little space.

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, non-destructive, two-optional-parameter list tool with full schema coverage and clear annotations, the description supplies everything needed to select and call it; no output schema means return-value explanation is not required.

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, and the baseline is 3. The description adds marginal value by explaining that passing `fields` yields more than the default short summary, but the `limit` parameter and the field-name pattern are left entirely to the schema.

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

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

States a specific verb and resource ('List the labels that can be put on events') and adds concrete examples (Confirmed, Urgent). It does not explicitly distinguish itself from the sibling scheduleit_list_label_groups, so a reader must infer that this returns labels rather than label groupings.

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 phrase 'labels that can be put on events,' suggesting it is a lookup performed before tagging events. No explicit when-not or named alternative (e.g. list_label_groups) is given, leaving the agent to infer the choice between the two.

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 bar is lower; the description still adds real behavior beyond them: responses are summarized unless `fields` is supplied, there is no pagination, and the reply is silently capped at `limit` (default 100). It does not mention auth or rate-limit behavior, but the truncation semantics are exactly the kind of trait that prevents misuse.

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 purpose and definition, then immediately the highest-value caveat (summary unless `fields`). Dense parentheticals pack a lot into few words, though the parenthetical about groups/`owner` is syntactically awkward and interrupts the flow.

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

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

No output schema exists, so the description carries the return-value burden and does so: short summary by default, fuller shape via `fields`, at most `limit` records, no paging. Combined with the annotations covering safety, an agent has everything needed to call this correctly on the first try.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: a concrete `fields` example (id,name,email,data1), the `limit` default of 100, and the non-obvious fact that `owner`/groups are group ids rather than resource owners. It says nothing about `workspace_id`, `modified_after`, `name`, or `resource_ids`, which is why it falls short of 5.

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

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

States a specific verb and resource ('List resources') and immediately defines what a resource is (people, rooms, equipment, vehicles). It explicitly distinguishes itself from the sibling get_resource, which returns ALL fields of one, so an agent can route between list vs. get without opening either schema.

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

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

Gives concrete routing advice — pass `fields` for more than the short summary, use get_resource for the full record of one — plus a note that there is no paging and that `limit` caps the reply. It does not state explicit exclusions against other list siblings (list_events, list_groups), but the resource-vs-group relationship is clarified.

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 cover the safety profile (destructiveHint=true, idempotentHint=true, openWorldHint=true), and the description adds genuinely new behavioral detail: resource_ids replaces the entire list rather than appending, empty string clears notes/custom fields, and date/resource changes may trigger notifications. It does not contradict the destructive hint, but it also does not reconcile the partial-update framing with the destructive flag or mention failure 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?

One dense paragraph, front-loaded with the WRITE marker and partial-update rule, followed by replacement/clearing rules and then side effects. Every clause conveys a distinct constraint; nothing is repeated or padding.

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

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

No output schema exists and this is an 11-parameter mutation with nested objects, yet the description covers the critical semantics an agent needs to call it safely. Remaining gaps are error/validation behavior for invalid resource ids and confirmation of the return shape, which are modest for a partial-update endpoint.

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 foregrounding the non-obvious mutation semantics (list replacement, empty-string clearing) that are the easiest things to get wrong. It adds little beyond what the schema descriptions already state, and none of the 11 parameters' valid ranges are discussed.

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 pair ("change fields of an existing event") and immediately qualifies scope as partial-update semantics, which cleanly separates it from scheduleit_create_event and scheduleit_delete_event. An agent can select this tool without opening the schema.

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

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

Clear context for use: fields not passed remain unchanged, and empty strings are the explicit clearing mechanism. It stops short of naming alternatives (e.g. get_event to inspect before updating) or stating preconditions, so no exclusions are offered.

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

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

Annotations already declare readOnly=false, destructive=true, idempotent=true, and openWorld=true, so the safety profile is covered. The description adds a genuinely non-obvious trait: this is a partial update where omitted fields are left untouched, despite the underlying POST verb. It does not say what a bad group_id does 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?

A single dense sentence with the mutation warning front-loaded as "WRITE:" and the endpoint appended. No filler, nothing restated.

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 partial-update tool with full schema documentation and no output schema, the definition covers what the agent needs to invoke it correctly. Minor gap: no mention of authorization requirements or failure behavior for an invalid group_id.

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 every field is documented with constraints, so the baseline is 3. The sentence "only the fields you pass are changed" adds real semantic value about the seven optional parameters — it tells the agent that omitting a field means "leave as-is," which the schema cannot express.

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?

"change fields of an existing resource group" gives a specific verb and resource, and the "existing" qualifier separates it from scheduleit_create_group. It does not name any sibling or alternative explicitly, so it stops 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?

Usage is only implied: the agent can infer "use this to modify a group that already exists, use create_group otherwise." There is no explicit when-to-use versus update_event/update_resource guidance, no prerequisites, and no exclusions.

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

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

Adds real semantics beyond the annotations: selective field updates, list replacement for group_ids, and empty-string clearing of email/details. Annotations already flag destructiveHint and idempotentHint, so the description doesn't need to restate risk, but it could note that replacement of group_ids is the destructive path rather than leaving the agent to infer it.

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 clauses with zero filler, front-loaded with the "WRITE:" marker that signals mutation first. Every clause carries distinct operational 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?

Covers the mutation model, clearing semantics and list-replacement hazard for an 8-parameter tool with a nested details object and no output schema. It leaves out error behavior (e.g. what happens with an unknown resource_id) and return shape, which the agent must assume.

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 already documents the group_ids REPLACES behavior and the empty-string clearing rule, so the description mostly restates structured data. It adds a little emphasis on partial-update semantics but no new per-parameter detail (e.g. color pattern, details key range).

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?

Leads with an explicit operation class ("WRITE: change fields of an existing resource") naming both verb and resource, and the word "existing" cleanly separates it from the sibling create_resource. The endpoint reference (POST /api/resources/{id}) reinforces the target so an agent can distinguish it from update_event and update_group 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?

States the operative condition clearly: only the fields you pass are changed, so partial updates are safe. It does not name alternatives or exclusions (e.g. use create_resource for new resources, delete_event for removal), so routing still requires inference from the name.

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