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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about mutation semantics, required permissions, idempotency, or whether the comment is editable/deletable. A single phrase is far too thin for a write operation with zero annotation coverage.

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

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

One sentence, front-loaded, no wasted words. It is appropriately sized for a simple tool, though arguably under-specified rather than concisely complete.

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 annotations and no output schema, the description omits return behavior, error cases, and permissions. The schema covers parameters but the description leaves significant behavioral territory blank.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds nothing about the task_id type flexibility or author defaults. No compensation is needed since the schema fully documents all three parameters.

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

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

States a specific verb (add) and resource (comment) bound to a task, which is clear enough to distinguish from siblings like update_task or get_task. It lacks explicit sibling differentiation, but the operation 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 when-to-use guidance, prerequisites, or alternatives are given. An agent gets no signal on when to comment versus updating a task's context or description.

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?

With no annotations present, the description carries the full behavioral burden, yet it discloses almost nothing: not whether assignment overwrites an existing agent, whether permissions are required, whether the target agent is notified, or whether the operation is reversible. Only the mutation/unassign duality is conveyed.

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 that front-loads the core action and appends the reversal case. No filler or redundancy.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the definition is minimally adequate: it names the action and the unassign path but omits side effects, permissions, and reassignment semantics that an agent would need 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 coverage is 100% and both parameters are documented in the schema, including the null-to-unassign semantics for agent_id. The description restates that same null behavior rather than adding format, type, or constraint detail, 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?

It states a specific verb (assign) and resource (task to an agent) and even covers the inverse operation (unassign via null). However, it offers no differentiation from closely related siblings such as claim_task, delegate_task, or release_task, so an agent must infer which assignment path 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?

The only usage hint is the parenthetical about passing null to unassign, which is really parameter behavior. There is no statement of when to prefer this over claim_task or delegate_task, nor any prerequisite or context for invoking 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?

With no annotations, the description carries the full behavioral burden and does so: it discloses that queue selection is atomic, the preconditions for claimability (open, unclaimed, unassigned or yours), the conflict failure conditions (completed, assigned to another agent, live lease), lease default and duration, and that it returns the claimed task or an empty-queue report.

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

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

Front-loaded with the core purpose, then mode behavior, then failure conditions, then lifecycle routing and the hosted-only constraint. Every sentence is load-bearing with 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 no-output-schema, zero-required-param tool, the description supplies everything needed to call it correctly: mode selection, filter scoping, conflict behavior, lease duration and renewal path, and the hosted-API restriction.

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

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

Schema coverage is 100%, so parameter syntax is already documented. The description adds meaning beyond that by explaining the mode switch driven by task_id and by clarifying the queue-only applicability of labels/project_id and the lease default, though it stops short of syntax-level detail.

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

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

States a specific verb (claim) and resource (task) plus its queue semantics, and distinguishes the two operating modes (queue claim vs. specific task_id) that separate it from siblings like list_tasks and get_task. An agent can tell immediately this is the exclusive-acquisition operation.

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

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

Explicitly covers both modes and when each applies: no task_id for the next highest-priority claimable task, task_id when the id came from list_tasks or a rejected write ('claim it first'). It also routes the agent to the correct lifecycle alternatives (heartbeat_task to extend, release_task to requeue, complete_task to finish).

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?

With no annotations supplied, the description carries the full burden and does disclose meaningful behavior: evidence is a durable, falsifiable claim that is not executed or verified by Delega, and command_output alone is rejected under 'required' policy. It still omits side effects of completion (state transition, idempotency, what happens if the task is already complete, permissions).

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

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

Three sentences, front-loaded with the action, then the evidence contract. Slightly dense with parenthetical detail and a mild redundancy between 'always welcome' and 'REQUIRED', but every clause conveys usable 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?

There is no output schema and no annotations, so the description must stand alone; it adequately covers purpose and the evidence contract but says nothing about the result of completion, downstream automations triggered, or error behavior. Adequate for the core call, incomplete for a mutation tool with zero structured safety/behavior coverage.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description goes beyond the schema by imposing a policy the enum alone does not encode: at least one 'strong' kind (commit/pr/ci_check/deploy_sha/artifact_url) must appear when evidence_policy is 'required', and command_output alone is rejected. That materially shapes how the agent must populate the parameter.

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

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

States a specific verb and resource: 'Mark a task as completed.' Clear and unambiguous, but it never distinguishes itself from the closely related sibling set_task_state (or update_task), which an agent could easily pick for the same end state.

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 conditional guidance about when evidence is required based on the task's evidence_policy, which is genuinely useful. However, it gives no tool-selection guidance about when to call complete_task versus set_task_state or update_task, and names no 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?

With no annotations, the description carries the full burden and does so thoroughly: it discloses cascade depth/budget caps, self-reaction prevention ('rules never react to tasks they created'), the ordering of condition evaluation, and the subtle field-mutation-vs-comment behavior under live claims. This is exactly the safety context an agent needs before creating a rule.

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

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

Front-loaded with the core definition, then example, then safety notes and access constraint. Dense but every clause earns its place; the safety sentence is long but carries non-redundant 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 rule-creation tool with no annotations and no output schema, the description covers execution model, access control, safety interactions, and a worked example. An agent has everything needed to construct a valid, safe request.

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

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

Schema coverage is 100%, so enum values, placeholders, and field/op pairings are already documented in the schema. The description's example maps to a real parameter combination but adds no syntax guidance 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+resource ('Create an automation rule') and immediately describes the execution model ('when an event fires and all conditions match, run the actions in-process'). The example and the phrase 'no webhook receiver needed' cleanly distinguish it from create_webhook and create_ingress_source 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?

Clear context: admin-only and 'Hosted API only' give real gating conditions, and the concrete example shows a canonical use case. It doesn't explicitly point agents to update_automation for modifications, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and does so exceptionally well: it discloses the HMAC-SHA256 signing scheme, exact header format with a 5-minute tolerance, that routing is pinned and never payload-controlled, the always-added 'ingress' provenance label, and the automation-opt-in behavior. These are precisely the operational traits an agent needs before invoking a security-sensitive endpoint.

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

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

