TrackingTime

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so calling this a 'write operation' adds nothing. The description omits what an agent actually needs: that the call is non-idempotent (retrying can create duplicate comments), that auth is required, and what happens on an unknown task_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?

A single tight sentence with the operation front-loaded and no filler. The endpoint path is arguably redundant with the tool name, but it costs little and is not 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 9-parameter, non-idempotent write tool with no output schema, the description leaves key things unaddressed: the text/notes/comment ambiguity, auth/account_id requirements, and retry semantics. Annotations cover the safety profile, but the content-parameter confusion is a real risk of misuse.

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 56% and the description adds no parameter meaning at all. Critically, there are three apparently interchangeable content parameters (text, notes, comment) and the description never says which one carries the comment body or how they interact; it also doesn't mention that task_id is required.

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

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

States a specific verb and resource ('Adds a comment to a task') and even names the REST endpoint, so the operation is unambiguous. It does not differentiate from siblings like list_task_comments or delete_task_comment, but the verb makes the direction of the operation obvious.

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

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

No when-to-use guidance, no prerequisites, and no mention of the nearby sibling tools. The only extra line, 'Limitations: write operation,' is a property of the tool, not guidance about when to choose it.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds genuinely useful context beyond that: it is a 'sensitive write operation', demands explicit confirm=true, and warns that the endpoint is global and does not prefix account_id — a non-obvious routing detail. It stops short of describing irreversibility or 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?

Three tight sentences, front-loaded with the verb/resource and then the routing and safety constraints. No filler, though the raw endpoint string is somewhat mechanical.

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 destructive mutation with no output schema, the description covers safety and scoping adequately but leaves parameter semantics gaps and does not address what happens to the request after approval/rejection. Minimum viable rather than 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 coverage is only 50%, so the description should compensate, but it only surfaces token and timeoff_id (via the URL) and confirm. It says nothing about the action/status/approved/access_token/app_password parameters, leaving several fields ambiguous — notably the overlapping action enum and approved boolean.

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 pair ('approves or rejects') and resource ('time off request'), and even names the underlying endpoint. An agent can distinguish it from siblings like create_timeoff, update_timeoff, get_timeoff and delete_timeoff 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?

It notes the operational constraint ('requires confirm=true') and the endpoint's global scoping, but gives no guidance on when to use this versus update_timeoff or delete_timeoff, nor any prerequisite/role context. 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so 'Limitations: write operation' largely repeats structured data rather than adding context. It does not say whether the archived customer is recoverable (e.g., via restore_customer), whether data is retained, or what permissions are needed.

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 very short sentences that are front-loaded with the action, which is good. The second sentence, however, only restates what the annotations already declare and does not earn its place, making the definition terse without being 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 mutation tool with no output schema and a large set of closely related customer operations, the definition omits the key distinctions an agent needs: archive vs delete semantics, reversibility, and effects on the customer's projects/tasks. Annotations cover the safety profile, but the description does not complete the picture.

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 83%, so the schema carries most parameter meaning (auth tokens, account_id, base_url). The description's path template '/customers/close/:customer_id' confirms customer_id is the resource identifier, but adds no new format or constraint 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?

States a specific verb+resource ('Archives/closes a customer') and even names the endpoint, so the core action is unambiguous. However, it never distinguishes itself from close siblings like delete_customer, restore_customer, or update_customer, leaving the agent to infer whether archive is a soft-close or a destructive removal.

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 when-to-use guidance at all — no conditions under which an agent should archive rather than delete, restore, or update a customer. The only hint ('Limitations: write operation') is a capability note, not a usage rule, so the agent must guess from the sibling list.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so 'write operation' largely restates structured data. The description does add one piece of novel context — that archiving 'affects project visibility' — but omits reversibility, the confirm-required flow, and non-idempotent retry behavior, all of which matter for a destructive mutation.

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, front-loaded sentences with the operation and its endpoint stated first. Slight waste in 'write operation', which is already covered by annotations, but nothing else bloats the text.

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

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

For a destructive, non-idempotent mutation the description covers the basic identity and the visibility side effect, and annotations plus an 86%-covered schema carry the rest. However, it never says whether archiving is recoverable via restore_project, which is the key question an agent needs answered before invoking it.

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 required confirm and credential parameters are already documented in the schema. The description only echoes project_id via the endpoint path and adds no format, aliasing, or multi-workspace guidance beyond what the schema 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?

States a specific verb pair (archives/closes) and the resource (project), and even names the endpoint /projects/close/:project_id. It is clear what the tool does, but it never distinguishes itself from close siblings like delete_project, update_project, or restore_project, so the agent must infer which one applies.

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

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

There is no guidance on when to archive rather than delete, update, or duplicate a project, and no mention that restore_project is the inverse. Usage is only implied by the tool name; the description adds no routing information.

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, readOnlyHint=false, and idempotentHint=false, so 'destructive write operation' largely restates structured data. The description does add the endpoint path and the account-existence precondition, but omits what 'archive/close' actually changes (reversibility, status side effects).

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

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

Two tight sentences with the action and endpoint front-loaded and constraints following. No filler, nothing to trim.

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

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

For a simple single-task mutation with no output schema, the description covers the action, endpoint, and main precondition. It could say more about whether archiving is reversible and how it differs from stop/delete, but it is close to 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 86%, so the schema already documents task_id, confirm, base_url, account_id, and auth fields. The description adds no parameter-level meaning beyond what the schema provides, which is the expected baseline here.

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

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

States a specific verb ('Archives/closes') and resource ('a task') and even cites the endpoint '/tasks/close/:task_id'. It does not, however, explicitly distinguish itself from close-sounding siblings like stop_task, delete_task, or restore_task, so an agent must infer the boundary.

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?

Provides one precondition ('task must exist in the target account') but gives no guidance on when to choose archive_task over delete_task, stop_task, or restore_task, nor any exclusions. 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the permission requirement and the concrete endpoint. It stops short of saying whether the archive is reversible (restore_user exists) 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?

Two short clauses with the operation front-loaded and limitations second; no filler. It is tightly sized, though the endpoint restatement is slightly redundant with the tool's purpose.

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

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

For a 7-parameter destructive tool with no output schema, the description covers the essential decision inputs: what it does, that it is destructive, and that permissions are required. Missing only reversibility and any notion of what happens to the user's data, which would round it out.

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

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

Schema description coverage is 86%, so the schema already documents confirm, base_url, api_token, account_id, access_token, and app_password. The description adds no parameter-level detail such as user_id format or account_id requirements, 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 ('Archives/closes a user') plus the underlying endpoint /users/close/:user_id, which pins down the operation precisely. It is distinguishable from the sibling restore_user, though the description never names that counterpart, so the differentiation is implicit rather than explicit.

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

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

