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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It discloses the default non-waking behavior, the opt-in agent run semantics, the required OAuth scope, and the side effect on todo task state — all beyond what the schema states.

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

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

Three tightly written sentences with no filler: purpose first, then the agent-spend nuance, then auth and side-effect. Every sentence earns its place and the most important differentiator (no provider spend by default) 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?

Covers purpose, auth, default versus agent-run behavior, and the non-obvious task-state side effect, which are the essentials for calling this mutation tool. It does not describe the response shape or idempotency_key behavior, but those are minor gaps given the simple operation.

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

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

Schema coverage is 80%, so the schema already documents most parameters. The description mostly echoes start_agent_run semantics already present in the schema and adds no new meaning for key, body, or pinned; idempotency_key remains undocumented in both the schema and description.

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

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

Opens with a specific verb and resource: 'Post a comment on a task,' which clearly identifies the operation and separates it from read-only siblings like get-comments and from task-mutation tools like update-task. The mention of 'thread' and agent behavior further reinforces the intended function.

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 clear invocation context: requires comments:write scope, explains the default no-agent-spend behavior versus start_agent_run=true, and warns that a comment moves a todo task to in_progress. It does not explicitly name alternatives or state when not to use it, 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 behavioral burden, and it delivers useful details: the server assigns the key, status/assignees/labels accept friendly values, and Goby has no issue types/sprints. This goes beyond the schema and prevents likely misconceptions. It stops short of describing the response shape, but the core side effects and constraints are clearly disclosed.

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

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

Two sentences, no filler, and the key facts are front-loaded. The first sentence identifies the action, the second delivers the most important behavioral caveats. 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 9-parameter tool with no output schema, the description covers the essential Goby-specific context and the most error-prone input semantics. The schema documents the remaining parameters, including idempotency_key and due_at. A note about the response would have made it fully complete, but the current description is sufficient for an agent to invoke the tool 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 78%, so the description must add meaning for the less-documented space. It does, by explaining that friendly values work for status, assignees, and labels, and by clarifying that priority is 1 highest to 3. This complements the schema's own descriptions and helps the agent supply valid values for the trickiest 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 opens with a specific verb and resource: 'Create a Goby task.' It also distinguishes this from sibling tools like update-task by framing it as the creation action, and clarifies that the key is server-assigned, so no client-supplied key is expected. This leaves no ambiguity about the tool's role.

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 it: whenever a new task should be created. It provides Goby-specific modeling guidance ('no issue types or sprints, use priority and labels') that helps an agent avoid using unsupported concepts, but it does not explicitly name alternatives like update-task or state when not to use this tool. Usage context is present but not explicit.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses a critical one-time secret behavior ('signing secret is returned ONCE here and can never be read back') and the required scope, which is valuable for an agent to invoke correctly. Does not cover rate limits or idempotency, but covers the key operational caveat.

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 the core purpose, a critical one-time secret warning, and an auth requirement. Information is front-loaded and every sentence earns its place.

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

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

The description covers purpose, security-critical behavior (secret returned once), and required scope. It lacks output details and explicit event semantics, but the schema covers event defaults and the tool is straightforward to invoke 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 schema already describes url and events. The description adds 'HTTPS endpoint' and mentions task events, but does not add meaningful parameter details beyond the schema. With 67% schema coveragehare, this is adequate but not enhanced by the description.

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

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

The description uses a specific verb ('Register') and resource ('HTTPS endpoint to receive task events'). It clearly distinguishes this from sibling tools like list-webhooks and update-webhook by stating the creation action and its 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 states the necessary scope (webhooks:write), which is a clear prerequisite, and implies this is the tool to use when registering a webhook. However, it does not explicitly say when to prefer this over alternatives or mention exclusion cases.

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 burden of behavioral disclosure. It clearly states the operation is permanent, which is critical for a destructive action. However, it doesn't mention side effects (e.g., whether the webhook stops receiving events immediately, whether related data is affected, or if any confirmation is required). The permanence warning is valuable but incomplete for a destructive 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 sentence that front-loads the core action and permanence, then adds a practical usage note about secret rotation. Every word earns its place; 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 one-parameter destructive tool with no output schema, the description covers the essential context: what it does, that it's permanent, and a common workflow (secret rotation). It doesn't explain return values or error cases, but with a single id parameter and no output schema, the missing details are minor. The sibling list includes create-webhook and update-webhook, and the description's rotation note helps disambiguate.

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%: the only parameter 'id' is described as 'Webhook uuid' with minLength 1. The description adds no additional parameter-level meaning beyond the schema. Baseline 3 is appropriate since the schema fully documents 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?