Front-loaded with purpose and security behavior, and every clause is informative. It is dense and packs multiple clauses into long sentences, but little is waste; a minor deduct for density over readability.

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 nested-object tool with no output schema and no annotations, the description is complete enough to invoke correctly: it covers auth requirements, signing contract, scope constraints, and side effects. Return values are not needed since the tool's job is creation and behavior is fully characterized.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds genuine meaning beyond the schema: it explains that project/assignee are pinned and cannot be overridden by payload, and that the 'ingress' label is always added regardless of the labels parameter. These clarify behavioral semantics of the parameters rather than restating types.

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 ('Create an inbound connector') plus a concrete functional definition ('a signed public endpoint that turns external events... into Delega tasks'). The 'admin only' qualifier and examples (CI failures, alerts, calendars) let an agent distinguish it from siblings like create_webhook without opening the schema.

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

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

Provides real access conditions ('admin only', 'Hosted API only') and a key scope limit ('Ingress can ONLY create tasks'), which implies when it applies. However, it never explicitly routes the agent between this tool and the closely related create_webhook/create_automation siblings, so the when-to-use-vs-alternative 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the core behavior — a hosted scheduler spawns real task instances from the template and tags them with source_recurrence_id — which goes beyond the schema. However it omits important operational traits for a recurrence tool: whether the first instance spawns immediately or after one interval, what happens on delete_recurrence, and how invalid rule/anchor combinations are handled.

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

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

Two sentences, nothing wasted, and the core purpose is front-loaded before the behavioral detail. The second sentence earns its place by explaining the spawning/linking model that the schema alone does not convey.

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, no-annotation, no-output-schema tool, the description explains the creation model but leaves scheduling semantics unaddressed — first-occurrence timing, the interaction of rule_type with anchor_weekday/anchor_day/anchor_month, and skip_if_open edge behavior are all left to the agent. Adequate but with clear 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 100% across all 14 parameters, so the schema already documents content, rule_type, interval, anchors, timezone, skip_if_open, etc. The description adds no parameter-level syntax or constraints, 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: 'Create a recurring task template.' That is clearly distinct in concept from create_task or update_recurrence. It stops short of explicitly contrasting itself with those siblings, but the template-vs-instance framing makes the purpose 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?

Usage is only implied: an agent can infer you call this when you need a repeating task rather than a one-off. There is no explicit when-to-use, when-not-to-use, or routing to create_task vs update_recurrence, so the guidance stays at the minimum-viable level.

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?

With no annotations, the description carries the full behavioral burden and discloses almost nothing. It does not state whether creation is idempotent, how duplicate tasks are handled (despite a find_duplicate_tasks sibling), what permissions are needed, or what happens if project_id is 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?

A single short sentence with no wasted words, but for a 7-parameter creation tool with no annotations or output schema it is under-specified rather than genuinely concise. There is nothing to front-load or structure.

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 a 7-parameter mutation tool with no annotations and no output schema, the description is inadequate. It should at least mention required fields, defaults, or the effect of evidence_policy and duplicate handling, none of which appear.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters including the priority enum and evidence_policy. The description adds nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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

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

States a clear verb+resource: 'Create a new task'. An agent immediately knows this creates a task. However, it offers no differentiation from siblings like create_recurring_task or delegate_task, which also produce task-like objects, so an agent must infer which creator to pick.

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, no prerequisites, and no mention of alternatives such as create_recurring_task or delegate_task. The agent receives no signal about when this tool is the right choice versus its siblings.

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?

No annotations provided, so description bears full responsibility. It states admin requirement and events but omits details like idempotency, activation behavior, or security considerations. Minimal disclosure.

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?

Short, front-loaded with verb and resource. Events list is lengthy but informative. Could omit events since they are in schema, but overall efficient.

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?

Adequate for a simple creation tool with 2 parameters and no output schema. Lacks info on return values or side effects, but context signals (100% coverage) compensate partially.

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 covers 100% of parameters with descriptions. The description redundantly lists events that are already in the enum. Adds no new semantic value beyond 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?

Clearly states the action (create) and resource (webhook), with specific context 'admin only' and listing events. Distinguishes from sibling tools like list_webhooks and delete_webhook.

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?

Specifies 'admin only', indicating restricted usage. Does not explicitly state when to use vs. alternatives, but the event list clarifies subscribing scenarios.

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?

With no annotations, the description carries the full burden. It does disclose one meaningful side effect beyond the schema – the parent's status flips to 'delegated' – which is exactly the kind of trait an agent needs. However it says nothing about permissions (the schema mentions admin-only for non-self delegations), reversibility/undo, or failure modes for a mutation tool.

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

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

Two sentences, zero filler, with the core action and the sibling exclusion front-loaded. Every clause earns its place.

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

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

For an 8-parameter mutation with a rich schema and no output schema, the description covers purpose, the alternative to use instead, and the key state change. It stops short of telling the agent what the call returns (e.g., the new child task ID), which is the one gap given no output schema exists.

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 8 parameters are already documented in the schema, including the priority enum and admin-only project_id note. The description adds no additional parameter syntax or format guidance, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Delegate a task: create a child task linked to a parent') and immediately distinguishes itself from the sibling assign_task. The agent can tell what it does and how it differs from the nearest alternative 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?

'Use this (not assign_task) for multi-agent handoffs so the delegation chain is recorded' gives an explicit when-to-use plus a named alternative and the reason to prefer this one. Nothing about selection 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses refusal conditions (active tasks, last active agent), but omits other key traits such as whether deletion is reversible, what permissions/auth are required, and what happens to the agent's existing tasks.

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, no filler, with the core action front-loaded and the caveat second. Every clause earns its place.

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

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

For a destructive tool with no annotations and no output schema, the description covers the essential failure modes but leaves notable gaps: irreversibility, permission requirements, and post-deletion side effects are unstated.

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

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

Schema coverage is 100% and the sole parameter agent_id is documented in the schema as 'Agent ID to delete'. The description adds nothing beyond that, so the baseline of 3 applies.

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

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