The 'Limitations' clause tells the agent this is a destructive write requiring user-management permissions, which is useful context for deciding whether to call it. However, it never states when to use this versus restore_user or update_user, nor any preconditions beyond permissions, so usage guidance is only implied.

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

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

Annotations already declare write and non-idempotent behavior, so the description doesn't need to restate that. It adds genuinely useful context: the operation is a write, and visibility of projects/users depends on role, which is a real constraint an agent won't get from annotations.

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

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

Single tight sentence plus a limitation clause. Front-loaded with the action. No wasted words, though the endpoint path is somewhat redundant with 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?

For an 8-parameter mutation tool with no output schema, the description is thin. It covers the safety-relevant limitation (role-based visibility) but leaves parameter semantics, especially the project_ids/projects alias and account_id requirement, unclear.

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 63%, and the description adds no parameter meaning at all. It doesn't clarify project_ids vs projects (the alias), whether user_id can be a list, or what account_id does beyond what the schema already says. For 8 parameters with partial coverage, more clarification is expected.

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 (Assigns) and resource (projects to a user) and gives the endpoint path, making it unambiguous against siblings like list_user_projects or assign_users_to_schedule.

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 name and endpoint, but there is no explicit when-to-use guidance, no mention of when to prefer list_user_projects or how to remove assignments. It doesn't name any alternative tool.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description's 'sensitive write operation; requires confirm=true' largely restates the schema's confirm const and the destructive annotation, adding little new behavioral context (no auth, side effects, or reversibility detail).

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

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

Two short sentences, front-loaded with the action and endpoint, then the constraint. Minimal waste, though the endpoint restatement is somewhat redundant with the 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?

For a 10-parameter destructive mutation with no output schema, the description covers the crucial confirmation gate and sensitivity flag. It omits the polymorphic 'users' shape and the 'to'/'from' range semantics, but the schema carries part of that load and no output contract needs explaining.

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 60%, so some parameters (confirm, base_url, api_token, account_id, access_token, app_password) are documented in the schema itself. The description reinforces the confirm requirement but says nothing about the undocumented/ambiguous 'users' (array vs number vs string), 'to'/'from', or schedule_id semantics, so it doesn't compensate for the remaining coverage gap.

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 ('Assigns users to a schedule') and pins the exact endpoint GET /schedules/:schedule_id/users/assign. This clearly distinguishes it from siblings like remove_users_from_schedule and assign_user_projects.

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 'Limitations' clause establishes a precondition (requires confirm=true) and flags the operation as sensitive, which implies caution. However, it never says when to prefer this over remove_users_from_schedule or how it relates to other assignment tools, leaving routing guidance 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 destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the 'destructive write operation' clause largely restates structured data. The phrase 'payload replaces/updates fields according to API behavior' hints at partial-vs-full update semantics but is too vague to be actionable, and no auth/permission or partial-failure behavior is described.

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

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

Two compact sentences, front-loaded with the operation and endpoint. The trailing 'Limitations' sentence is short but partly padding since annotations already carry the destructive flag.

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

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

For a destructive, non-idempotent batch mutation with no output schema, the description should explain how tasks are identified and matched, what a partial failure does, and how it relates to update_task. None of that is present, leaving real gaps for a 7-parameter write tool.

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

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

Schema description coverage is 86%, so the schema already documents confirm, base_url, account_id, and the token aliases. The description adds nothing about the shape of the tasks array (e.g. whether each entry needs an id, which fields are updatable) — the single most important parameter remains unexplained in both places.

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 ('Updates tasks in batch') and names the endpoint, so the operation is unambiguous. It implicitly distinguishes itself from the single-record sibling update_task via 'in batch', though it never names that alternative 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?

There is no statement of when to use this over update_task or update_events_batch, no prerequisites, and no exclusions. The agent must infer that 'batch' means multiple tasks in one call.

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 agent knows this is a safe read operation. The description adds 'read-only calculation' which reinforces this but doesn't add much beyond the annotations. It doesn't describe return format, rate limits, or other behavioral traits.

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 short sentences with no wasted words, front-loading the core purpose. It efficiently conveys the essential information without unnecessary detail.

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 tool with no output schema and incomplete parameter documentation, the description is insufficient. It doesn't explain what the returned amount represents (hours? days?), how to use the parameters, or when to prefer this over similar tools. The agent lacks critical context to invoke 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 56%, so the description should compensate for undocumented parameters. However, it provides no parameter information at all. Key parameters like 'to', 'from', 'user_id', and 'policy_id' lack descriptions in both the schema and the description, leaving agents to guess their meaning.

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 clear verb+resource: calculates time off amount via GET /timeoffs/calculate_amount. This distinguishes it from sibling timeoff tools like get_timeoff_balance (which retrieves balances) and create_timeoff (which creates records). However, it doesn't clarify how it differs from get_timeoff_balance, which also seems related to time off calculations.

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 no guidance on when to use this tool versus alternatives like get_timeoff_balance or other timeoff-related tools. It simply states what it does without context about appropriate scenarios or 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?

Annotations already declare readOnly=false, openWorld=true, idempotent=false and destructive=false. The description adds value beyond them by flagging the permission requirement in the target account and confirming custom fields can be supplied during creation, though it does not restate the non-idempotent behavior or describe the response.

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

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

Three short sentences front-load the core action and endpoint, then add capability and constraints. Nothing is redundant, though the 'Limitations:' fragment is slightly clipped rather than fully developed.

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 should cover creation semantics, permissions, and the custom-fields capability, which it does. Minor gaps remain around what 'name' must contain and multi-workspace account_id handling, but these are 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 71%, so most parameters (base_url, api_token, account_id, access_token, app_password) are self-documented. The description adds only the note that custom field values are supported, matching the custom_fields parameter, and says nothing about the required 'name' parameter, which the schema leaves undocumented.

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 customer') and even names the underlying endpoint (POST /customers/add), which makes it easy to separate from update_customer, archive_customer, and delete_customer. It stops short of explicitly naming those siblings or clarifying scope, so it is clear but not maximally differentiated.

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 notes it is a write operation requiring account permissions, which implies a context of use, and mentions that custom field values can be set at creation time. However, it never states when to prefer this over update_customer or how it relates to list_customers, so usage guidance is only implied.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the write/non-idempotent profile is covered. The description's "write operation" line largely repeats that, though the POST path adds a small amount of context. It does not disclose auth requirements, what happens on duplicate names, or 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?

Two short sentences, front-loaded with the core action and then the constraint, with no filler. The "Limitations:" label is slightly odd for what is really a required-parameter note, but the text is compact and earns its 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 an 11-parameter mutation tool with no output schema, the description covers the purpose and the two enum-bearing required params. It omits guidance on the auth parameters (api_token/app_password/access_token), the multi-workspace account_id requirement, and any return/error behavior, leaving meaningful gaps for an agent configuring the call.

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 55% with 11 parameters, several of which (name, color, notes, cf_index, api_token, access_token, app_password) have no schema description. The description only restates that value_type and filter_object_class are required, which the schema's required array already conveys, and the object-class list duplicates the enum. It adds essentially nothing beyond the structured 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?