The description states a specific verb ('Delete') and resource ('webhook endpoint'), and adds the permanence qualifier ('permanently'). It also distinguishes itself from update-webhook by explicitly noting that secret rotation is done via delete-then-create, which helps an agent understand this tool's role relative to its 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?

The description gives clear context for when to use this tool: to delete a webhook permanently, and notably for secret rotation via delete-then-create. It doesn't explicitly name alternatives like update-webhook for non-rotation changes, but the rotation hint implies the workflow. A small gap is not stating when NOT to use it (e.g., for temporary disabling), but the guidance is otherwise useful.

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 meaningful behavioral traits: the chronological ordering, the exact message categories included, and the required OAuth scope (comments:read). It does not describe potential error cases or pagination, but for a simple read operation it provides solid transparency.

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

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

Two compact sentences with no filler. The core behavior is front-loaded, and the scope requirement is stated in the second sentence. Every word contributes useful 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 single-parameter, read-only tool with no output schema and no annotations, the description is mostly complete: it defines the resource, ordering, message kinds, and authentication scope. It does not explain response shape or failure behavior, but those are less critical for a straightforward list operation.

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

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

The schema already documents the single parameter 'key' with a clear example format (OPS-42). Since schema description coverage is 100%, the description does not need to add parameter detail. It adds no extra semantic value beyond the schema, matching the baseline.

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

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

The description states a specific verb and resource: it retrieves a task's conversation, explicitly listing the message types (user, agent, system) and ordering (oldest first). This clearly distinguishes it from sibling tools like add-comment or get-task.

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

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

The description implies its use case—reading a task's conversation—and mentions the required scope, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is clear enough for an agent to infer the purpose, but exclusions and alternative routing are absent.

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 indicates read behavior ('Fetch') plus that the result includes the task description field. No annotations are provided, so the description carries the full burden, but for a simple read there are no destructive or mutating traits to disclose. It could mention not-found behavior, but that's a minor gap for a simple get 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?

One sentence, front-loaded with the key identification and what's returned. 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?

Simple one-param get tool, so completeness is mostly met. However, no annotations and no output schema means it doesn't disclose error/not-found behavior or permission requirements, though for a simple fetch by key it's otherwise sufficient. Sibling context clarifies there are related list/update tools.

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 documents the key parameter with format example, and the description reinforces the key's purpose by tying it to the task identifier. There is only one parameter, so no significant gap. The description adds context about type of key.

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 ('Fetch'), resource ('one task'), and key identifier format with an example ('OPS-42'). This clearly distinguishes it from list-tasks, which retrieves multiple tasks.

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 appropriate use: fetch a single task by key. It does not explicitly say when not to use it or mention list-tasks as the alternative for broader queries, so guidance is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden, and it delivers useful traits: newest-first ordering, content exclusions, and the limited scope to recorded workflow changes. It does not explicitly state read-only behavior, auth requirements, or pagination behavior, but the 'get' verb and 'recorded changes' phrasing imply a non-mutating history lookup.

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 conveys the tool's core purpose, scope, ordering, and an important distinction from comments. There is no wasted wording.

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 sufficiently conveys what a call returns (status, assignee, due-date changes, newest first) even without an output schema. It does not explain cursor/limit semantics or pagination flow, but for a simple task-history tool the core information an agent needs is present.

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

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