The description states a specific verb (Delete) and resource (agent), making the operation unambiguous. It doesn't explicitly differentiate from siblings like register_agent or set_agent_role, but the resource naming is distinct enough that no sibling collision exists.

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 failure condition ('may refuse if the agent has active tasks or is the last active agent') which implicitly tells the agent when the call won't succeed, but there is no explicit when-to-use guidance, no mention of alternatives (e.g., set_agent_role or release_task to retire an agent), and no prerequisites.

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

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

With no annotations, the description carries the full burden and does well: it discloses the destructive side effect (run log is deleted alongside the rule), the auth requirement (admin only), and an environment restriction (hosted API only). It stops short of stating irreversibility, confirmation behavior, or error conditions when the ID does not exist.

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

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

A single sentence with the deletion action and its side effect front-loaded, followed by two compact qualifiers. 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 one-parameter destructive tool with no annotations or output schema, the description covers the essentials an agent needs (what is destroyed, required privilege, supported environment). Only the irreversibility/confirmation aspect of a delete is left unstated.

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

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

Only one parameter, and the schema already describes it at 100% coverage ('Automation rule ID to delete'). The phrase 'by ID' in the description adds nothing 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 (Delete) plus a precise resource (an automation rule and its run log), so the agent knows exactly what is removed. It does not explicitly name a sibling, but the resource differs clearly from delete_recurrence, delete_webhook, and update_automation.

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

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

Gives two real gating conditions — admin privilege required and hosted-API-only — which tell the agent when this call is valid. It does not, however, point to alternatives (e.g., update_automation for disabling instead of deleting) or say when deletion is inappropriate.

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?

With no annotations, the description carries the full burden and does well: it discloses the destructive cascade (deleting the source also removes its delivery log), the immediate post-delete state (endpoint returns 404), and an auth requirement (admin only). It omits whether the deletion is reversible or requires confirmation, which keeps 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, front-loaded with the action and side effect, then constraints. Every clause (cascade, 404, admin only, hosted only) earns its place with 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 single-parameter delete with no output schema and no annotations, the description covers the critical facts: what gets destroyed, the resulting endpoint state, and the access/hosting constraints. It is essentially complete, with only reversibility/confirmation behavior left unstated.

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

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

Schema description coverage is 100%, so the single source_id parameter is already documented. The description only restates 'by ID' and adds no format or type nuance beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb (Delete) and resource (an inbound connector source and its delivery log), scoped by ID. This cleanly distinguishes it from sibling deletes like delete_webhook, delete_automation, and delete_recurrence, since the resource differs. An agent can pick it without opening the schema.

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

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

It gives access constraints ('admin only', 'Hosted API only') that gate usage, which is useful, but it never states when to choose this over alternatives or when not to delete (e.g., active sources, dependent automations). Usage is implied from 'delete by ID' rather than explained.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that spawned instances survive as normal tasks (i.e., no cascade delete), which is real behavioral value, but it says nothing about irreversibility, required permissions, or whether the recurrence can be restored.

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, zero filler, with the core action front-loaded and the important side effect immediately after it. Nothing is padded or restated.

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

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

For a single-parameter delete with no output schema and no annotations, the description covers the essential scope question (what is and is not removed). It stops short of the destructive-op caveats (permanence, permission requirements) that an agent would ideally have.

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?

Only one parameter, and schema description coverage is 100% ('The recurrence ID to delete'), so the schema already does the work. The description adds no format, ID-source, or type nuance beyond it, making 3 the correct 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 and resource ('Delete a recurring task template'), and 'template' plus the follow-up clause distinguishes it from delete_task (which removes instances). It never names a sibling outright, so it falls just short of the 5 bar, but an agent can tell it apart from delete_automation 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as update_recurrence (which might disable rather than remove the template). The only usable hint is implicit in the consequence sentence, which is about effect rather than 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that deletion is permanent (irreversible), but says nothing about required permissions, whether linked data/subtasks are cascaded, or whether repeated calls are idempotent.

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?

Five words with zero waste and the key constraint front-loaded. It is maximally concise, though arguably terse enough that useful context was omitted rather than trimmed.

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

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

For a one-parameter destructive tool with full schema coverage and no output schema, the description covers the core action and its permanence. It still leaves gaps an agent might care about, such as cascading effects and permission requirements.

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

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

Schema description coverage is 100%, so the single task_id parameter is already fully documented as 'The task ID to delete'. The description adds no syntax, format, or constraint details beyond the schema, making the baseline 3 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 gives a specific verb (delete) and resource (task) plus the scope qualifier 'permanently'. It is clear what the tool does, though it does not name how it differs from related siblings like complete_task, set_task_state, or release_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?

There is no guidance on when to use this tool versus alternatives. Siblings such as complete_task, set_task_state, and release_task change task status without deleting, and the description never tells the agent when deletion is the right choice.

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?

With no annotations, the description carries the full burden and does disclose one meaningful trait: an admin-level authorization requirement. It omits the traits that matter most for a destructive operation — whether the deletion is permanent, whether it breaks existing deliveries or inbound events, and what happens if the ID is not found.

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

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

One short sentence with zero filler; the verb, resource, identifier, and permission constraint are all front-loaded.

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

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

For a one-parameter destructive tool with no annotations and no output schema, the description is minimally adequate but leaves the irreversibility and side-effect profile unstated, which is exactly the information an agent needs 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 100% and the single parameter ('webhook_id') is fully documented in the schema. The description's 'by ID' phrase restates rather than enriches that, so the baseline 3 is correct.

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

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

States a specific verb and resource ('Delete a webhook') plus the lookup key (ID), which cleanly separates it from create_webhook and list_webhooks in the sibling set. It stops short of naming any sibling explicitly, so it lands at clear-but-not-differentiating.

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 '(admin only)' parenthetical is a genuine precondition that tells an agent whether it is even eligible to call this tool. However, there is no guidance on when to delete a webhook versus alternatives such as delete_ingress_source or delete_automation, so 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?

With no annotations, describes algorithm (TF-IDF + cosine similarity) and scope (open tasks) but does not detail return type or side effects. Adequate but not thorough.

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 with priorization of algorithm details and use recommendation. No superfluous words.

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?