States a specific verb and resource (creates a new custom field) and scopes it by naming the object classes it can attach to (task, project, event, user, customer), which distinguishes it from siblings like create_enum_option and update_custom_field. The API endpoint is also given, so an agent knows exactly what operation this is.

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 states that this is a write operation and that value_type and filter_object_class are required, which is implied usage guidance for creating a field. However, it never says when to choose this over update_custom_field, create_enum_option, or how it relates to list/get custom field tools, so no alternatives or exclusions are given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so most of the safety profile is provided structurally. The description adds the meaningful constraint that a pre-existing enum custom field id is required, plus the underlying endpoint, but redundantly restates 'write operation'.

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

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

Two tight sentences with the primary action front-loaded and the constraint second. Nothing is padded, though the endpoint string adds little selection value.

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 write tool with no output schema and 11 parameters, the description covers the core action and its precondition adequately but leaves most parameter meanings and any return/error behavior unaddressed. It is minimally complete rather than thorough.

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

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

Schema coverage is only 45% and the description compensates for almost none of it, documenting neither the required 'name' semantics nor optional fields like color, index, notes, and enabled. It only alludes to custom_field, leaving the bulk of the 11 parameters ambiguous.

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 enum option for an existing custom field'), which clearly distinguishes it from create_custom_field and update_enum_option. The parent resource (custom field) fixes the scope precisely.

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 prerequisite 'requires an existing enum custom field id' gives partial when-to-use context, telling the agent this cannot create a field from scratch. However, it never contrasts itself with update_enum_option or list_enum_options, so the selection logic is left to inference.

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 and openWorldHint=true, so the 'write operation' note is largely redundant. The description adds useful context on optional capabilities (task/project linking, notes, repeating, custom fields) and mandatory inputs, but says nothing about idempotency, auth requirements, or side effects beyond what annotations cover.

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

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

Two tight sentences, front-loaded with the action and endpoint, then the capability summary, then the hard constraints. No filler and every clause carries 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 21-parameter mutation with no output schema and thin schema descriptions, the description covers the essentials (required fields, main feature groups) but omits much of the parameter surface and any auth/permission or return behavior. Adequate as a minimum viable definition, not 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 only 24% across 21 parameters, so the description must compensate. It does name the required trio (start, end, timezone) and groups optional fields (task/project link, notes, repeat config, custom fields), which adds real meaning, but it leaves many parameters undocumented (duration, event_type, frequency, repeat_every, end_repeat, name aliases, auth/base_url).

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 time event') and even names the underlying endpoint POST /events/add, which clearly separates it from list_events, get_event, update_event and create_events_batch. It does not explicitly name those siblings, 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 conveys scope and prerequisites (write operation; start, end and timezone are required) and lists supported features, which implies when to use it. However it never states when to prefer a sibling such as create_events_batch or track_task, nor any exclusions, so guidance is 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 already declare readOnlyHint=false and idempotentHint=false, and the description merely restates 'write operation' rather than adding value. Critically, it says nothing about partial-failure behavior, whether a failed entry aborts the whole batch, auth requirements, or any size cap on the batch — exactly the traits an agent needs for a non-idempotent batch write.

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 with the core action front-loaded and no padding. The 'Limitations' clause is weak on substance but does not waste much 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 six-parameter, non-idempotent batch mutation with no output schema, the description omits what an agent most needs: how the batch payload is shaped, what happens on partial failure, and whether retries are safe. Annotations cover only the safety profile, leaving these gaps unaddressed.

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 base_url, account_id, and the auth fields. The description's 'batch payloads' is the only nod to the events parameter and adds no format, size, or shape 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 and resource ('Creates time entries in batch'), which cleanly separates it from the single-entry create_event sibling. It does not, however, explicitly name create_event or update_events_batch as the alternative, so the differentiation is implied rather than stated.

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

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

There is no guidance on when to use this batch tool versus create_event or update_events_batch, nor any prerequisites. The 'Limitations' sentence gestures at usage constraints but resolves to nothing actionable ('accepts API-supported batch payloads').

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, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is largely carried by structured data. The description adds that this is a 'sensitive write operation' requiring explicit confirmation, which usefully reinforces the guardrail, but says nothing about side effects, reversibility, or error 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?

Two short sentences, front-loaded with the core action and then the critical limitation. The endpoint reference is arguably redundant, but nothing is padded and the key constraint (confirm=true) is not buried.

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

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

For a 14-parameter destructive mutation with no output schema and less than half of parameters documented, the description is far too thin. An agent gets the confirm gate but no guidance on required business fields, date formatting, or workspace/account selection when the user belongs to multiple 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?

With 14 parameters and only 43% schema description coverage, the description must compensate for undocumented parameters, and it does not. It mentions only confirm=true, which is already documented in the schema, leaving amount, spent_date, project_id, category_id, customer_id, and others entirely unexplained.

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 an expense') and even names the underlying endpoint, which is enough to separate it from update_expense, delete_expense, and list_expenses. It stops short of explicitly contrasting itself with those siblings, so it falls just below the top band.

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?

'Limitations: sensitive write operation; requires confirm=true' gives a real usage precondition, which is more than most definitions offer. However, it gives no when-to-use context (e.g. when to create vs. update an expense, or which fields are needed for a valid record), so usage is only partially covered.

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, and destructiveHint=false, so the 'write operation' statement merely restates structured data. The one added behavioral detail is that creation happens via GET /holidays/add, which is a useful quirk. No auth/permission or side-effect context is provided.

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 purpose is front-loaded, which is good. However, the trailing 'confirm is not required by the Excel' clause is unclear filler that consumes space without earning it.

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

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

For a 7-parameter mutation with no output schema, the description omits required auth context (the token/account parameters), the meaning of date/name, and any indication of what happens on success or duplicate. Annotations cover the safety profile but not enough to fill this gap.

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

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

Schema coverage is 71%, with the auth/URL params documented but the two core fields (date, name) left undescribed in the schema. The description adds no parameter meaning for these gaps, so it neither compensates nor detracts.

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 holiday'), which cleanly distinguishes it from siblings like update_holiday, delete_holiday, and list_holidays. It also references the underlying endpoint, though it doesn't explicitly call out differentiation from near-name 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?

No when-to-use or when-not-to-use guidance relative to alternatives such as update_holiday or create_timeoff. The clause about 'confirm is not required by the Excel' is opaque jargon that does not help an agent decide when to invoke this tool.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds 'sensitive write operation; requires confirm=true', which reinforces the confirmation gate, but the confirm requirement is already documented in the schema's const/description, so the added value is modest. Nothing about side effects beyond creation (e.g. whether it emails the customer) is 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 terse sentences with the operation front-loaded and the constraint immediately after. No filler, though the endpoint string is arguably redundant with the tool name for an agent that cannot call URLs directly.

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

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