Schema description coverage is only 33%: only the 'key' parameter is described, while 'limit' and 'cursor' have no schema descriptions. The tool description adds no parameter-level meaning, so it does not compensate for the low coverage.

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 ('get'), resource ('a task's recorded workflow changes'), and the fields involved (status, assignee, due date), plus ordering ('newest first'). It also distinguishes itself from comment retrieval with 'Carries no message content,' so an agent can separate it from siblings like get-comments.

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 clearly implies when to use it (when a task's workflow history is needed) and includes an exclusion ('Carries no message content'), steering agents away from using it for message content. However, it does not explicitly name alternatives or state when-not-to-use conditions, leaving some inference to the agent.

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 of explaining behavior. It transparently discloses that labels come from existing tasks and that Goby has no labels endpoint, which meaningfully shapes expectations. It could add output format details, but the core caveat is 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?

A single sentence that front-loads the core purpose and adds a concise parenthetical caveat. There is no fluff 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?

The description is sufficient for a simple, parameterless listing tool. It states what is listed徒 and the main limitation. A small gap is not describing the response shape, but that is minor given the simplicity and absence of an 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?

The tool takes no parameters elaborately, so there is little for the description to add. The baseline for zero-parameter tools is 4, and the description does clarify the semantic scope ('labels in use on the team's tasks').

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 identifies the resource ('labels in use on the team's tasks') and the tool's purpose (listing them). It also distinguishes this from a generic label endpoint by noting labels are harvested from existing tasks.

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 about what the tool returns and a key limitation (labels not yet used won't appear). There are no alternative label tools among siblings, so no explicit when-not-to-use guidance is needed.

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

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

No annotations or output schema exist, so the description carries the behavioral disclosure burden. It clarifies that results are legal assignee values and warns about name ambiguity, but doesn't state return shape, pagination, or any ordering/filter behavior. Still, for a zero-parameter list call the core behavior is reasonably clear.

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; the key scoping detail ('legal assignee values') and operational preference (email over names) are front-loaded in a compact format.

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

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

For a parameterless listing tool with no output schema and no sibling ambiguity on resource type, the description provides enough context: what is returned and how to disambiguate members. It doesn't mention pagination or output fields, but this is a minimal tool requiring little extra context.

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, and the schema has no properties. The description adds useful semantic context about what the returned members represent ('legal assignee values') rather than being a bare tautology.

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 identifies the tool's purpose: listing the team's members, specifically as legal assignee values. The verb 'list' plus the resource 'members' is unambiguoushare and is distinguished from sibling list-* tools by clarifying what is being listed.

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 concrete usage guidance: prefer matching by email because names are ambiguous. This tells an agent how to correctly use the returned data. It doesn't explicitly contrast with sibling list tools, but each sibling targets a different resource, so no exclusion is necessary.

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 burden. It discloses that tokens are masked and that the tool lists all stored per-project tokens, which is useful. However, it does not mention whether the command has side effects, requires authentication, or what happens if no tokens exist. For a read-only listing tool, this 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?

Two sentences, front-loaded with the core purpose and output details, followed by a clear usage trigger. 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 zero-parameter, read-only listing tool, the description covers what it shows, the masking behavior, and when to use it. It does not describe the output format, but with no output schema and a simple listing use case, the description is sufficiently complete for an agent to select and invoke it correctly.

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

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

The tool has zero parameters, and schema description coverage is 100%, so there is nothing for the description to add about parameters. The description instead clarifies the scope of the output (current project directory, all stored per-project tokens), which is the relevant semantic context. Baseline 4 for zero-parameter tools 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 clearly states the tool's function: showing which Goby token is active for the current project directory, its origin, and all stored per-project tokens. It uses a specific verb ('Show') and resource ('Goby token'), and it distinguishes itself from sibling tools like set-project-token and remove-project-token by focusing on listing/displaying rather than modifying.

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 says to use this tool first when a Goby call fails with unauthorized or 'no token configured'. This provides clear when-to-use guidance and implies it is a diagnostic first step, which differentiates it from token management 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 are provided, so the description carries the full burden. It discloses that the tool provides legal status values, but it does not explicitly state that this is a read-only operation, nor describe output shape, ordering, or freshness. The list implication is clear, but behavioral detail is minimal.

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 that is compact, informative, and front-loads the core purpose. It also connects the values to the tools that consume them, making it efficient and purposeful.

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 zero-parameter listing tool, the description is largely complete: it names the resource, its role, and its consumers. It could be more explicit about output format or read-only nature, but the lack of parameters and simple purpose reduce the need for extensive detail.

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 i.e., no parameters to document. The description adds semantic meaning by explaining what the returned statuses represent, which is more context than the empty schema alone provides.

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 identifies the resource ('team's board columns'), the operation (list), and the semantic role (legal status values for task operations). It sets the tool apart from siblings like list-labels and list-tasks by describing exactly what these values are for.

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 it: before create-task, update-task, or list-tasks to know valid status values. It does not explicitly state exclusions or contrast with sibling tools, but the usage context is clear enough from the reference to those task operations.

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 burden. It discloses key behaviors: default exclusion of completed tasks, ordering by newest-updated, and filter combination logic (AND with specific unions for status/status_in and assignee/unassigned). This goes beyond the schema by clarifying default behavior and filter semantics. It doesn't mention pagination, error handling, or response format, but for a read-only list tool, the provided details are fairly 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 exactly two sentences. It front-loads the core purpose and ordering, then covers the key default and filter combination behavior. No unnecessary fluff. Every word earns its place, making it easy for an agent to quickly grasp the tool's essence.

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 list tool with 15 optional parameters and no output schema, the description provides essential context: default exclusion of done tasks, ordering, and filter combination. It doesn't explain the response structure or pagination, but those are typically handled by the client and not critical for correct invocation. The sibling tools (like create-task, update-task) are distinct enough, and the parameter list is well-documented in the schema. The description is complete for making the right call, though adding a note about response being a list could help.

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 schema description coverage is 87%, so the schema already documents most parameters. However, the description adds value by explaining the combination rules (AND across filters, unions for status and assignee), which is not in the schema. This helps the agent understand how to combine filters correctly, which is crucial for effective search. It doesn't describe every parameter in detail, but schema covers them. Given the high coverage, baseline 3, and the added combination logic, a 4 is justified.

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 it lists and searches tasks, with a specific ordering (newest-updated first) and default exclusion of completed tasks. It distinguishes itself from sibling tools like get-task and create-task by focusing on list/search and from list-statuses and list-members by the resource type. It also mentions filter combination behavior, adding specificity beyond a generic 'list tasks'.

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 clearly indicates when to use this tool: to list or search tasks, with filters. It does not explicitly mention when not to use it or name direct alternatives, but the inclusion of 'get-task' as a sibling and the description of this being a list operation implies the choice. It lacks explicit exclusions, but the context (titles of siblings) is clear enough for a well-functioning agent.

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?

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?

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?

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?

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

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

The description identifies the resource (

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?

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 burden. It discloses the default directory behavior and that the operation 'forgets' the token, implying a destructive/irreversible action. However, it doesn't state whether the token is removed from disk, whether it affects other projects, or whether confirmation is needed. The word 'Forget' gives some transparency but not full detail.

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

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

The description is a single sentence that is concise and front-loaded with the action. It includes the default behavior and the parameter guidance without unnecessary words. Every part 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 simple one-parameter tool with no output schema, the description is mostly complete. It explains the default directory and the action. The only gap is the lack of detail about what 'forget' means behaviorally (e.g., irreversible, scope), but given the simplicity and the parameter schema, 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?

Schema coverage is 100% and the parameter description is already detailed, explaining the default and when to pass it explicitly. The description adds the context that the directory defaults to the current one, which aligns with the schema. With full schema coverage, the baseline is 3, but the description's explicit 'when unsure' guidance adds value, so a 4 is warranted.

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 ('Forget the stored Goby token') and the resource ('for a project directory'), with a default behavior noted. It is distinct from sibling tools like set-project-token and list-project-tokens, which are about creating/listing tokens rather than removing 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?

The description implies when to use it: when you want to remove a stored token for a project directory. It doesn't explicitly contrast with alternatives, but the sibling set makes the purpose clear. The parameter description adds guidance about when to pass dir explicitly ('when unsure'), which helps usage.

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 discloses key side effects: tokens are written to the user's config file (not the repo), take effect immediately without restart, and apply to all subdirectories. It does not mention overwrite behavior or error conditions, but the stated persistence and scope are valuable beyond a bare 'set token' statement.

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 zero filler. The core purpose and side effects are front-loaded, and every clause earns its place. It is concise without omitting essential 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 three parameters and no output schema, the description covers the main behavioral aspects (persistence, scope, immediacy) and the schema covers parameter details. It does not explain the response format or failure modes, but these are not critical for the agent to call the tool correctly. Overall, it is sufficiently complete.

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

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

Schema coverage is 100%—every parameter (dir, api_key, base_url) has a description in the input schema. The tool description adds no new parameter-specific details; it only refers to 'project directory' which the schema already explains. Per the rubric, baseline 3 is appropriate when the schema handles parameter documentation.

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

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

The description clearly states the action ('Store a Goby API key') and the resource ('for a project directory'), and explains the effect on subsequent tool runs. It distinguishes itself from sibling tools list-project-tokens and remove-project-token by focusing on the set operation, leaving no ambiguity about what it does.

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 this sets a project-scoped token for all Goby tool runs, but it does not explicitly mention when not to use it or name alternatives like list-project-tokens/remove-project-token. The 'when' is implied by the purpose but not stated as a comparison, so it falls short of the explicit guidance 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 provided, the description carries the behavioral burden and does disclose PATCH semantics, the use of clear_* flags, and a permission requirement (key owner must be participant or team lead). However, it omits return format, error behavior, and side effects such as history or notification updates, so transparency is only partial.

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

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

The description is two tightly scoped sentences, front-loaded with the core action and semantics. It avoids redundancy and does not repeat schema-level details, making it highly efficient for an agent to parse.

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

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

For a mutation tool with no output schema, no annotations, and low schema coverage, the description is not complete enough for confident invocation. It covers core semantics and permissions but lacks return-value expectations, error conditions, and parameter-level detail for a 13-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 only 38%, and the description does not compensate for the eight undocumented parameters. It explains the general clear_* flag pattern and PATCH behavior, but fails to clarify priority, assignees, estimate_hours, or the clear flags' exact semantics, leaving much of the parameter surface ambiguous.

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

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

The description clearly states the verb 'Update' and the resource 'a task's fields,' and distinguishes it from create/list/get siblings by specifying PATCH semantics. The mention of clear_* flags further clarifies the intended mutation behavior, so an agent can select this tool unambiguously.

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

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

The description provides no explicit guidance on when to use this tool versus create-task or other task-related tools, nor any when-not-to-use conditions. It implies usage through PATCH semantics but leaves the agent to infer the appropriate context from the sibling list.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that updates are partial ('any subset') and introduces the important behavior that endpoints can be auto-disabled and later re-enabled. It does not mention authorization, failure modes, or response shape, but it adds meaningful behavioral context beyond the name and 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?

The description is two concise sentences with no filler. The core update purpose and field scope are front-loaded, and the re-enable guidance adds practical value rather than repetition.

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

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

For a five-parameter mutation tool with no annotations and no output schema, the description is reasonably useful but not complete. It captures the main action and one important edge case, but it leaves out failure/error behavior, whether other fields are preserved on partial update, and what the caller should expect after the update.

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

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

Schema description coverage is only 20%, so the description needs to compensate, but the parameter list mostly repeats schema property names. The useful addition is 'any subset', indicating optional partial updates, and the enabled=true behavior. However, it does not explain semantics like what events represent, how the URL is validated, or what the id parameter refers to beyond structured field names.

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

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

The description opens with the verb 'Update' and names both the resource ('webhook') and the mutable set of fields ('name, url, events or enabled flag'). It also clarifies the partial-update scope with 'any subset', which distinguishes this from create-webhook 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?

The description communicates context: this tool changes an existing webhook and supports partial updates of only the fields provided. The second sentence adds a concrete and valuable use case, re-enabling an auto-disabled webhook after fixing the receiver. It does not explicitly say when to choose update-webhook over create-webhook or list-webhooks, but the intent is clear.

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?

Since no annotations are provided, the description must carry the behavioral burden. It does explain that the tool verifies the key and returns team/scopes/borrowed-access info. However, it never explicitly states whether the operation is read-only, whether it has side effects, or whether a specific authentication state is required to succeed. That makes it adequate but not fully transparent.

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, dense sentence that front-loads the action ('Verify') before the details. Every phrase adds meaningful information: team, key prefix, scopes, and borrowed access. No filler words. This is a model of 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?

The tool has no output schema, so the description must explain its output. It clearly lists the types of information returned, which is sufficient for an agent to plan subsequent calls (e.g., knowing which scopes are allowed). It does not specify return formatting or error states, but for a whoami-like call this is a minor omission; the core information is there.

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 and the schema confirms that. Since no user input is required, the description needs no parameter explanation. Baseline 4 applies because the description is not required to compensate for missing parameter docs.

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 very specific action ('Verify the Goby API key') and enumerates exactly what the agent learns (team, task key prefix, scopes, borrowed access). This clearly distinguishes it from sibling tools like list-tasks or get-task, which all target different resources or datastore operations.

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 makes the context clear: the tool inspects the current API key context. It does not explicitly name alternatives or exclusions, but because it is the only tool that introspects identity among 19 siblings, an agent can immediately recognize when to use it. The absence of explicit when-not guidance keeps it at a 4 rather than a 5.

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