Tool is simple with 2 parameters and no output schema. Description covers purpose, usage hint, and algorithm—mostly complete; missing explicit return format but acceptable given low complexity.

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 has 100% coverage of both parameters (content and threshold). Description adds no extra meaning beyond the schema, so baseline score of 3 applies.

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

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

Description clearly states the tool checks similarity using TF-IDF + cosine similarity and explicitly distinguishes it from create_task by recommending its use before creation.

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?

Directly advises 'Call this before create_task to avoid redundant work', providing clear usage context. No explicit when-not-to-use but sufficient for a simple check 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?

The description discloses read-only status, scoping, and 'Hosted API only' constraint. No annotations exist, so the description carries full burden; it adds useful behavioral context but omits details like rate limits or data freshness.

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 efficient with no wasted words, but the structure could be slightly improved for readability. It front-loads the key 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 tool with no parameters and no output schema, the description adequately covers purpose, scope, and read-only nature. It could mention the output format, but it is otherwise 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?

No parameters exist in the input schema, so the description has no need to add parameter info. The baseline score of 4 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 uses specific verb+resource ('Triage board') and lists exact items (abandoned claims, silent holders, etc.). It clearly distinguishes this from sibling tools by its focus on items needing human or coordinator attention.

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 implies when to use (for triage) and provides scoping rules (coordinators/admins vs workers), but it does not explicitly state when not to use or compare with alternatives like list_tasks or get_stats.

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?

With no annotations, the description carries the burden and does reasonably well: it discloses append-only immutability, bounded paging, that history remains complete, and that omissions from max_chars remain retrievable. It does not state auth requirements or rate limits, but the core non-obvious behavioral traits are covered.

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 dense sentences, front-loaded with the resource and follow-up pagination mechanics. Every sentence earns its place, though the distinction between the two cursor types takes some parsing.

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 ledger tool with no annotations and no output schema, the description is complete enough on behavior (paging, cursor types, retrieval guarantees) and the schema covers parameters. Minor gaps remain around auth and exact return shape, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters thoroughly. The description reinforces how key and history_cursor behave but adds no semantics beyond what the schema provides. 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 (Read) and resource (bounded page of the append-only context provenance ledger). It is fairly clear but does not name its closest siblings (get_task_context, update_task_context) to distinguish provenance history from current context, which would have made the boundary 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?

Implies usage through guidance on key for narrowing and cursor mechanics, but never states when to use this versus get_task_context/update_task_context or any other alternative. The usage hints that exist are about pagination, not 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?

No annotations are provided. The description identifies it as a 'get' operation, implying it is read-only and non-destructive, but it does not disclose any other behavioral traits such as permissions, rate limits, or data freshness. The description is adequate but not rich.

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

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

The description is a single sentence that is concise and front-loaded with the verb and resource. Every word contributes to clarity, with no unnecessary 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 no-parameter tool with no output schema, the description provides a reasonable list of statistics categories. However, it lacks details on the output structure or format, which would be helpful for an agent to interpret the results. Nonetheless, it is largely complete for the tool's purpose.

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

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

The input schema has zero parameters, so the description does not need to add parameter meaning. According to the rubric, 0 parameters gives a baseline of 4. The description lists the statistics categories, which are the output rather than input, but it does not detract.

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 clearly states the verb 'get' and the resource 'task statistics', and lists specific categories of statistics (totals, completed today, due today, overdue, by project). This distinguishes it from sibling tools like get_task (single task) or list_tasks (listing tasks) and provides a clear purpose.

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 does not explicitly state when to use this tool versus alternatives like list_tasks or get_task. It implies that statistics are aggregated rather than individual tasks, but no direct guidance or exclusions are provided.

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?

With no annotations, the description carries the burden and does disclose non-obvious behavior: output is 'bounded JSON', large reads paginate via text cursors, and a fragment must not be treated as complete. It omits auth/permission requirements and error behavior, but the pagination and bounded-output disclosures are genuinely useful beyond the schema.

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

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

Three tight sentences, each earning its place: the scope is front-loaded, the sibling routing follows, then the pagination caveat. No redundancy or 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 read tool with no output schema and no annotations, the description enumerates the returned facets and explains the pagination/bounded-output model, which is enough to call it correctly. Only absent pieces are permission requirements and error semantics, which are minor here.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents cursor, task_id and max_chars. The description reinforces the cursor rule ('same task ID', fragments incomplete) but adds little formal syntax or format detail 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 (Get) plus the exact resource and returned facets (details, ownership, handoff, links, subtasks), and explicitly carves out what it does NOT return ('Context is retrieved separately through get_task_context'). An agent can distinguish it from get_task_context and list_tasks 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?

Clearly routes context-fetching to the named sibling get_task_context and gives pagination guidance ('Follow text cursors with the same task ID for large details; do not treat a fragment as complete'). It lacks an explicit negative condition (e.g. when to prefer list_tasks or get_task_chain), so it stops short of a full 5.

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

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

No annotations are supplied, so the description carries the full burden. It does disclose the shape of the result (root + all descendants, depth-sorted), which is genuine behavioral context for a traversal tool, but it says nothing about read-only safety, chain size limits, pagination, or behavior when the task has no children.

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, no redundancy, with the scope and ordering constraint front-loaded before the usage hint. Every clause earns its place.

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

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

With no output schema, the description must convey the return value, and it does describe the result as the full chain from root, depth-sorted. Missing pagination/size caveats for potentially large chains keeps it short of a 5 for a simple single-parameter tool.

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

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

Schema description coverage is 100% and the schema already explains that task_id is "Any task ID in the chain." The description adds no syntax, format, or edge-case guidance 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 ("Get the full delegation chain for a task") and defines the scope precisely as root plus all descendants sorted by depth, which clearly separates it from retrieving a single task. It does not explicitly name the sibling it differs from (e.g., get_task or get_task_context), so differentiation is inferable rather than stated.

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

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

"Use this to inspect parent/child accountability" gives an implied use case but no explicit when-to-use versus alternatives, and no exclusions or prerequisites. An agent can guess the intent but is not routed away from get_task/get_task_context.

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?