For a destructive, non-idempotent write with 11 parameters and no output schema, the description covers the confirmation gate but not the auth parameter interactions (access_token vs api_token vs app_password) or the behavior of the unlabeled invoice fields. Annotations carry the safety story, so the gap is real but not severe.

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

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

Schema description coverage is only 55% across 11 parameters, so the description is expected to compensate and does not. It only echoes the confirm requirement already stated in the schema, and mentions account_id only implicitly through the endpoint path; terms, qr_file, customer_name, customer_address and payment_details are left with no semantics anywhere.

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 an invoice') and even names the underlying endpoint, which distinguishes it cleanly from update_invoice, delete_invoice, export_invoice and send_invoice in the sibling list. It lacks any explicit sibling differentiation in prose, so it stops short of a 5.

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

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

The 'requires confirm=true' line tells the agent a prerequisite for invocation, which is genuine usage guidance. However, there is no when-to-use vs. alternative (e.g. when to use this versus create_expense or send_invoice afterwards), and no when-not-to-use 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=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the permission requirement, which is useful behavioral context, but it does not mention non-idempotency or what happens on duplicate creation.

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

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

Two sentences that are front-loaded with the core action and endpoint, then list supported features and limitations. No wasted words, though the limitations could be integrated more smoothly.

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 incomplete schema descriptions for 12 parameters, the description should provide more detail about required fields, authentication options, and return behavior. It covers the essentials but leaves gaps for an agent to infer.

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

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

Schema description coverage is only 42%, so the description should compensate. It mentions linking a customer, custom fields, public visibility, and estimated time, which maps to some parameters, but it omits several parameters such as default_view and account_id from the description.

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 (creates) and resource (project), and names the endpoint POST /projects/add. It does not distinguish itself from the many sibling create_* tools or from duplicate_project, but the purpose is unambiguous.

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

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

The description notes it is a write operation and requires permissions to create projects in the target account, which implies when it is usable. However, it gives no explicit when-to-use guidance versus alternatives like duplicate_project or update_project.

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 and destructiveHint=false, and the description merely restates 'write operation'. It offers no insight into auth requirements (despite api_token/access_token/app_password params), what gets persisted, sharing semantics, or non-idempotency, so it adds little beyond the annotation block.

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 short and front-loads the action, which is good, but the second sentence is garbled and wastes space on an unclear 'Excel' reference rather than useful detail.

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 11-parameter, zero-required, write-capable tool with no output schema, the description omits critical context: what a report consists of, which credential parameter to pass, and what happens on success/failure. It is not sufficient for an agent to invoke it confidently.

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

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

Schema description coverage is only 45% across 11 parameters, and the description clarifies none of them — no explanation of data, name, type, doc_type, recipient_users, or which credential fields are needed. This leaves a large documentation gap that the description fails to compensate for.

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 saved/shared report') and even names the underlying endpoint (POST /docs/add), which lets an agent distinguish it from update_report/delete_report/list_reports. It does not, however, differentiate it from the many other create_* siblings or clarify what a 'report' is in this product.

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 indication of when to use this tool versus update_report, list_reports, or refresh_report_share_token. The only usage-adjacent remark is that 'confirm is not required by the Excel', which is confusing and does not help tool selection.

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=false, and openWorld=true, so the safety profile is largely covered. The description adds the confirm=true requirement and the 'sensitive write' framing, which is consistent and mildly useful, but it does not disclose side effects, permission needs, or what the created schedule affects.

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, front-loaded sentences with no filler; the core action and the confirm constraint both land immediately. Efficiency is good, though a slightly longer description would have room to document the parameters it omits.

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 19-parameter destructive tool with no output schema and low schema description coverage, the definition is far too thin. It omits what a schedule contains, what happens on creation, and how most parameters behave, leaving the agent under-equipped 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?

With 19 parameters and only 32% schema description coverage, the schema does not carry the burden, so the description should compensate. Instead it mentions only confirm=true and adds nothing about the day fields, users, frequency, or credentials, leaving most parameters semantically opaque.

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 schedule') and even names the endpoint used, so the agent knows exactly what action is taken. It does not, however, differentiate itself from near siblings like update_schedule, delete_schedule, or assign_users_to_schedule.

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 the confirm=true prerequisite, which is a useful usage constraint. But it offers no guidance on when to prefer create_schedule over siblings such as update_schedule, list_schedules, or create_event, so the agent must infer selection from the name alone.

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 and destructiveHint=false, so "write operation" mostly restates structured data. The description does add value by flagging the permissions requirement, but it stays silent on the non-idempotent behavior (idempotentHint=false) and on what creation returns, leaving gaps even under the lower annotation-backed bar.

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 action front-loaded and the constraint placed last. Efficient, though the raw HTTP endpoint reference is marginally low-level for a tool description.

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

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

For a 13-parameter write tool with no output schema and no return-value contract, the description covers the high-level surface but leaves the non-idempotency, type enum, and most parameter meanings undocumented. It is enough to attempt a call but not enough to call it confidently.

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

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

Schema description coverage is only 38% across 13 parameters, so the description is expected to compensate. It names four functional parameters (users, project, custom fields, billable), which merely echoes schema property names and adds no semantics, while the PERSONAL/EVERYONE type enum and most auth/account parameters remain unexplained.

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 ("Creates a new task") plus the underlying endpoint POST /tasks/add, and it enumerates the main capabilities (users, project link, custom fields, billable). It does not distinguish itself from close siblings like create_project or batch_update_tasks, 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?

Usage is implied by the stated limitation ("write operation; requires permissions to create tasks in the target account/project"), which gives the agent a permission prerequisite. However, there is no explicit when-to-use/when-not guidance or routing to alternatives such as batch_update_tasks, so it is only minimally 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 declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the 'sensitive write operation' label and the confirm requirement, but does not explain side effects such as whether the request needs approval or what happens on repeated calls — leaving a modest gap beyond the annotations.

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

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

Two tight sentences, front-loaded with the action and followed by the constraints. The endpoint reference is slightly unusual but informative; there is no 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 mutation tool with no output schema but rich annotations, the definition covers the critical safety gate (confirm). It still omits which fields are needed to build a valid request and what the result looks like, which matters given 11 loosely documented parameters.

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 11 parameters and only 55% schema description coverage, the description is expected to compensate, but it only mentions confirm=true — which the schema already documents. Core fields like to, from, notes, user_id, and policy_id get no explanation in either place, so the agent must guess their meaning.

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 time off request') and even names the underlying endpoint, so the agent knows exactly what the tool does. It doesn't explicitly differentiate from the adjacent update_timeoff/delete_timeoff/approve_timeoff siblings, but the create semantics are unambiguous from the verb.

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 a real prerequisite ('requires confirm=true') and flags the operation as sensitive, which is usable guidance. However, it never says when to prefer this over alternatives such as creating via a policy, nor how it relates to the approval flow implied by the approve_timeoff sibling.

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, idempotentHint=false, and readOnlyHint=false. The description adds useful context beyond that – it flags the operation as 'sensitive' and discloses the required confirm=true gate, which the annotations do not convey. It omits reversibility and what the created policy affects, 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?