With no annotations, the description carries the full burden and does well: it discloses cursor-based pagination, the critical warning that a fragment is not a complete document, the version-preservation requirement for guarded updates, and that missing keys are reported. It omits any statement about permissions or whether reads can fail, but the operational traits it does surface are high-value.

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

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

Front-loaded with the default behavior and the 'not the whole history' scoping before the mode list. It is dense but every sentence carries operational information; the one advisory sentence ('never mistake a fragment for a complete document') is arguably redundant with the cursor note but earns its place as a warning.

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?

Eight parameters, no output schema, and no annotations — the description covers the read semantics, view modes, pagination, version guarding, and historical-key availability, which is most of what an agent needs. It does not explain the provenance flag or the key-limit/offset paging interplay, which remain schema-only.

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

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

Schema coverage is 100%, so 3 is the floor, and the description adds real meaning on top: the interaction of keys with view selection, the cursor reuse rule ('repeat identical selectors; changed content invalidates the cursor'), and the purpose of version. Minor gaps remain (include_provenance, key_limit, max_chars behavior are only in 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 ('Read selected persistent task state') and immediately scopes it: the default summary returns canonical current-state keys plus a paginated index, explicitly 'not the whole history.' This distinguishes it from sibling tools like get_context_history and get_task without the agent 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?

Gives explicit routing between modes — exact keys for values, view=keys to browse the index, view=full for complete access — and notes that historical noncanonical keys surface through the index. It never names get_context_history as the alternative for history, so the agent must infer the exclusion from 'not the whole history.'

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?

No annotations are provided, so the description carries the full burden. It discloses the environment restriction and error behavior for custom endpoints, but does not mention whether authentication is required or if the operation is read-only (though 'get' implies it). Additional transparency on response behavior might be helpful.

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 extremely concise with two sentences. The first sentence states the purpose, and the second adds a critical usage condition. No wasted words, and key information is front-loaded.

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

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

Given no parameters, no output schema, and no annotations, the description is fairly complete. It specifies what the tool returns and where it works. However, it could briefly mention that the operation is read-only or that it returns current usage values, but overall it is 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?

The input schema has zero parameters, and schema coverage is trivially 100%. The description adds value by explaining what information is returned (quota and rate-limit info) and the environment condition, exceeding the baseline expectation for a no-parameter tool.

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 clearly states the tool retrieves quota and rate-limit information for the current plan, with a specific verb 'Get' and resource 'usage'. It distinguishes itself from sibling tools, which focus on agents, tasks, webhooks, etc., by focusing on plan-level metrics.

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 explicitly restricts usage to the hosted API (api.delega.dev) and notes that custom endpoints receive a clear error. This provides clear context, though it does not explicitly compare to alternatives, which is acceptable given no similar sibling tools exist.

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?

With no annotations, the description carries the full burden and does well: it exposes the reclaim-by-another-agent behavior, the 409 no-longer-holding-claim failure mode, the recovery action, and the hosted-API-only constraint. Auth/permission requirements and the success response shape are not stated, keeping it short of a 5.

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

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

Front-loaded with the core action, then timing, then optional state rationale, then the failure path. Three dense sentences with no filler and nothing repeated from the schema.

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

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

No output schema exists and no annotations are present, so the description must supply context; it covers timing, the 409 failure, recovery, and the hosted-only constraint. The one gap is what a successful call returns (new lease_expires_at), which an agent would benefit from knowing.

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

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

Schema coverage is 100%, so the baseline is 3 and the enum values (working/waiting_input/errored) are already in the schema. The description adds the *purpose* of the state field (so humans/orchestrators see why the claim is held), which is useful framing but not new syntax or constraints.

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 ('Extend the lease on a task you have claimed') that is unmistakably distinct from siblings like claim_task, release_task, and complete_task. An agent can tell exactly what this does without opening a schema.

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

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

Explicitly says to call it periodically before lease_expires_at while working on a long task, and gives a clear when-not path: on a 409, re-claim rather than continue. The trigger condition and the failure recovery are both named.

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?

With no annotations provided, the description carries the full burden. It implies a write operation (attaching a link) but does not disclose whether it requires specific permissions, whether links are idempotent, or what happens on duplicate links. It adds some context but falls short of rich behavioral disclosure.

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-loading the action and then the usage scenario. No wasted words.

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 5-parameter mutation tool with no annotations and no output schema, the description is adequate but incomplete. It doesn't cover return values, error conditions, or behavioral details like idempotency, which are important for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description lists the types of links (branch, commit, PR, URL) which aligns with the 'kind' enum but adds no new semantic meaning beyond the schema.

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

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

The description states a specific verb (attach) and resource (branch/commit/PR/URL link to a task), which is clear and distinct from sibling tools like list_task_links. However, it doesn't explicitly differentiate itself from list_task_links or other task-related tools beyond the linking action.

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 provides a clear usage context ('when work in a repo, PR, or external artifact should travel with the task'), but does not mention when not to use it or name alternatives like list_task_links for viewing links.

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?

With no annotations, the description carries full burden. It discloses role-based behavioral differences (admin vs coordinator views) and hints at read-only nature for coordinators. However, it does not detail the admin full view or any 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 sentences with no wasted words. The first sentence states the primary purpose, and the second adds crucial role-based context. Efficient and front-loaded.

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

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

The description explains what coordinators see but not the full admin view attributes. No information on pagination, sorting, or output format. Given no output schema, more detail on the admin view would improve completeness.

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

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

The tool has zero parameters, so the schema provides no information. The description adds meaning beyond schema by explaining role-dependent output, which is relevant for parameterless tools.

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 clearly specifies the action ('List all registered agents') and resource ('Delega agents'), and distinguishes from sibling tools like register_agent and delete_agent by focusing on listing. It also mentions role-based differences, adding clarity.

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 implies usage for listing agents with role-based views but does not explicitly state when to use this tool vs alternatives or when not to use it. The context from sibling tools helps, but no direct guidance is provided.

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?

Without annotations, the description carries the full burden of behavioral transparency. It indicates a read operation (listing) and includes constraints (admin only, hosted API). However, it does not disclose whether the operation is safe, has side effects, or any rate limits. The transparency is adequate but not detailed.

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 a single sentence that efficiently communicates the tool's action, scope, included data, and usage restrictions. Every phrase is meaningful, and there is no redundancy.

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

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

Given the tool's low complexity (no parameters, no output schema), the description covers the essential information: what is listed, what data is provided, and access constraints. It could be improved by mentioning output format or pagination, but it is sufficient for an agent to use 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?

The tool has no parameters, so the input schema covers 100% of the parameter documentation. According to guidelines, this gives a baseline of 4. The description adds no extra parameter information because none is needed.

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 clearly states the tool lists all automation rules with run/failure counts for the user's account. It specifies 'admin only' and 'Hosted API only', making the purpose and scope unambiguous. It distinguishes itself from sibling tools like create_automation or delete_automation by focusing on listing.

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 clear context that the tool is restricted to administrators and available only on the hosted API. However, it does not explicitly compare to alternatives or state when to use this tool versus other list tools. The usage constraints are helpful but could be more 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?

No annotations are provided, so the description carries the full burden. It discloses important access restrictions (admin, hosted), but does not mention whether the operation is read-only, destructive, or other behavioral traits. Adequate but has gaps.

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 a single efficient sentence with no wasted words. It front-loads the core action and resource, then adds restrictions in a concise manner.

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 list tool with no parameters and no output schema, the description covers the basic purpose and restrictions but does not describe the return format or any additional context about delivery counters. Adequate but incomplete for a fully self-contained description.

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

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

There are zero parameters, so the baseline is 4 per rules. The description does not need to add parameter info, and it correctly explains the tool's purpose without needing to mention parameters.

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

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

The description uses a specific verb 'list' and resource 'inbound connector sources' with additional detail 'with delivery counters'. This clearly distinguishes it from sibling tools like list_agents or list_webhooks.

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 explicitly states 'admin only' and 'Hosted API only', providing clear context on when this tool is applicable. However, it does not mention alternatives or when not to use 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?

No annotations are provided, so the description must disclose behavioral traits. 'List' implies a read-only operation, but specifics like authentication or pagination are absent. The description does not go beyond the implied read-only nature.

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 a single, informative sentence with no filler. It is perfectly sized for a zero-parameter tool.

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

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

For a simple list-all tool with no parameters and no output schema, the description is sufficient. It could mention default output fields or pagination, but the lack is not critical.

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

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

There are 0 parameters, so schema description coverage is 100% vacuously. Baseline for 0 parameters is 4, and the description adds nothing, which is acceptable as no parameters exist.

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 clearly states the action (list) and resource (projects), and the name uniquely identifies it among sibling tools, which all target different resources (tasks, agents, webhooks).

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 implies usage is when all projects are needed, but provides no explicit when-to-use, when-not-to-use, or alternative tools. It is minimally adequate.

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?

Description adds behavioral context (recurrences spawn tasks, completing instance doesn't delete schedule) beyond the empty annotations, but lacks details on auth, rate limits, or 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 sentences, front-loaded with key action, 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?

Given no parameters and no output schema, description adequately covers purpose and key behavior for a simple list tool.

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

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

No parameters in schema; description doesn't need to add param info. Baseline 4 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?

Description clearly states 'List recurring task templates' with a specific verb and resource, distinguishing it from sibling tools like create_recurring_task or update_recurrence.

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 explicit guidance on when to use vs alternatives like list_tasks; behavioral note about completing instances is helpful but doesn't address selection context.

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?

With no annotations, the description carries the full behavioral burden. 'List' implies a safe read operation, but the description does not confirm read-only semantics, pagination, ordering, or whether links are grouped by type. For a single-parameter read tool this is adequate but thin.

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 front-loaded sentence with zero filler that still conveys the resource and its subtypes. Nothing could be cut without losing information.

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

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

For a simple one-parameter read tool with no output schema, the description gives enough to call it correctly, and the enumerated link types partially compensate for the missing return structure. Minor gap: no note on what happens when a task has no links or how results are ordered.

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% — task_id is fully documented as 'The task ID whose links to list'. The description adds no syntax, format, or edge-case detail beyond what the schema already provides, 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 ('List') and resource ('links attached to a task') and even enumerates the link subtypes (branch, commit, pull request, URL), so the agent knows exactly what comes back. It is clearly distinct from siblings like link_task or get_task, though it never names an 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 when-to-use guidance, no mention of prerequisites, and no reference to the sibling link_task that creates these links. Usage is only faintly implied by the verb '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?

No annotations provided, so the description carries the burden and does well: discloses pagination behavior, default limits (25 tasks, 6000 chars), the 'not the whole queue' caveat, role-based visibility (workers vs admins), and mutation etiquette (act/claim/comment). It does not explicitly state side effects beyond comments, but this is a read-list tool.

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

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

Front-loads the core purpose and pagination guidance, then role and action guidance. Dense but every sentence is functional; slightly verbose in the multi-clause policy sentence, but not wasteful.

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 12-param list tool with no output schema, the description covers pagination, visibility, role behavior, and sibling alternatives. It stops short of documenting specific filters (delegated to schema), which is acceptable given 83% coverage. No output schema means more detail on returned fields could help, but the pagination hint covers the main risk.

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 documents most parameters (limit, offset, max_chars, due, etc.). The description reinforces pagination semantics (next_offset with identical filters, page size defaults) but adds little parameter-specific syntax beyond that. 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 (list) and resource (task summaries), specifies the compact paginated form, and distinguishes itself from siblings by naming get_task for details and get_task_context for selected state. An agent can route correctly without opening schemas.

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

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

Explicit alternatives: get_task for details, get_task_context for selected state. Also gives follow-up pagination guidance ('follow next_offset with identical filters') and scopes behavior by role (workers vs coordinators/admins) with action guidance on whose tasks to act on.

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?

No annotations are provided, so the description must disclose behavioral traits. It only states 'list' and 'admin only', without mentioning pagination, rate limits, or any side effects, leaving gaps for a read 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?

The description is a single, concise sentence with no redundant words, efficiently conveying the tool's purpose and access restriction.

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 the tool's simplicity, no parameters, and no output schema, the description adequately covers purpose and access. It could mention the return format, but the omission is minor.

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

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

The input schema has no parameters, so coverage is trivially 100%. The description adds no parameter information, but no additional meaning is needed beyond the empty schema.

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

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

The description clearly states the verb 'List', the resource 'webhooks', and specifies scope 'configured for your account' and access restriction 'admin only', which distinguishes it from sibling tools like create_webhook or delete_webhook.

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 does not provide guidance on when to use this tool versus alternatives. It implies admin-only usage but lacks explicit context on use cases 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?

No annotations provided, so the description carries the full burden. It discloses read-only status, scoping ('scoped to what you can read'), ranking behavior ('human-stated facts weighted highest'), and environment constraint ('Hosted API only'). Missing only rate limits/pagination, but substantially covers 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?

Front-loads the core action and scope, then usage timing, then behavior notes. Dense but every clause earns its place; the 'Lexical match for now' aside is a minor tangent but useful.

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

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

Complete for a read-only search tool with no output schema: return shape described ('key, value, source, and the task they live on'), scoping, ranking, and constraints all covered. An agent has enough to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds value beyond it: ranking behavior for source values and the default-false semantics of include_superseded with retracted entries explained. The query intent example reinforces the 'q' parameter's purpose.

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

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

States a specific verb and resource ('Search your decision-memory') plus a differentiating scope ('across ALL tasks'). Contrasts with sibling get_task_context implicitly by emphasizing recall without knowing the task, making it distinguishable from task-scoped context 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?

Explicit when-to-use ('at the START of new work to avoid re-deciding something already settled') and a stated match-mode limitation ('Lexical match for now... exact-ish terms beat paraphrases'). Gives the agent clear invocation conditions.

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?

Discloses API key one-time return and saving requirement, but lacks info on idempotency, authentication needs, or conflict behavior. No annotations to supplement.

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, front-loaded with action and key warning. No redundancy.

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

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

Adequate for a creation tool: mentions critical output (API key). Missing error handling info but overall sufficient given no output schema.

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

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

Schema description coverage is 100%, so description adds no value beyond the schema. 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?

Clearly states action 'register' and resource 'agent in Delega'. Mentions critical return of API key only at creation, which distinguishes it from list/delete/modify 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?

Implied usage for creating new agents, but no explicit guidance on when to use vs alternatives like 'set_agent_role' or prerequisites.

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

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

With no annotations, the description carries the full burden and does well: it discloses the state transition (back to open, immediately claimable), the visibility of the handoff note to the next claimant, and an environment constraint ('Hosted API only'). It does not cover permission/auth requirements or what happens if the task isn't currently claimed by the caller.

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

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

Three tight sentences: purpose/effect, when to use, and a practical tip. The state-change consequence is front-loaded and nothing is padded.

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

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

For a two-parameter mutation with no output schema and no annotations, the description covers state effects and handoff semantics adequately. Missing permission requirements and error/edge behavior (e.g., releasing an unclaimed or already-completed task) keep it just short of fully complete.

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

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

Schema description coverage is 100%, so the schema already fully documents both task_id and handoff, including the fallback behavior when handoff is omitted. The description reinforces why to supply handoff but adds no syntax or format detail beyond the schema — the baseline 3 applies.

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

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

The description names a specific verb ('Release') and resource ('a task you have claimed') and states the resulting state change ('returns to open status and becomes immediately claimable'). It is clearly distinguishable from siblings like complete_task, claim_task, and set_task_state.

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

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

It gives an explicit trigger condition: 'Use when you cannot finish the work or another agent should take over.' That effectively routes the agent away from complete_task, though no sibling tool is named as an alternative and no negative exclusions are 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?

No annotations are provided, so the description carries the full burden, and it does disclose two non-obvious behaviors: the admin-key authorization requirement and the sandbox-agent prohibition. It stops short of stating side effects such as whether the change is reversible, when it takes effect, or whether it revokes prior permissions.

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

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

Two sentences, zero filler, front-loaded with the action and its authorization requirement. Every clause (role definitions, admin key, sandbox exclusion) carries distinct decision-relevant information.

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

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

For a 2-parameter tool with full schema coverage and no output schema, the description covers purpose, authorization, allowed values, and an eligibility exclusion. The remaining gap is mutation semantics (effect timing, reversibility, whether a role can be downgraded), which an agent changing permissions would want.

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

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

Schema coverage is 100%, so the baseline is 3, and the description genuinely exceeds it by defining what each enum value means operationally (worker/coordinator/admin scopes) rather than leaving the schema's terse 'Role preset to apply'. It adds no new detail for agent_id, which the schema already documents.

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 (set an agent's role) and enumerates the three concrete values with their scope implications (worker = own-task, coordinator = sees/comments on all account tasks, admin = full account management). This is enough to distinguish it from register_agent, list_agents, and delete_agent 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?

Gives a hard precondition (admin key required) and an explicit when-not with the alternative route: sandbox agents 'graduate via the claim flow and cannot be assigned a role.' It does not name sibling tools as alternatives for other cases, but the eligibility rule is concrete and actionable.

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?

With no annotations, the description carries the full burden and does so: it discloses the non-lease-extending semantics, the resulting "held-but-stuck" visibility model, downstream observers (list_tasks/get_task), the 409 failure condition, and the hosted-only hosting constraint. That is exactly the behavioral context annotations would otherwise 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?

Three sentences, front-loaded with the action and its key distinction, then usage, then failure/visibility/support constraints. No filler or repetition.

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

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

No output schema and no annotations, so the description must cover behavior and constraints — which it does (lease semantics, visibility path, 409, hosted-only). An agent has everything needed to decide to call it and to interpret 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 description coverage is 100%, so the 3 is the floor. The description adds intent beyond the raw enum by tying "waiting_input" and "errored" to concrete agent situations (blocked on input, hit an error), though it says nothing about the optional "detail" parameter's role or the 500-char limit.

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

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

Specific verb+resource ("Report the session state of a task you have claimed") with the exact enum values named inline. It cleanly distinguishes itself from sibling heartbeat_task by stating it acts "without extending the lease," and from update_task by scoping to session state only.

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 this to flag that you are blocked on input or hit an error" gives a clear positive trigger, and "Fails with 409 if you no longer hold an active claim" plus "Hosted API only" give prerequisites/constraints. It does not explicitly name heartbeat_task as the contrasting alternative for liveness, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and delivers real value: it discloses the admin auth requirement, the partial-update semantics ('only supplied fields change'), and the non-obvious side effect that setting active=true re-enables a rule auto-disabled after repeated failures. It omits reversibility and any indication that actions/conditions are wholesale replacement (left to the schema), so it is strong but not complete.

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 core action and followed by the two most decision-relevant qualifiers (admin scope and re-enable behavior). Every clause earns its place with no redundancy.

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

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

No output schema and no annotations, so the description must stand on its own, and it covers the key non-schema behaviors (auth scope, partial update, re-enable semantics, hosted-only). The rich 100%-covered schema handles nested action/condition detail, so remaining gaps are minor.

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

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

Schema description coverage is 100%, so the baseline is 3. The description earns an extra point by adding meaning the schema lacks for the active parameter — that setting it true specifically revives an auto-disabled rule, not merely toggling a 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?

States a specific verb+resource ('Update an automation rule'), which is unambiguous against create_automation/delete_automation/list_automations. However, it never explicitly names or contrasts with those siblings, so an agent must infer the distinction from the name alone.

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

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

Gives concrete usage constraints: 'admin only' and 'Hosted API only', which qualify who and where the tool applies. It stops short of explicitly stating when to prefer it over create_automation or how to handle a non-existent rule, so no true when-not guidance is present.

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

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

With no annotations, the description carries the full burden and performs well: partial-update semantics ('only supplied fields change'), secret rotation behavior ('shown once — old secret stops working immediately'), and admin/hosted constraints. It omits any statement about the response shape beyond the one-time secret display, which is the main remaining gap.

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

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

Three compact sentences, front-loaded with the action and scope, then the mutation contract and the destructive rotate_secret consequence. No redundant phrasing 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 mutation tool with no annotations and no output schema, the description covers partial update, secret rotation irreversibility, and environment/auth constraints. It could note what the response returns besides the one-time secret, but is otherwise complete for correct invocation.

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

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

Schema description coverage is 100%, so all 8 parameters are already documented in the schema. The description reinforces the partial-update contract and the one-time secret reveal, but adds little that the schema does not already state, 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?

States a specific verb (update) and resource (inbound connector source) plus scope qualifiers (admin only, Hosted API only). This cleanly separates it from the create/delete/list_ingress_source siblings without needing to name them.

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

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

Gives clear preconditions — admin only and Hosted API only — so the agent knows the required auth and environment context. It does not explicitly name alternatives or when-not-to-use, but for an update operation against an existing source the context is unambiguous.

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?

No annotations are provided, so the description must carry the full burden. It discloses that the tool updates a recurrence and can pause/resume via the active flag, but does not mention permissions, side effects on already spawned tasks, reversibility, or any other behavioral traits. This is minimal for a mutation tool.

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

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

The description is a single, front-loaded sentence that conveys the core action and a key parameter behavior without any wasted words.

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 a complex mutation tool with 16 parameters, no annotations, and no output schema, the description is minimal. It covers the essential action but lacks context on side effects, constraints, or what happens to existing tasks. It is adequate but incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all 16 parameters thoroughly. The description adds only the meaning of the active parameter as pause/resume, which is a small addition beyond the schema's 'Whether the recurrence is active'. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states the verb 'update' and the resource 'recurring task template', which is clear. It does not explicitly differentiate itself from siblings like update_task or create_recurring_task, but the term 'recurrence' aligns with the tool name and distinguishes it from task-level updates.

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 such as update_task or create_recurring_task. The only contextual hint is the use of active=false/true for pause/resume, but this is usage of a parameter, not a when-to-use guide.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not explain whether this is a partial update (are omitted fields left unchanged?), whether clearing a field requires nulls, what permissions are needed, or what happens on conflict — all material for a mutation tool with nine parameters.

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 front-loaded sentence with zero padding, correctly placing the verb and scope first. It is efficient, though its brevity shades into under-specification rather than true conciseness.

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 nine-parameter mutation tool with no annotations and no output schema, the description is far too thin. Partial-update semantics, permission requirements, and expected outcome are all absent, leaving the agent to infer critical behavior 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 100%, so every parameter already carries its own description (including the admin-key caveat on evidence_policy). The description adds no syntax, format, or field-level meaning beyond the schema, which is the baseline-3 case when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Update an existing task's fields'), so the agent knows this mutates an existing task rather than creating one. However, it offers no differentiation from siblings that also modify tasks (assign_task, delegate_task, set_task_state, complete_task, update_task_context), which an agent must disambiguate by name alone.

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, no prerequisites, and no mention of alternatives such as assign_task or set_task_state for state changes. The agent gets no help deciding between this and the many other task-mutating siblings.

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?

With no annotations provided, the description carries the full behavioral burden and does so: it discloses merge-vs-replace semantics, optimistic concurrency via expected_version, atomic conflict behavior (a conflict applies no write), and the shape of the response (compact acknowledgment, not merged history). This is unusually complete disclosure for a mutation tool.

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

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

Five tight sentences, front-loaded with what the tool does, followed by usage, concurrency guidance, return shape, and conflict handling. No sentence is redundant or padded.

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

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

Despite having no annotations and no output schema, the description covers mutation semantics, return value, concurrency guard, and conflict resolution. An agent has everything needed to call it correctly and to react to failures.

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

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

Schema description coverage is 100%, so the schema already documents task_id, context, source, and expected_version, making 3 the baseline. The description adds useful meaning beyond the schema by tying expected_version to its source (get_task_context) and framing it as a guard against concurrent writes, plus the merge-and-retry procedure when it fails.

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 precise verb+resource pair (merge keys into persistent task context) and immediately distinguishes the operation from its siblings by specifying merge-not-replace semantics, which separates it from get_task_context and get_context_history.

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 explicit when-to-use guidance (keep a compact current_state/next_step, retrieve history only when needed) and names the concrete alternative for history via the get_task_context/get_context_history flow. It also prescribes the failure path: on conflict, read current keys, merge and retry explicitly.

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