Two tight sentences with the action front-loaded and the caveats second; nothing is padded. It is effectively sized for the operation, though it could fold the endpoint detail away as it adds little for an agent.

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

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

For a mutation tool with no output schema and 9 parameters at 67% coverage, the annotations plus the confirm disclosure cover the safety profile adequately. However, the description says nothing about workspace scoping (account_id) or the shape of the policy being created, leaving meaningful gaps.

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

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

Schema coverage is 67%, above the midpoint, so baseline 3 applies. The description only restates the confirm=true requirement already documented in the schema and adds no meaning for parameters like users, account_id, or the auth aliases.

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 time off policy') and even names the endpoint, so the operation is unambiguous and distinguishable from siblings like create_timeoff or update_timeoff_policy. It does not explicitly contrast against those siblings, so it stops short of a 5.

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

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

The description gives a precondition (confirm=true) but no when-to-use or when-not-to-use guidance, and never routes the agent toward or away from alternatives such as create_timeoff or update_timeoff_policy. Usage is only implied by the required confirmation flag.

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 and openWorldHint=true, so calling it a 'write operation' is largely redundant. It does add one genuinely useful non-annotation detail — the requirement for group-management permission — but omits mutation side effects such as duplicate-name behavior or whether members are notified.

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 action and endpoint, with no padding. The 'write operation' clause is slightly redundant with the annotations but does not waste much 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 mutation tool with no output schema and 7 parameters, the description covers the action, endpoint and an auth prerequisite, but says nothing about the result of the call or what happens when the group name already exists — leaving an agent without the information it needs to interpret success or failure.

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 71% and the auth/override parameters (base_url, api_token, app_password, account_id, access_token) are already documented in the schema. The description adds no meaning to 'name' or the polymorphic 'users' parameter, 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 ('Creates a user group/team') and even names the backing endpoint (/user_groups/add), so an agent knows exactly what the tool does. It does not, however, distinguish itself from the adjacent update_user_group/delete_user_group siblings beyond the verb.

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

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

The description offers no when-to-use guidance, no prerequisites for selecting this over update_user_group, and no note on how the required 'name' interacts with the optional 'users' list. Only a bare permission restriction is given.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false. The description restates the destructive nature but adds no new behavioral context – no warning about reversibility, cascade effects on related tasks/projects, 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?

Two short, front-loaded sentences. The endpoint is stated first, followed by the limitation. No 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 destructive, non-idempotent operation on a customer that likely cascades to related data, the description is thin. It doesn't mention data loss scope, whether the operation can be undone, or the auth requirements implied by the 7 parameters. Adequate but leaves real gaps.

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 86% and required params (customer_id, confirm) are documented in the schema. The description adds no parameter meaning beyond the endpoint path, so it neither helps nor hurts. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Deletes a customer'), plus the exact endpoint. Distinguishable from siblings like archive_customer and restore_customer despite no explicit sibling naming.

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

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

No guidance on when to use this versus archive_customer (the reversible alternative) or restore_customer. It notes 'destructive write operation' but doesn't tell the agent to prefer archiving when reversible soft-delete suffices.

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, readOnlyHint=false, idempotentHint=false, so 'destructive write operation' merely restates structured data rather than adding value. The description omits what is actually destroyed (field values on existing tasks/entities), whether deletion is recoverable, and any auth/permission 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?

Two short sentences, front-loaded with the action and endpoint. The second sentence is largely redundant with the annotations but costs little; nothing is padded or buried.

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

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

For a destructive, non-idempotent delete with a mandatory confirm parameter and no output schema, the description covers the mechanics but not the consequences. An agent knows what it does but not what data is lost or whether the operation is reversible, which is material for an irreversible delete.

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 confirm, credentials, and base_url. The description only implies custom_field_id via the URL template and adds no new semantics for the remaining parameters, so baseline 3 applies.

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

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

States a specific verb (Deletes) and resource (custom field definition) and even names the endpoint path, so the action is unambiguous. It does not explicitly differentiate from siblings like delete_enum_option or update_custom_field, but the resource noun is distinctive enough to identify the target.

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

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

There is no guidance on when to use this tool versus alternatives (e.g. delete_enum_option, update_custom_field, archive_* patterns). No prerequisites, no note that the field must exist, and no mention of the required confirm flag as a usage condition.

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, readOnlyHint=false, and non-idempotent, so the statement 'destructive write operation' largely restates structured data. The endpoint path adds a small amount of context, but the description omits what is destroyed, whether deletion is reversible, and that the confirm flag gates the operation.

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, front-loaded sentences with no filler. The 'Limitations' sentence is slightly redundant with annotations, but overall it is tight and readable.

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 mutation with no output schema, the description should note irreversibility and the required confirmation gate. With annotations covering the safety profile and the schema covering params, it is adequate but leaves meaningful gaps.

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 parameters, including the required confirm flag. The description adds no parameter-level detail (e.g., format of enum_option_id or auth requirements) beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb (deletes) and resource (enum option) and even names the endpoint path, so the operation is unambiguous. It does not differentiate itself from siblings like update_enum_option or list_enum_options, keeping it 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 guidance on when to use this versus update_enum_option or list_enum_options, nor any prerequisites such as needing a valid enum_option_id or confirmation. The 'Limitations' note is a safety statement, not usage 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?

The line 'destructive write operation' merely restates the destructiveHint=false/readOnlyHint=false annotations and adds no new information. With annotations already covering the safety profile, the description should instead disclose irreversibility, whether the event can be recovered via restore_event, or the auth requirements — none of which appear.

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 with the action front-loaded and no filler. The second sentence is largely redundant with the annotations, which keeps it from a 5.

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 7 parameters (5 focused on auth/workspace routing), the description is thin but the schema carries most of the load and annotations cover the safety profile. Missing confirmation of side effects and recovery path keeps it at minimum viable.

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 86%, so the schema already documents confirm, base_url, account_id, and the token aliases. The description only implies that event_id is a path segment, adding little beyond the structured fields; baseline 3 is appropriate.

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

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

States a specific verb+resource ('Deletes a time entry') and even names the REST endpoint. It does not differentiate itself from siblings like delete_events_batch (which deletes many) or restore_event (the inverse), so an agent must infer the single-vs-batch distinction.

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 when-to-use guidance: nothing tells the agent to prefer delete_events_batch for multiple entries, whether the event can be restored, or what prerequisites (account_id when multi-workspace) apply. Usage is only implied by 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so 'destructive write operation' restates structured data rather than adding context. Nothing is said about irreversible loss of tracked time, auth/permission requirements, or partial-failure behavior when some event_ids are invalid.

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, front-loaded sentences with no filler; the destructive nature is stated up front. It is efficient, though the second sentence is largely 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?

For an 8-parameter destructive batch operation with no output schema, the description is too thin: it omits the required confirm flag, the events-vs-event_ids choice, workspace/account scoping, and any consequence of misuse. An agent would need to reverse-engineer intent from the schema alone.

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 75%, below the high-coverage baseline, and the description mentions no parameters at all. The undocumented 'events' parameter is ambiguous (array of objects or a string) and the description does nothing to clarify whether it or event_ids is the intended input.

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 (Deletes), resource (time entries), and scope (in batch), plus the underlying endpoint /events/batch/delete. The 'batch' qualifier implicitly separates it from the single-item delete_event sibling, though it never names that sibling 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?

There is no guidance on when to use this versus delete_event (single) or update_events_batch. The 'Limitations:' line only flags destructiveness, not selection criteria, prerequisites, or alternatives.

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, readOnlyHint=false, and idempotentHint=false, and the description merely restates "destructive write operation." It adds one genuinely useful detail — the unusual GET method and the confirm=true gate — but discloses nothing about reversibility, downstream effects, or auth requirements beyond what structured fields provide.

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 action and followed by constraints, with no filler. The endpoint path is slightly boilerplate but still compact overall.

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?

Given annotations that already carry the full safety profile, a schema at 86% coverage, and no output schema, the description covers the essentials an agent needs. The missing element is any statement about recoverability or consequences of the deletion, which matters for a destructive tool.

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

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

Schema description coverage is 86%, so the confirm and credential/base_url parameters are already documented in the schema itself. The description adds no syntax, format, or meaning 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?

States a specific verb and resource ("Deletes an expense") and even names the exact endpoint, so the operation is unambiguous. It does not explicitly differentiate itself from siblings like update_expense or archive_* tools, but the delete intent is self-evident from the name and text.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., how it differs from update_expense or whether a soft-delete/archive path exists). The only conditional information given is the confirm=true requirement, which is a precondition rather than 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true. The description adds that it is a 'destructive write operation' and 'requires confirm=true', which reinforces annotations but also adds a specific behavioral requirement (confirmation parameter) not present in annotations. Some additional value, but not extensive beyond annotations.

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

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

Two concise sentences, front-loaded with the action and endpoint, then limitations. No 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?

Given annotations cover safety profile and schema covers parameters, the description adds the confirm requirement and endpoint. However, it doesn't mention potential side effects (e.g., cascading deletions) or return behavior, though no output schema exists. Adequate but minor gaps.

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 most parameters. The description adds the requirement of confirm=true, but holiday_id semantics are not elaborated. Baseline 3 is appropriate when schema does 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?

States a specific verb+resource ('Deletes a holiday') and even names the underlying endpoint GET /holidays/delete/:holiday_id, which distinguishes it from siblings like delete_timeoff, delete_event, and delete_task.

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 mentions the destructive nature and confirm=true requirement, which gives some usage context, but does not explicitly compare to alternatives (e.g., update_holiday, list_holidays) or state when to use vs. not use.

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, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so 'destructive write operation' is redundant with structured data. The description does add the confirmation gate, but it omits consequences of deletion (reversibility, effect on linked timecards/expenses, error on already-deleted invoice given non-idempotency).

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 clauses, with the action and endpoint front-loaded before the limitations. No filler sentences, though the endpoint path duplicates information the schema parameters already imply.

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

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

For a destructive, non-idempotent mutation with no output schema, the description covers the confirmation requirement and target endpoint, which are the essentials. It still leaves gaps on failure behavior and side effects on related records, which matter for an irreversible operation.

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 confirm, account_id, base_url, tokens, etc. The description only echoes the confirm=true requirement and the account_id/invoice_id path placement, adding no syntax or format detail beyond the structured fields. 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 (deletes) and resource (invoice) plus the exact endpoint POST /invoicing/:account_id/invoices/:invoice_id/delete, which leaves no ambiguity about scope. It does not, however, differentiate itself from sibling mutations such as mark_invoice_void or archive-style operations, which a reader must infer.

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 'Limitations' clause gives one actionable prerequisite (confirm=true), which is real usage guidance. It never says when to delete versus voiding or archiving an invoice, nor what state the invoice must be in, so the when-to-use decision against siblings is left to inference.

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?

'Limitations: destructive write operation' merely restates destructiveHint=true and readOnlyHint=false from the annotations, earning no credit. It omits behavior the annotations do not carry: whether the deletion cascades to tasks/timecards/expenses, whether it is reversible, and what the caller sees on success or failure.

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 with the action front-loaded and no filler prose. The second sentence is largely redundant with the annotations, which slightly dilutes the efficiency.

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

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

For a destructive, non-idempotent, open-world mutation with seven parameters and no output schema, the description is thin. It never addresses scope of deletion, recoverability, permission requirements, or the required confirm flag, leaving an agent to infer the risk profile entirely from annotations and 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 the auth parameters, base_url override, and the confirm flag. The description only echoes project_id via the endpoint template and adds no semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Deletes a project') plus the underlying endpoint, so the operation is unambiguous. It does not distinguish itself from the closely related siblings archive_project and restore_project, which an agent must choose between.

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

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

No guidance on when to delete versus the available alternatives. With archive_project and restore_project present in the sibling set, the description should say whether this is permanent, when archiving is preferred, or how recovery works, and it says none of that.

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, readOnlyHint=false, and non-idempotency, so the safety profile is covered structurally. The description adds useful context beyond that: the operation is destructive, it is a write, and confirm=true is mandatory, though it does not note irreversibility or what happens to still-running report jobs.

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 front-loaded sentences with a clear 'Limitations:' label and no filler; the constraint (confirm=true) is placed before the endpoint detail. Slightly terse relative to the 8-parameter surface but nothing is wasted.

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

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

No output schema exists, so return values needn't be explained, and annotations already convey the destructive/write profile. For a simple deletion tool the description is nearly complete, with the only real gap being the undocumented 'data' vs 'report_id' invocation paths.

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 description coverage, the schema carries most parameter meaning, so baseline 3 applies. The description's 'one or more' hints at batch deletion but does not resolve the ambiguity between the 'data' array and the standalone 'report_id' parameter, which are undocumented in both places.

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 ('Deletes'), the resource ('saved/shared reports'), and a scope qualifier ('one or more') plus the underlying endpoint. An agent can distinguish it from get_report/update_report/list_reports, though it offers no explicit contrast with sibling delete_* 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?

The destructive nature and the confirm=true prerequisite are stated, which signals when the tool is appropriate, but there is no guidance on when to delete versus archive or restore, nor any prerequisite/permission context for choosing it over alternatives.

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, readOnlyHint=false and idempotentHint=false, so the safety profile is covered. The description adds the meaningful constraint that confirm=true is mandatory, but does not disclose side effects (e.g., what happens to assignments or the schedule's history).

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 action and endpoint front-loaded, followed immediately by the operative constraint. No filler.

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

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

For a destructive single-resource delete with annotations covering safety and an 86%-documented schema, the definition is nearly sufficient. It could mention auth requirements or the effect on related schedule assignments, but nothing essential to invoking it correctly is missing.

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

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

Schema description coverage is 86%, so the schema already documents confirm, base_url, account_id, tokens, etc. The description only restates the confirm requirement, adding no semantics beyond the structured fields; baseline 3 is appropriate.

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

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

States a specific verb (deletes) plus the resource (a schedule) and even the underlying endpoint, making it trivially distinguishable from siblings like update_schedule or delete_task.

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 precondition ('requires confirm=true') and flags the operation as destructive, which implicitly tells the agent when it is safe to call. However, it names no alternative or when-not-to-use condition, so guidance is only implied.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so 'destructive write operation' merely restates structured data. The description adds the endpoint path but says nothing beyond annotations about irreversibility, whether a restore_task recovery path exists, or any permission 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?

Two short sentences, front-loaded with the action and endpoint with no filler. It is efficient, though the 'Limitations' fragment is thin enough to feel like a stub.

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 7-parameter operation with no output schema, the description covers only the basic action. Given the required confirm flag and auth parameters are documented in the schema at 86% coverage, it is minimally adequate, but it omits recovery options and side effects an agent should know before deleting.

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% and the required confirm flag is already documented in the schema, so the heavy lifting is done there. The description only alludes to task_id through the endpoint path and adds 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 and resource ('Deletes a task') and pins down the endpoint /tasks/delete/:task_id, which is concrete. It does not, however, differentiate from close siblings like archive_task or restore_task, which an agent must choose among.

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 when-to-use or when-not-to-use guidance and no named alternative (archive_task, restore_task exist as siblings). The 'Limitations' line only notes destructiveness, not the conditions that should select this tool over archiving.

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, readOnlyHint=false and idempotentHint=false, so 'destructive write operation' merely restates structured data and adds no value. The description omits genuinely useful behavioral context such as irreversibility, auth requirements, or whether the deletion can be undone.

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 with the action front-loaded and no padding. The second sentence is largely redundant with the annotations, but the text is 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 destructive single-entity delete with annotations covering the safety profile and no output schema, the essentials are present. It nonetheless leaves out confirmation behavior and auth expectations that would help an agent 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 86%, so the schema already documents comment_id, confirm, and the auth/account overrides. The description adds no parameter meaning beyond that, which is the baseline 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?

Names a specific verb and resource ('Deletes a task comment') plus the underlying endpoint, so an agent can distinguish it from delete_task and the other delete_* siblings. It stops short of explicitly contrasting with the closely related list_task_comments/add_task_comment, but the purpose is unambiguous.

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

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

No guidance on when to use this versus alternatives, no prerequisites, no mention that the required confirm flag gates the call. The agent must infer everything from the schema.

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 description effectively reinforces the destructive nature already hinted by annotations, and adds unique behavioral context by explicitly stating that this destructive write requires confirm=true. It could have disclosed if deletion is permanent or recoverable, but it provides more than the annotations alone.

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

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

The description is highly concise, one sentence covering the action and a critical limitation. Every part earns its place without any fluff.

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 description gives the core action, the exact endpoint, and a critical safety requirement, which is sufficient for a destructive tool with annotations. It doesn't explain the return value or all permissions, but since there is no output schema and annotations cover safety, it is mostly 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?

With 86% schema description coverage, the schema already documents most parameters, including the confirm requirement. The description mentions confirm=true, which duplicates the schema but adds minimal new meaning for the 7 parameters overall. The baseline is 3.

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 (deletes) and resource (a time off request), and uniquely includes the exact endpoint. It clearly distinguishes this specific delete operation from other delete sibling tools like delete_customer or delete_task.

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 implies usage through "deletes a time off request" and lists a critical limitation, but it does not explicitly state when to use this tool versus alternatives such as update_timeoff. However, for a specific delete operation, the context is clear enough.

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, readOnlyHint=false, and idempotentHint=false, so the description's 'destructive write operation' line merely restates structured data. It adds no new behavior: not what happens to group members or associated data, not whether the delete is recoverable, not auth requirements or rate limits.

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

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

Two short, front-loaded sentences with no padding, and the endpoint reference is placed immediately after the action. The second sentence is largely redundant with the annotations, which slightly weakens it, but it is not verbose.

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

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

For a destructive, non-idempotent, open-world delete with no output schema, the description is minimally adequate: safety is covered by annotations and the required confirm flag is covered by the schema. It still omits cascade effects (what happens to members, projects, or trackables tied to the group), which an agent would want before calling.

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

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

Schema description coverage is 86%, so the schema already documents confirm, base_url, api_token, account_id, access_token, and app_password. The description adds nothing about user_group_id beyond echoing it in the URL path, so the baseline of 3 is appropriate.

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

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

The description names a specific verb (deletes) and resource (user group/team) and even cites the underlying endpoint /user_groups/delete/:user_group_id, so the action is unambiguous. It does not, however, contrast itself with the many other delete_* siblings (delete_customer, delete_project, delete_task), though the resource name largely does that work.

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

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

There is no guidance on when to use this tool versus alternatives (e.g., archive_user vs delete, list_user_groups to find the id), no preconditions such as required permissions or the fact that the group must exist, and no note on irreversibility beyond a generic 'destructive' label.

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 and openWorldHint=true, and 'write operation' is consistent with that. The 'supports extra API parameters via passthrough' note usefully explains the additionalProperties:true schema, but nothing is said about side effects, the new project's ownership/naming, or rate limits.

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

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

Two short sentences with the action front-loaded and no filler. Slightly terse but every sentence carries 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 mutation tool with 7 parameters and no output schema, the description is a bit thin: it omits what the duplicate returns and any required context beyond the URL. Annotations plus the 71%-covered schema carry most of the remaining burden.

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 71%, so most parameters are already documented. The description adds only the passthrough hint and implicitly the project_id via the endpoint; it doesn't clarify what the 'name' parameter controls for the duplicate, which is the one field most likely to confuse an agent.

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 ('Duplicates a project') and even names the underlying endpoint, so an agent knows exactly what it does. It doesn't explicitly contrast with create_project or update_project, but the action is unambiguous.

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

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

Only a fragment of guidance: it notes it is a write operation and supports passthrough params. There's no statement of when to duplicate vs. use create_project or what prerequisites (e.g. workspace/account_id, permissions) are needed.

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, idempotentHint=true, and destructiveHint=false, so the description's 'read-only export' merely restates structured data. It adds no behavioral context beyond that, such as the export format produced, whether it streams/downloads a file, or any rate limits or permission 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?

Two compact sentences with the action and endpoint front-loaded and no filler. The second sentence is somewhat redundant with the annotations but is short and 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?

No output schema exists, so the description should ideally say what the export actually produces (PDF, CSV, URL, binary payload). Since 'export' implies a non-JSON artifact, this is a meaningful gap, though annotations cover the safety profile 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 83%, so the schema already documents nearly every parameter (base_url, api_token, account_id, access_token, app_password), and the description adds nothing further about them. The only undocumented field, the required invoice_id, is merely echoed in the endpoint path. 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 verb ('Exports') and resource ('an invoice') and even pins the REST endpoint, so an agent can immediately tell this apart from mutation-oriented siblings like send_invoice or mark_invoice_paid. It stops short of distinguishing itself from get_invoice or the sibling export_timecards, so it is clear but not fully differentiated.

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

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

There is no guidance on when to choose export_invoice over get_invoice, list_invoices, or export_timecards, and no prerequisites or exclusions are stated. The only hint is the terse 'Limitations: read-only export', which implies no side effects but does not route the agent to an alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's "read-only export" merely restates that safety profile. It adds the endpoint path and a vague "pass data in the API-supported format" note but discloses nothing about auth requirements, return format, or limits. With annotations carrying the safety burden, this is adequate but adds little genuine context.

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 that are front-loaded with the core action and contain no padding. The second sentence is somewhat vague but still earns its place as a constraint statement.

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 export tool with no output schema and only partial schema coverage, the description omits what the export produces, what format the result takes, and how the data parameter works. An agent would struggle to call this correctly, especially the data argument.

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 9 parameters and only 56% schema description coverage, the description should compensate for the undocumented to/data/from/user_id arguments but does not. "Pass data in the API-supported format" gestures at the data parameter without explaining its structure, acceptable values, or relationship to from/to.

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 ("Exports timecards") and even names the endpoint GET /timecards/export, so the basic action is unambiguous. However, it does not distinguish this tool from closely related siblings such as export_invoice, list_timecards, get_timecard, or generate_timecard, so the agent gets no help telling similar export/list/get operations apart.

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

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

There is no guidance on when to use this tool versus list_timecards, get_timecard, or export_invoice. The "Limitations" line describes a constraint, not a usage condition, and no prerequisites or exclusions are given, leaving selection entirely to inference.

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, so the description's 'write operation' note is largely redundant. The genuinely additive part is that generated days can be persisted when save_days=true, which clarifies side effects beyond the annotations.

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

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

Two short sentences, with the core action front-loaded ahead of the caveats. No padding or repetition.

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

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

For a 9-parameter mutation tool with no output schema, the description omits what the call returns, the required time-range/auth inputs, and how the result relates to saving. The save_days note is the only behavioral completeness it provides.

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 sits at 56% with 9 parameters and none required. The description explains only save_days; from/to, user_id, account_id requirements, and auth parameter selection are left to the schema, which is itself incomplete.

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 ('Generates a user timecard') and even names the underlying endpoint, so an agent can distinguish it from read siblings like get_timecard and list_timecards. It stops short of explicitly naming those alternatives.

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

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

No statement of when to use this tool versus save_timecard_day, get_timecard, or export_timecards. The only usage-adjacent content is the save_days note, which is a parameter behavior rather than selection 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 (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine context beyond them: 'visibility depends on account role,' which tells the agent results may vary by permissions. 'Read-only' merely restates readOnlyHint and adds little.

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

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

Three short sentences, front-loaded with the action, then usage, then limitations. No filler and nothing that repeats structured data unnecessarily.

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 read tool with annotations covering safety and full schema coverage, the description is nearly complete, and the role-based visibility caveat is a useful addition. With no output schema, it could have described the returned account shape, which is the remaining minor gap.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including the multi-workspace requirement for account_id. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

Specific verb and resource ('Gets account/workspace settings from /account'), which is clear enough for an agent to identify the operation. It stops short of distinguishing itself from close siblings like get_me or list_workspaces, so it lands at 4 rather than 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?

'Use for account-level configuration and metadata' gives implied usage context, but no when-not guidance and no alternatives are named among the many sibling getters (get_me, get_user, get_customer, list_workspaces). Adequate but leaves the routing decision to inference.

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, idempotentHint and destructiveHint=false, so the 'read-only' restatement earns little. The added value is the account-scoping constraint ('customer must belong to the authenticated account context'), a genuine behavioral/authorization fact not present in annotations or 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?

Three short, front-loaded sentences with no filler: purpose, one supported flag, then limitations. Efficient, though the endpoint path slightly duplicates what the name already conveys.

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

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

For a read-only single-resource getter with no output schema, the description covers purpose, endpoint, the one non-obvious flag, and the authorization scope. No output explanation is needed since no output schema exists, and no pagination concern applies.

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 71%, so the schema already documents base_url, api_token, account_id and the token aliases. The description only flags include_custom_fields (which is undocumented in the schema) and adds no syntax or format detail. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Gets a specific customer') and anchors it to the endpoint /customers/:customer_id, which clearly distinguishes it from list_customers. It stops short of naming the sibling, but the singular-resource framing is unambiguous.

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

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

The 'Limitations' clause implies usage context (read-only, account-scoped), but it never states when to use this versus list_customers or get_account, nor any exclusion conditions. 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, idempotentHint=true, and destructiveHint=false, so 'Limitations: read-only' merely restates what structured data provides. No additional behavioral context (e.g. behavior on a missing ID, auth requirements across the six credential params) is 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 short, front-loaded sentences with no filler. It is efficiently sized for a simple getter, though 'Limitations: read-only' adds little given the annotations.

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 single-resource getter with no output schema and an adequately described input schema, the description is minimally sufficient. It omits any note about the returned definition shape or not-found behavior, which keep it at the baseline rather than above it.

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 the parameters well. The description adds only the endpoint path and does not clarify which credential parameter is preferred or what custom_field_id must reference, so this is the standard baseline.

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

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

States a specific verb+resource ('Gets a custom field definition') and even names the REST path, which clearly distinguishes it from list_custom_fields, create_custom_field, and update_custom_field. It stops short of explicitly differentiating from its siblings, but the single-fetch semantics are unambiguous.

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

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

The 'read-only' limitation implies a safe retrieval use, but there is no explicit when-to-use guidance and no pointer to alternatives such as list_custom_fields for enumeration. Usage is only implied by the verb.

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