Goodeye

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

With no annotations providing behavioral hints, the description fully discloses the effects: creating a member row for team_membership or transferring ownership for ownership invitations, and returning the result payload. This exceeds the typical burden for 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?

The description is concise, with three sentences that front-load the main action and efficiently cover preconditions, behavioral details, and return value. No unnecessary words 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?

Given the tool's simplicity (one parameter, output schema exists), the description covers purpose, preconditions, effects, and return. It lacks info on error cases or permissions but is largely complete, warranting a score of 4.

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 covers the single parameter with 100% description, including its purpose as a UUID. The description adds no additional semantic value beyond what the schema already provides, so the baseline score of 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?

The description clearly states the tool accepts a pending invitation, specifying the two types of invitations (team_membership and ownership) and their outcomes. While the purpose is distinct from siblings like cancel_invitation or decline_invitation, it does not explicitly differentiate itself, so a score of 4 is appropriate.

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 for usage: the invitation must be pending and not expired. However, it does not mention when to use alternatives (e.g., decline_invitation), which prevents a higher score. It achieves a 4 for clear usage context without exclusions.

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

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

Annotations already indicate a write operation (readOnlyHint=false). The description adds value by specifying the 'Owner only' constraint, which is critical for correct invocation. It does not detail potential side effects like duplicate handling, but the owner requirement is a meaningful 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-loaded with the core action. Every sentence provides distinct information: the action, the owner constraint, and identifier formats. 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?

While the output schema is present (covering return values), the description lacks important context such as error conditions (e.g., if user already a team member), relationship to invitation flow, or required user existence. For a simple tool, this is adequate but not comprehensive.

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 already describes both parameters well. The description only reiterates that user_identifier accepts UUID, email, or handle, which is already in the schema. No additional meaning is added 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?

Description clearly states the verb 'Add' and resource 'user to a team', making the action unambiguous. It also specifies the owner-only restriction and accepted identifier formats, differentiating it from sibling tools like remove_team_member and list_team_members.

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 context ('Owner only') but does not explicitly state when to use versus alternatives like invitations or other team management tools. No mention of prerequisites like user existence or team membership status.

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

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

Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds rich behavioral context: owner-only access, slug occupation, hiding from public listing, fork persistence, metadata update on lineage, and idempotency for already-archived templates. No contradictions with annotations.

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

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

The description is concise, with four focused sentences. It front-loads the main action and identifier format, then lists key behavioral effects and conditions. 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?

Given the simple parameter set (2 params) and existence of an output schema, the description covers the main action, ownership, idempotency, effects on slugs and forks, and visibility. It sufficiently explains the tool's behavior 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 coverage is 100%, so baseline is 3. The description does not add new meaning beyond what the schema provides for 'template_id' (UUID or @handle/slug) and 'archive_reason' (optional note). It mentions 'Owner only' but that's not tied to a specific 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 clearly states the tool archives a template by UUID or @handle/slug. It distinguishes from siblings like 'delete_template' (archiving keeps slug occupied and hides from public, but forks keep working) and 'unarchive_template' (reverse action). The verb 'Archive' and resource 'template' are specific.

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 specifies 'Owner only' as a usage constraint, and explains effects (slug occupied, hidden from public, forks continue). It implicitly contrasts with deletion and unarchiving, but does not explicitly name alternatives like 'delete_template' or 'unarchive_template'. This is clear but lacks explicit exclusionary guidance.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false. Description adds value by explaining that archived_at is set and the slug remains occupied, beyond what annotations provide. No contradiction.

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 core purpose and idempotency. No unnecessary 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 the simple nature (one param, annotations covering idempotency and non-destructiveness, and an output schema exists), the description is complete. No missing critical info.

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 with 100% schema description coverage. Description does not add any additional semantic or behavioral info beyond the schema's description of workflow_id. 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?

Clearly states the action 'archive' on resource 'workflow you own'. The term 'Idempotent' adds precision. Distinguishes from siblings like delete_workflow and unarchive_workflow.

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 notes idempotency and behavior of keeping the slug occupied, which implies when to use (archive vs delete). However, no explicit when-not-to-use or alternatives given.

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

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

Describes the full audit process: assesses against rubric, runs verifier, produces report, and applies user-approved fixes via save_workflow. Aligns with readOnlyHint=true as it does not modify state itself. No contradictions.

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?

Somewhat verbose with an unclear opening line ('Return the goodeye-workflow-audit pack'). Multiple sentences could be streamlined for clarity.

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 one parameter and output schema exists, the description explains return format and process. Provides adequate context for selecting and invoking the tool, though could be more concise.

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 schema description already explains the parameter. The main description adds the context of 'local skill' but not significantly beyond the schema. 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?

Clearly states it audits workflows (remote or local) and produces a prioritized report with fixes. Distinguishes from sibling tools like check_workflow_safety or optimize_workflow by describing the audit rubric and verifier integration, but the first line 'Return the goodeye-workflow-audit pack' is confusing.

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?

Explains when to use with workflow_id for registry workflows vs. without for local skills, including access requirements. Does not explicitly state when not to use or mention alternatives like check_workflow_safety.

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 the state change (resolution='cancelled') and the effect on the recipient, beyond what annotations provide. It confirms the mutation (readOnlyHint=false) and non-destructive (destructiveHint=false) nature, with idempotency implied but not elaborated. No contradiction with annotations.

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

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

The description is extremely concise with three short sentences, each adding crucial information: purpose, effect, and return value. No redundant 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 the simple tool with one parameter and an output schema, the description is mostly complete. It covers purpose, constraint, outcome, and return format. However, it could mention error scenarios (e.g., if not proposer or invitation already processed).

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 does not add significant meaning beyond the schema's description of invitation_id as a UUID, but it confirms the parameter's role in the cancellation action.

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 'cancel' and the resource 'pending invitation you sent', with a scope constraint 'proposer only'. It effectively distinguishes this tool from its siblings like accept_invitation and decline_invitation.

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 specifies the user must be the proposer and explains the effect (recipient cannot accept/decline). However, it does not explicitly state when not to use it or mention alternative tools, though the sibling context provides some guidance.

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

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

Annotations (readOnlyHint=false, destructiveHint=false) indicate it's not read-only or destructive. The description adds that it 'Bills two metered verifier runs against the caller', disclosing a cost implication not captured in annotations. It also describes the output structure without contradiction.

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 paragraphs, concise and front-loaded with the main purpose. It includes necessary details without being verbose. Could be slightly more structured, 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?

Given the complexity (two verifiers, billing, multiple ID formats, output fields) and presence of an output schema, the description adequately covers the tool's behavior and effects. It mentions billing and status outcomes, which is sufficient for the agent.

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% with descriptions for both parameters. The description adds value by explaining that template_id can be a UUID, slug, or @handle/slug, and reinforces the version parameter's behavior. This goes beyond the schema descriptions.

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 runs both system safety verifiers on a published template version. It specifies the verb 'run', the resource 'template version', and the scope 'both system safety verifiers'. This distinguishes it from siblings like 'check_workflow_safety' and 'run_verifier'.

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 explains how to specify the template (UUID, slug, @handle/slug) and defaults to the latest live version. It mentions billing and different access patterns (REST vs MCP). While it doesn't explicitly state when not to use, it provides sufficient context for 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?

The description adds behavioral context beyond annotations: it bills two metered verifier runs, describes the combined status and per-side block/advisory fields, and notes visibility rules. Annotations only supply non-safety hints, so the description carries the transparency burden well.

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 redundant sentences. It is front-loaded with the main purpose. While a bullet list might improve readability, the current structure is clear and compact.

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 presence of an output schema (mentioned in context), the description sufficiently covers identification, visibility, billing, and default version. It includes key output statuses and fields, making it complete for a safety check tool.

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

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

Schema coverage is 100%, but the description adds meaning: it clarifies default version behavior ('Defaults to the latest version') and access context ('visibility mirrors get_workflow'). This enhances understanding beyond schema alone.

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 runs both system safety verifiers on a workflow version. It specifies resolution of UUID/slug, visibility, and default version, distinguishing it from siblings like run_verifier (single verifier) and check_template_safety (templates).

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

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

The description implies when to use this tool (when both safety verifiers are needed) but does not explicitly state when not to use it or mention alternatives like run_verifier for single verifier runs. Usage guidance is implied but lacks clear 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?

Beyond annotations (idempotentHint=true, etc.), the description adds validation against reserved list, collision rejection, and field stamping. It also clarifies idempotency behavior for re-submission, providing useful context.

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

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

Description is three concise sentences with purpose first, then behavior, then idempotency. Every sentence adds value; no unnecessary 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 simple one-parameter tool with an output schema, the description covers purpose, validation, idempotency, and effects. Given the annotations and schema details, it feels 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 covers 100% with a clear description for the handle parameter. The description adds that handle is validated against a reserved list, but does not add significant new 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?

Description clearly states 'Claim a handle for the authenticated caller', specifying the verb, resource, and actor. This distinguishes it from sibling tools like rename_handle or accept_invitation.

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 first-time handle claiming but lacks explicit guidance on when not to use it or mention of alternatives like rename_handle. Contextual information 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?

Discloses handle immutability and namespace sharing, and failure condition. However, with no behavioral hints in annotations (all false), description could elaborate more on side effects or permissions required. It adds some value beyond annotations but is not exhaustive.

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 that front-load the primary action and add key constraints. 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 single-parameter creation tool with an output schema, the description covers the essential failure condition and handle behavior. It feels complete for the tool's complexity, though it could briefly mention what the response contains (but output schema likely covers that).

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% with a detailed description of the handle parameter. The description repeats the immutability and namespace info already present in the schema, adding no new semantic information, so baseline of 3 is appropriate.

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

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

The description clearly states it creates a team owned by the caller, with specific verb and resource. It is unambiguous and distinct from sibling tools like delete_team or list_teams.

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 failure condition (handle_not_claimed if provisional handle held) and notes handle namespace sharing, offering context for when to use. Lacks explicit alternatives but given uniqueness of the tool, guidance 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?

Annotations already provide idempotentHint=true and destructiveHint=false. The description adds detail: sets resolution='declined', mentions idempotency with an error (InvitationAlreadyResolved), and notes re-invite possibility. No contradictions.

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 concise with two effective sentences. It front-loads the main action and adds necessary behavioral details without superfluous text.

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

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

Given the simplicity of the tool (single parameter, clear output from idempotency and error behavior), the description covers all necessary context. The presence of an output schema means return values are handled separately.

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 only parameter, invitation_id, is fully described in the schema (100% coverage). The tool description does not add extra semantic information 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?

The description clearly states the action: 'Decline a pending invitation addressed to the caller.' It differentiates from siblings like accept_invitation and cancel_invitation by its specific verb and target.

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

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

The description implies when to use (declining a pending invitation) and provides context: 'The proposer may re-invite after this.' However, it does not explicitly state when not to use it or compare with alternatives.

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

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

Annotations already indicate destructiveHint=true. The description adds critical details: permanent removal, condition on shared bytes, no recovery path, and 404 with existence masking. No contradiction with annotations.

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

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

Four sentences, each providing necessary information: action, effect, error case, return value. No redundancy. Front-loaded with the core action.

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 simplicity of the tool (1 param, no output schema shown but description gives return JSON), the description is fully sufficient. It covers behavior, errors, and result.

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

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

Only one parameter (image_id) with schema description already explaining it. The description references 'by id' but doesn't add new semantic context. Schema coverage is 100%, so 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?

The description clearly states it hard-deletes a hosted image by id. It distinguishes itself from sibling tools like `delete_image_generator` by specifying the resource. The verb 'delete' and resource 'image' are 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?

It mentions ownership requirement and permanent deletion, implying when not to use (if you don't own the image or want recovery). It also notes existence masking, which is important context. However, it does not explicitly list alternatives for similar actions.

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?

Beyond the destructiveHint annotation, the description details the full extent of destruction: all versions, run records, anonymous run records are removed, no recovery path. It also covers edge cases like platform-managed generators surfacing as NotFound and no confirmation token needed. These behaviors are not apparent from annotations alone.

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

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

The description is well-organized: begins with the primary action, then covers permanence, alternatives, constraints, edge cases, and return value. While detailed, every sentence adds unique information, with no superfluous content. It is slightly lengthy but efficient for the complexity.

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 comprehensively covers the tool's context: scope, irreversibility, alternative, conflict conditions, edge cases for system generators, return format, and backup retention policy. Given the tool's destructive nature and with an output schema indicated, the description is 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?

The single parameter generator_id is described in the schema as a UUID, and the description adds that it accepts a UUID string, which is not explicitly in the schema format. It also clarifies the scope constraint (own generator) beyond the schema. Since schema coverage is 100% and the description adds practical context, a 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 clearly states the tool 'permanently and immediately erase an image generator you own' with specific verb 'erase' and resource 'image generator'. It distinguishes from sibling tool 'revoke_image_generator', which is explicitly mentioned as an alternative.

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 guidance on when to use vs. revoke: 'Use revoke_image_generator if you want to deactivate the generator without erasing it'. Also mentions prerequisite about unpublishing template versions that reference the generator, providing clear conditions for successful invocation.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the behavioral detail that the handle is released for reuse, which is not deducible from annotations. However, it does not mention other consequences like deletion of team data or member dissociation.

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. Every word serves a purpose: stating the action, identifier methods, and side effect. No redundant or vague phrasing.

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 complexity (destructive action, one parameter, output schema exists), the description covers the core purpose and side effect but lacks details on member handling, reversibility, or required permissions beyond ownership. The output schema may compensate, but the description could be more thorough for a deletion 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?

The schema provides 100% coverage for the single parameter, describing it as 'UUID or handle'. The description adds the crucial semantic that the team must be owned by the user, which is not in the schema. This helps the agent select the correct identifier.

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 ('Delete a team you own') and the resource ('team'). It specifies that deletion can be done by UUID or handle, and notes the side effect of releasing the handle. This differentiates it from sibling tools like 'remove_team_member' or 'transfer_team_ownership'.

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 indicates that the team must be owned by the user, providing a prerequisite. However, it does not explicitly state when not to use the tool (e.g., if the goal is to transfer ownership instead) or mention alternatives among siblings. Additional context about team member impact would enhance guidance.

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

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

Annotations set destructiveHint=true, but the description adds extensive behavioral details: irreversibility, data removal scope (template, versions, files, records), backup retention window, serving gate conditions, and fork pointer behavior. No contradiction with annotations.

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

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

The description is structured into clear sections (permanence, serving gate, fork severing, ownership) and every sentence provides value. Slightly verbose but maintains clarity; could be tightened in a few spots 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?

Given the complexity of a destructive action with multiple conditions and side effects, the description is thorough. It covers prerequisites, restrictions, and consequences (fork pointer nullification, backup retention). Output schema exists, so return values don't need explanation. Complete for the 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?

Only one parameter template_id with 100% schema coverage. The schema already describes it as UUID or @handle/slug. The tool description adds context like 'Owner only' but no new parameter-specific semantics 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?

The description clearly states the tool permanently erases a template, with specific verb 'delete' and resource 'template'. It distinguishes from the sibling 'archive_template' by noting the reversible alternative, making 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?

Explicitly explains when to use (permanent deletion) and when not to (prefer archive_template for reversibility). Also provides conditions like serving gate (must unpublish or archive) and fork severing effects, offering complete usage guidance.

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

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

Despite annotations already indicating destructiveHint=true, the description adds rich behavioral context: details on what exactly is removed (version row, files, verification records, unreferenced content), the irreversibility, the three-month backup retention window, and the monotic version numbering with gaps. No contradiction with annotations.

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

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

The description is somewhat long but well-structured with logical paragraphs. Every sentence adds value. Front-loaded with the core action. Could be slightly more concise but remains clear and informative.

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

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

Given the tool's destructive and irreversible nature, the description is thorough: covers permanence, what is removed, prerequisites, alternatives, version numbering, and security (owner only). Output schema exists but not shown, so return values are not described, but that's acceptable. Complete for a complex tool.

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

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

Schema coverage is 100% (both parameters fully described in schema). The description adds no new information about parameters beyond what the schema already 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?

The description clearly states it permanently erases a single template version. It uses specific verbs ('erase', 'permanently delete') and identifies the resource. It distinguishes from siblings like 'archive_template' (reversible) and 'delete_template' (whole template), and mentions the prerequisite 'unpublish_template_version'.

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 states when to use: when permanent removal is desired. Provides alternatives: 'archive_template' for reversible removal, 'delete_template' for entire template. Also specifies prerequisite: version must be unpublished first via 'unpublish_template_version'.

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?

Disclosures beyond annotations: lists exactly what gets permanently deleted (verifier, versions, run records, access grants), states no recovery path, mentions backup retention window, and notes no confirmation token needed. Does not contradict annotations.

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

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

Well-structured with front-loaded action statement, then detailed bullet points. Every sentence adds value without redundancy. Efficient use of text.

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

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

Given the destructive nature, the description covers all critical aspects: what is deleted, recovery, retention, constraints (serving gate), scope, and return value. No gaps remain for a safe and informed 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 already describes verifier_id as UUID or name. Description adds context: only works for user-scoped verifiers, and reaffirms the return value includes deleted: true. Schema coverage is 100%, so baseline is 3; the additional context raises it to 4.

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's purpose: 'Permanently and immediately erase a verifier you own'. It distinguishes from sibling tools like revoke_verifier and get_verifier, and specifies scope constraints.

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 explicit when-to-use and when-not-to-use guidance: mentions revoke_verifier as alternative for deactivation without erasure, details serving gate conflict with published templates, and clarifies platform-managed/other's verifiers return NotFound.

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

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

Annotations already indicate destructiveHint=true. The description adds significant value by detailing the permanent nature, removal of versions/files/grants, lack of recovery path, and backup retention window (up to three months but inaccessible). This goes well beyond the annotation.

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 concise, well-structured with clear paragraphs, and every sentence adds value. It is front-loaded with the core action and permanence, then expands on details.

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 complex effects, the description covers permanence, what is removed, recovery, ownership, and backup window. An output schema exists, so return values are not needed. The description is fully 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?

With 100% schema coverage for the single parameter, the baseline is 3. The description adds the owner restriction (workflow you own) which is not in the schema, but this is a minor addition. No further parameter details are 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 uses the specific verb 'erase' and identifies the resource as 'a workflow you own'. It explicitly distinguishes from the sibling tool 'archive_workflow' by noting it is permanent and irreversible.

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 states when to use (for permanent deletion) and when not to (recommends 'archive_workflow' as a reversible alternative). It also specifies 'Owner only' and applicability to both live and archived workflows.

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

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

Goes far beyond annotations: details permanence, what gets deleted (version row, files, unreferenced content), no recovery path, backup retention period, current version restriction, and version number gaps. No contradiction with destructiveHint: true.

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?

Concise yet comprehensive. Every sentence adds value, front-loaded with core action, then covers consequences, alternatives, and constraints. 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?

Fully covers all relevant context for a destructive irreversible operation: permanence, scope of deletion, backup timeline, what cannot be deleted, ownership requirement. Output schema exists but description doesn't need return details.

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 already has 100% coverage with clear descriptions for both parameters. Description adds minimal extra meaning (e.g., 'non-current' for version, 'UUID, slug, or name' for workflow_id) but not necessary.

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: 'permanently and immediately erase a single non-current workflow version.' Distinguishes from sibling tools like archive_workflow and delete_workflow by naming them 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?

Provides explicit when-to-use and when-not-to-use: 'use archive_workflow if you want a reversible alternative,' 'Use delete_workflow to permanently remove the entire workflow.' Also notes 'Owner only'.

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

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

Annotations provide no behavioral details, but description extensively covers write behavior, validation, conflict handling, and return format. No contradiction with annotations; adds full transparency beyond hints.

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

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

Well-structured with front-loaded purpose, then versioning, validation, return. Some redundancy (e.g., token requirement repeated), but each section adds necessary detail. Could be slightly more concise.

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 creation vs update, conflict conditions, validation against pricing, token usage, and return fields (as listed). No output schema in structured data, but description provides complete return structure. No gaps for a deploy 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?

Only one parameter (payload) with 100% schema coverage; schema already describes each field thoroughly. Description reinforces the meaning of expected_version_token and generation_contract but does not add independent value 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?

Description starts with 'Create or append a version on a user-owned image generator,' clearly stating the verb (create/append) and resource (image generator). It also distinguishes from system generators and mentions scope, making the purpose specific and 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?

Explanation of when to use (create new or re-deploy) and when not (matching system generator). Provides versioning logic and token requirements. Lacks explicit alternatives like 'use list_image_generators to fetch tokens' but overall context 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?

Annotations are all false, so the description bears full burden. It fully discloses behavior: creates/appends, versioning, concurrency token, input contracts, few-shot examples, return format, and persistence. No contradictions with annotations.

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

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

The description is well-structured with clear sections, bullet points, and code formatting. It is concise yet comprehensive, front-loading the main action. Every sentence adds value without 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 complexity (versioning, contracts, concurrency), the description covers all necessary aspects: what the tool does, how versioning works, input contracts, few-shot examples, concurrency token, and return values. Output schema exists and is referenced. The description is complete for an agent to correctly invoke the 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%, reducing the need for additional parameter info. However, the description adds context beyond schema, such as typical few-shot counts and how input contracts affect examples. It also explains the overall workflow, integrating parameters into the usage flow.

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 action: 'Create or append a version on a user-owned semantic verifier.' It explains what a semantic verifier is, distinguishes from system verifiers, and covers versioning behavior. The purpose is specific and unambiguous.

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

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

The description explains when to use (create new or append version) and provides constraints (e.g., cannot deploy if name matches system verifier). It details versioning logic and the role of expected_version_token. It references run_verifier for execution, but does not explicitly state when not to use or compare with siblings. Context is clear, but explicit exclusion could improve.

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?

Describes idempotency ('last-write-wins'), non-destructive nature ('soft signal, version stays fetchable'), and deprecation timing ('deprecated_at anchors on first call'). Fully aligns with annotations.

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

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

Four concise sentences, each adding essential information. No fluff. Front-loaded with main action.

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?

Explains return behavior (version stays fetchable), effect on other tools (fork_template, lookup_fork_lineage), and idempotent handling. Complete for a mutation tool with 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 has 100% coverage. Description adds value by noting 'message is last-write-wins', which is beyond schema. Minor extra context.

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 'Mark one template version as deprecated' with specific resources. Distinct from siblings like delete_template_version.

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 mentions 'Owner only' and describes soft-signal behavior versus alternatives. Lacks explicit when-not-to-use but context 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?

Annotations declare readOnlyHint=true, which is consistent with returning a prompt pack. The description adds behavioral context by instructing the agent to follow the pack locally and then call save_workflow(), which is beyond what annotations provide. No contradictions.

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: first states what the tool returns, second gives actionable guidance. No wasted words, front-loaded 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?

Despite the tool being simple (no parameters), the description does not elaborate on the output schema or what the prompt pack contains. While the tool is part of a broader system, some additional context about the output 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, and schema coverage is 100%. The description does not need to add parameter info, and it meets the baseline for this case.

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

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

The description states it returns a 'goodeye-workflow-designer prompt pack', which is a specific resource. The verb 'Return' is clear. However, 'prompt pack' is somewhat vague and could be more explicit about its content, but it distinguishes from sibling tools like save_workflow.

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 tells the agent to follow the prompt pack locally and then call save_workflow() to persist. This provides clear context for when to use this tool and the follow-up action, though it does not mention 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?

Discloses authentication requirement, return value (id and lineage metadata), and behavior for anonymous callers (AuthRequired). Annotations are minimal (all false), so description adds valuable behavioral context beyond annotations.

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

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

Two sentences, no fluff, front-loaded with purpose. Every word adds value.

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

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

Given presence of output schema, description adequately covers authentication, result, and visibility (public template). No major gaps identified.

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 description does not need to detail parameters. Baseline 3 is appropriate; no additional parameter meaning is added beyond what schema already 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?

Description uses specific verb 'fork' and clearly identifies the resource (public template) and target (private workflow owned by caller). Distinguishes from sibling operations like 'get_template' or 'create_workflow'.

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

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

States when to use: forking a public template into a private workflow. Lacks explicit when-not-to-use or alternative suggestions, but the context is clear given sibling names.

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?

Beyond the annotations (which only indicate it's not read-only and not destructive), the description reveals billing, authentication, return fields, prompt privacy (only hash stored), resolution order, and mutual exclusivity. This is rich behavioral context.

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

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

The description is fairly long but well-structured with clear sections (resolution order, billing, returns). The first sentence provides the core purpose. While succinct, it covers necessary details without 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 complexity (multiple parameters, nested object, output schema exists), the description covers all essential aspects: purpose, authentication, billing, parameter relationships, output fields, and privacy. It is fully complete 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?

The input schema has 100% description coverage, so the baseline is 3. The description restates some parameter context but does not add new parameter semantics beyond what the schema already provides. The resolution order and mutual exclusivity are explained in both places.

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

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

The description opens with 'Generate one or more images from a text prompt, billed to the caller's credits.' This clearly states the action (generate), the resource (images), and a key characteristic (billing). It distinguishes this from sibling tools like delete_image, get_image, or update_image.

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 detailed guidance on when to use `generator` vs `model`, resolution order, and mutual exclusivity. It also mentions authentication requirements. However, it does not explicitly contrast with other image tools (e.g., when to use this vs upload_image or list_images), though the purpose 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?

Adds return content ('full image record including serving URL') and error behavior with existence masking, going beyond readOnlyHint annotation.

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 concise sentences: purpose, return value, error handling. No redundancy, 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?

With output schema existing, description sufficiently covers purpose, ownership, return content, and error behavior. Complete for a simple get 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?

Only one parameter with 100% schema coverage. Description adds no additional semantic detail beyond what 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?

Clearly states 'Fetch a hosted image by id' with specific verb and resource. Ownership requirement distinguishes it from tools like list_images, update_image, delete_image.

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 ownership constraint guides usage, but no mention of when not to use or alternatives like list_images or get_image_generator.

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 that the tool returns the full deploy-time payload and config_hash for drift detection, and that it requires ownership. Annotations already indicate readOnlyHint: true, so description adds context about error cases and return data.

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

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

Well-structured with two paragraphs; first sentence states purpose, then details. Could be slightly shortened but no unnecessary content.

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 ownership requirements, error cases, version behavior, and return payload content. Output schema exists, so explanation of return values is sufficient. No gaps for this tool's 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; description adds context that generator_id accepts a UUID string and that version defaults to current version. This adds meaning beyond schema field descriptions.

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 states 'Fetch one user-owned image generator' with a specific verb and resource. It distinguishes from siblings like list_image_generators or deploy_image_generator by noting that system generators are excluded and that this is a get 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 mentions that system generators are not returned, requires ownership, and cross-user/revoked generators return NotFound. Provides guidance on version pinning but could be more explicit about when to use this versus list_image_generators.

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

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

Annotations already provide readOnlyHint: true, indicating a safe read operation. The description adds no additional behavioral context beyond what annotations 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?

The description is a single sentence with no wasted words, efficiently communicating the tool's purpose and included 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 read-only resource with no parameters and an output schema, the description fully captures the tool's behavior and output. Completeness is high.

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 description does not need to explain parameter semantics. Baseline of 4 is appropriate for zero 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 clearly states the verb 'Return' and the resource 'referral program status', specifying two key outputs (shareable code and credits earned). It implicitly distinguishes from sibling 'redeem_referral_code'.

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 when-to-use or when-not-to-use guidance. Usage is implied by the tool's purpose, but it does not address alternatives among 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?

Beyond annotations (readOnlyHint=true), description discloses that the returned body is a workflow the agent should execute as a runbook, and mentions the safety banner for non-owners. No contradiction.

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

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

Four concise sentences, each adding essential info: fetch action, execution directive, safety note, default version. No redundant text.

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

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

With output schema present, description covers identification, versioning, safety, and agent action. Complete for the tool's complexity level.

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%, but description adds value by clarifying identifier formats (UUID, @handle/slug, @handle/slug@vN) and version pinning behavior (default latest).

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 fetches a public template by UUID, @handle/slug, or @handle/slug@vN. This distinguishes it from sibling tools like list_templates or get_template_file.

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?

Indicates 'Anyone can read' and notes default version behavior, providing context on when to use. However, it doesn't explicitly contrast with alternatives like search_templates or list_templates.

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

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

Annotations already declare readOnlyHint=true, but description adds valuable behavioral details: handling of text vs binary files, size limits (metadata+error), identifier formats, and safety banner for non-owners. No contradiction with annotations.

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

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

Description is front-loaded with the main action and follows with necessary details. Six sentences each add information, but could be slightly more terse. Overall well-structured.

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 output schema exists (context signals), description covers file behavior (text, binary, over-limit), identifier options, and access restrictions. Complete for the tool's complexity with 3 parameters.

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

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

Schema coverage is 100%, baseline 3. Description adds meaning beyond schema: explains identifier formats (UUID, @handle/slug, @vN), that path must match manifest, and version parameter's purpose. Adds significant value.

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 'Fetch a single file from a template version's file tree by path', using specific verb and resource. It distinguishes from sibling tools like get_template (which returns the template manifest) and get_workflow_file (different 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?

Explicitly tells the agent to use get_template to see the manifest for path validation, and notes restrictions for non-owners and anonymous callers, providing clear context for when to use this tool vs 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?

The description specifies that the summary is for the 'current monthly' period, adding context beyond the readOnlyHint annotation. It does not contradict annotations and provides useful scope information. However, it could mention if the data is live or cached.

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, clear sentence. It is concise with no unnecessary words, achieving maximum efficiency.

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

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

Given the tool's simplicity (no parameters, read-only, output schema exists), the description is complete. It fully describes what the tool returns and the time scope. No additional context seems necessary.

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 description does not need to add parameter details. The schema coverage is 100% trivially. The description correctly implies no user input is needed, which is sufficient.

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 returns the current monthly credit usage summary. The verb 'Return' and specific resource 'monthly credit usage summary' make the purpose immediately clear, and it is distinct from sibling tools like get_image or get_workflow.

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

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

No guidance is provided on when to use this tool versus alternatives. For instance, there is no mention of checking credit limits or comparing with other billing-related tools. The description only states what it does, leaving the agent to infer usage 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?

Beyond the readOnlyHint annotation, the description details that system verifiers are never returned (NotFound), returns the full deploy-time payload with config_hash, and requires owner or tune access. It also describes error behavior for unauthorized or revoked verifiers.

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 well-structured and concise, with no redundant sentences. It front-loads the core purpose, then breaks down identifier usage, default behavior, returned payload, and access requirements. Every sentence adds value.

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

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

Given the presence of an output schema, the description still covers the key return fields, access requirements, error cases, and scope limitations. It is comprehensive for a complex tool with multiple behaviors.

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

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

With 100% schema coverage, the baseline is 3. The description adds valuable context: verifier_id can be a name only with owner/tune access, version defaults to current, and it explains the returned fields. This enhances understanding beyond the schema descriptions.

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 fetches one accessible verifier version and explicitly scopes to user-only. It distinguishes from sibling tools like list_verifiers by specifying it retrieves a single verifier by ID or name, and clarifies that system verifiers are never returned.

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 explains when to use the tool (to fetch a verifier version), what identifiers are accepted (UUID or accessible name), and required access (owner or tune). It also notes that system verifiers are run-only and not returned, guiding against inappropriate use.

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

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

Annotations already indicate read-only. Description adds that workflows are private with masked not-found cross-user reads, and owners can fetch archived workflows, providing useful behavioral context beyond annotations.

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

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

The description is concise with front-loaded purpose. It includes an actionable instruction but is efficient overall, with no wasted sentences.

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 presence of an output schema, the description adequately covers return content (body and facets), privacy, versioning, and archiving, making it complete for a read tool with good annotations.

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 both parameters with clear descriptions. Description's 'Latest version by default' and 'by UUID or slug' are redundant or slightly less complete than the schema, adding no significant new meaning.

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

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

The description clearly states it fetches the workflow's markdown body plus discovery facets. The verb 'Fetch' and specific resource distinguish it from siblings like get_workflow_file or list_workflows.

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 instructs to execute, not just display, implying usage for runbook execution. It mentions privacy and archiving but lacks explicit when-to-use or alternative comparisons.

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

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

Annotations declare readOnlyHint=true, and the description adds behavioral details beyond that: how text files return decoded strings, small binaries return base64, large binaries return metadata and error, and that SKILL.md returns the workflow body. No contradiction with annotations.

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

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

The description is a well-structured single paragraph of 6 sentences, starting with the main purpose then detail. It is efficient but could be slightly more concise.

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 all key behaviors: path matching, version handling, file type handling, size limits, permission requirement. With an output schema present, return values are documented elsewhere, so the description is 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 baseline is 3. The description adds minimal extra parameter context beyond the schema (e.g., SKILL.md returns workflow body), but does not substantially enhance parameter understanding.

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 'Fetch a single file from a workflow version's file tree by path.' The verb 'Fetch' and resource 'single file' are specific, and it distinguishes itself from sibling tools like get_workflow_files (plural) and get_workflow.

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 context on when to use get_workflow to see the manifest, explains behavior for different file types (text, small binary, large binary), and notes the permission requirement. However, it does not explicitly state when not to use this tool or list 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?

Beyond the readOnlyHint annotation, the description details important behaviors: unknown paths return 'not_found' envelopes instead of failing, aggregate inline budget can cause 'batch_response_cap_exceeded' errors, paths are returned in lexicographic order, each path appears exactly once, and the response structure is given. There is no contradiction with annotations.

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

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

The description is moderately detailed but each sentence serves a purpose. It is well-structured with clear paragraphs covering different aspects (path matching, ordering, error handling, budget). No 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?

Given the complexity of a batch file fetch tool with error handling, budget limits, and ordering, the description covers all key aspects. The presence of an output schema relieves the need to describe return values, but edge cases are thoroughly documented. The description is complete 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?

Schema coverage is 100%, so baseline is 3. The description goes beyond schema by explaining that 'paths' must exactly match manifest rows, ordering is lexicographic, unknown paths return error envelopes, and the budget exhaustion behavior. For 'version', it clarifies pinning vs latest. 'workflow_id' as UUID/slug/name is mentioned. These details add significant value.

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 'Fetch multiple files from a workflow version's file tree in a single call', using a specific verb and resource. It implicitly distinguishes from 'get_workflow_file' (single file) and 'get_workflow' (manifest retrieval through reference).

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 instructs to use exact paths from the manifest obtained via 'get_workflow', and notes that unknown paths return error envelopes, providing clear context. However, it does not explicitly list alternative tools for when this tool should not be used, though the purpose (batch fetch vs single file) 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?

The description goes beyond annotations by explaining version history behavior: default grants access to current version and later, but not older versions unless include_history is set. Annotations only show non-read/write/destructive hints, so description adds valuable context.

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

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

Two sentences, no fluff. First sentence states the purpose immediately, second sentence explains an important behavioral nuance. Highly 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?

The description covers the main purpose and key behavioral details. Since there is an output schema, return values are not needed. Missing permissions or error handling but still complete enough for a grant 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?

All four parameters are described in the input schema (100% coverage). The description adds extra meaning by mentioning identification methods (UUID, email, handle) and explaining the effect of include_history, which enhances understanding 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 uses the specific verb 'Grant' and resource 'workflow access', clearly stating the action. It distinguishes the tool from siblings like revoke_workflow_grant by focusing on granting access.

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 explains when to use this tool (to grant access) and provides context about default version history behavior. It implicitly contrasts with revoke_workflow_grant but does not explicitly list alternatives or when-not.

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

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

Annotations already specify idempotentHint=true and destructiveHint=false; description adds 'your direct grant' context but doesn't disclose additional behaviors beyond annotations.

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

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

Single sentence, no wasted words, front-loaded with action and resource.

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 operation with one parameter and output schema; description is sufficient but could mention it only affects the caller's own grant.

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% (workflow_id fully described); description adds no extra parameter semantics 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?

Description uses specific verb 'remove' and resource 'your direct grant on a shared workflow,' clearly distinguishing from siblings like grant_workflow or revoke_workflow_grant.

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 when-to-use or when-not-to-use guidance; usage is implied by the verb 'remove' and context of shared workflows.

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?

Beyond the readOnlyHint annotation, the description adds critical security context: 'Never returns hashes or plaintext.' This discloses important behavioral traits about what the tool does not expose, which is valuable for an API key listing 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 three sentences long, front-loaded with the purpose, then describes the return format, and finally gives pagination instructions. Every sentence is essential, and there is no waste.

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

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

Given the tool has two well-documented parameters, an output schema, and is read-only, the description covers all necessary aspects: what it does, how to paginate, and what it does not return. It is complete for a simple listing 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?

The input schema already provides 100% coverage with descriptions for 'limit' and 'cursor'. The tool description does not add additional semantic meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'List', the resource 'your live (non-revoked) API keys', and distinguishes from siblings like mint_api_key or revoke_api_key. It is specific and unambiguous.

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

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

The description explains pagination behavior (page until next_cursor is null) and the return format. While it doesn't explicitly state when not to use it, the context of sibling tools makes it clear this is for viewing existing keys, not for creating or revoking.

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

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

Annotations declare read-only behavior. The description adds detail: lists only non-revoked generators, excludes platform-managed ones, and describes pagination behavior mirroring list_verifiers, all beyond the annotations.

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

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

Three sentences covering purpose, exclusions, pagination, and return format. Front-loaded with main purpose, no unnecessary 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 list tool with simple pagination, the description fully covers what the tool does, what it returns (including field list), and its limitations (exclusions). No gaps given the output schema is provided inline.

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% with clear parameter descriptions. The description adds value by referencing list_verifiers pagination behavior, providing extra context for cursor usage.

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 the resource 'active (non-revoked) image generators owned by the caller'. It specifies exclusions (platform-managed) and scope, making it distinct from sibling list 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?

Provides clear context that only user-owned generators are listed and platform-managed ones are excluded, informing when not to use this tool. However, no explicit alternatives are named for other use 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?

The description goes beyond the readOnlyHint annotation by detailing pagination behavior and return format ('Returns {items: [...], next_cursor: str | null}'). This provides critical behavioral context that helps an agent understand how to iterate results, with no contradictions to annotations.

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

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

The description is concise at approximately 6 lines, front-loaded with the main purpose, and uses well-structured bullet points for filters and pagination. Every sentence adds value without redundancy, making it easy 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?

Given the presence of an output schema and the description's coverage of filters, pagination, and return format, the description is fully complete for this tool. It addresses all necessary aspects without relying solely on structured fields.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by elaborating on the source filter (e.g., explicitly mentioning 'generated' images) and explaining pagination cursor usage, which is not fully captured in the schema descriptions. This enhancement justifies a 4.

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 'List hosted images owned by the caller, with optional filters,' specifying a verb (list) and resource (hosted images). This distinguishes it from sibling tools like get_image (single image) and delete_image, making the purpose immediately clear.

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 use for retrieving multiple images with optional filters but does not explicitly contrast with alternatives like get_image for individual images or upload_image. The usage context is clear but lacks explicit when-not or sibling differentiation.

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

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

Annotations already indicate readOnlyHint=true, so the description's disclosure of pagination behavior and return format adds value beyond what annotations provide. No contradictory information.

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 concise and well-structured, using code blocks for examples and front-loading the core purpose. Every sentence adds value.

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

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

For a listing tool with 4 optional parameters and an output schema, the description covers return format, pagination, and parameter behavior. No gaps detected.

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 baseline is 3. The description adds meaning by explaining what each filter value does and default values, going beyond enum strings.

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 invitations visible to the caller, with specific details on filter and state parameters. It distinguishes itself from sibling tools like accept_invitation and cancel_invitation 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 explains the three filter options and two state options, and mentions cursor-based pagination. It does not explicitly state when to not use this tool, but the context is clear enough for correct invocation.

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

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

Annotations declare readOnlyHint=true, confirming safe read behavior. The description adds value beyond annotations by disclosing that the owner appears via a synthetic row, which is a non-obvious behavioral trait. No contradictions detected.

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 consists of two short, clear sentences. It is front-loaded with the core purpose and includes an important behavioral note 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 the simple tool (one parameter, read-only, with output schema), the description is complete. It covers the action, identification method, and a notable result behavior. The presence of an output schema means return values need not be detailed.

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 100% for the single parameter team_identifier. The description mentions 'by UUID or handle', which mirrors the schema's own description. No new meaning is added 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?

The description clearly states the verb 'List', the resource 'members of a team', and the identification method 'by UUID or handle'. It also adds a specific detail about the owner appearing via a synthetic row. Among siblings like add_team_member and list_teams, this tool's function is distinct.

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 explicit guidance on when to use this tool versus alternatives, such as listing teams or adding members. It lacks context about prerequisites or conditions that might warrant using this tool over others. While the purpose is clear, usage scenarios are left 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?

The description adds context beyond annotations (owned + member of) and aligns with readOnlyHint=true. It adequately discloses behavior for a read-only list 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?

One sentence, front-loaded with key information, no unnecessary 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 the tool's simplicity (one optional param, no required params, output schema exists), the description is complete and sufficient.

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 has 100% coverage for the single parameter. The description does not add additional semantics beyond the schema's enum values and default.

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), resource (teams), and scope (visible to caller, owned + member). It distinguishes from siblings like list_team_members and create_team.

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 (to see your teams) and provides context but does not explicitly state when not to use or mention alternatives.

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

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

Annotations already indicate read-only and non-open world. Description adds important nuance: archived templates are excluded unless include_archived is set, and even then only the caller's own. No contradictions.

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 main purpose, no fluff. Efficient and to the point.

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 core behavior (public, filtering, archived handling) and output schema exists. Lacks explicit mention of pagination behavior (e.g., cursor usage), but parameters imply it.

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

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

Schema already describes all parameters thoroughly (100% coverage). Description clarifies the effect of filter and include_archived in context, adding marginal 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?

Description clearly states 'List public templates' and explains the filter and archived behavior. Distinguishes from siblings like search_templates and get_template by focusing on listing with optional filters.

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 explicit context on who can read (anyone) and how filters work (filter='mine', include_archived). However, it does not explicitly contrast with sibling tools like search_templates, leaving some ambiguity.

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 discloses key behaviors: only active verifiers, includes owned and workflow-derived grants, excludes system verifiers, anonymous callers get empty list, and pagination via next_cursor. Annotations only provide readOnlyHint, so description adds significant context.

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

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

Description is concise: one sentence for purpose, a code block for return format, and brief additional details. No redundant information, and each sentence serves a purpose. Front-loaded with core functionality.

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 (2 optional params, paginated list), the description covers all essential aspects: what is returned, excluded items, caller visibility, and references a sibling for more detail. Output schema is included. No gaps noted.

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 schema has 100% coverage with descriptions for both parameters (limit, cursor). Description does not add new parameter-level meaning but implicitly relates to pagination via next_cursor reference. Baseline score 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?

Description clearly states 'List active (non-revoked) verifiers visible to the caller', specifying the verb, resource, and condition. It distinguishes from sibling 'get_verifier' by noting when to use that instead.

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?

Description explicitly guides to use 'get_verifier' for deploy-time config when role is owner or tune, providing an alternative. It also mentions anonymous callers get empty list, implying when not to use. Could add more context about other siblings, but sufficient.

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 beyond annotations by specifying 'direct user and team grants' and authorization requirement. However, it doesn't clarify if grants are only explicit or include inherited ones.

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

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

Extremely concise with two sentences, front-loaded with action, no unnecessary 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 output schema exists, description does not need to explain return values. However, it could briefly mention that it lists only direct grants, but 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 already describes workflow_id fully. Description does not add new parameter info, but baseline 3 is appropriate as schema handles it.

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 uses specific verb 'List' and resource 'grants on a workflow', clearly distinguishing from siblings like grant_workflow or revoke_workflow_grant. The authorization note also clarifies scope.

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?

Mentions 'Admin or owner only' which provides some context on who can use it, but lacks guidance on when to use this tool over alternatives (e.g., after granting, before revocation) 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?

Annotations declare read-only and non-open-world. The description adds key behaviors: pagination via next_cursor, response structure, and archived workflow exclusion/inclusion. These go beyond annotations, though some behavioral aspects (e.g., filtering) are implicit in 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?

The description is four sentences, front-loading purpose and pagination. Every sentence adds necessary information: what it does, output shape, pagination rule, and archived behavior. 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?

Given the tool has 6 optional parameters, pagination, and archived filtering, the description covers all essential aspects: what is listed, how to paginate, and the role of include_archived. Output schema is also described inline, making it self-contained.

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. The description adds value by explaining the effect of 'include_archived' (includes only your own archived) and emphasizes pagination cursor usage, which clarifies parameter usage beyond schema descriptions.

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 'workflows', clearly scoping to 'you own or that are shared with you'. It distinguishes from sibling tools like 'search_workflows' and 'get_workflow' by focusing on listing with pagination and archived filtering.

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 workflows, but does not explicitly state when not to use it or how it compares to alternatives like 'search_workflows' or 'get_workflow'. Provides pagination and archived behavior but no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds the return tuple, which provides some behavioral insight beyond annotations. However, it omits details on error conditions, visibility constraints (what 'you can see' entails), or whether the tool fails gracefully for non-forked workflows.

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, well-structured sentence that immediately states the return values and the resource it operates on. Every word is necessary; there is no redundancy or fluff. It is optimally concise.

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 (one parameter, output schema exists), the description is largely complete. It identifies the return fields (though output schema likely handles definitions) and the target object. Minor gap: it could explain the meaning of the returned fields, but this is mitigated by the presence 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any extra meaning to the workflow_id parameter beyond what is already in the schema. No parameter-specific elaboration is provided.

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 verb 'lookup' and the resource 'fork lineage', and lists the exact return fields: parent_template_id, parent_template_version, upstream_latest_version, is_upstream_unpublished. It distinguishes itself from siblings by focusing on lineage of forked workflows, a unique concern not covered by other tools like get_template or fork_template.

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 alternatives. It does not state prerequisites, when not to use, or contrast with sibling tools like check_template_safety or get_workflow. The context of 'forked workflow you can see' implies limited applicability, but this is insufficient.

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?

Despite having annotations that are all false (no hints), the description explicitly warns that the secret is returned only once, a critical behavioral trait beyond what annotations 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?

The description is extremely concise with a single sentence that front-loads the key action and includes a critical note about the one-time return, making it efficient and to the point.

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 creation tool with an output schema, the description is minimal. It covers the essential behavioral note but lacks broader context such as security implications, prerequisites, or how it fits into the overall key lifecycle.

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 the 'name' parameter fully (100% coverage), and the description adds no extra meaning beyond what the schema provides, meeting the baseline of 3.

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

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

The description clearly states the action ('Mint') and resource ('good_live_ API key'), and distinguishes from siblings like list_api_keys and revoke_api_key by its unique creation 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?

The description implies the tool is used to create a new API key but does not provide explicit guidance on when to use versus alternatives like revoke_api_key, nor does it mention prerequisites or 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?

The description goes beyond the readOnlyHint annotation by detailing the return pack's contents and the required iterative process. It explicitly states that only the description changes and other fields are preserved, adding valuable behavioral context.

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

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

The description is concise and structured with a clear introductory sentence followed by technical details. It uses backticks for code-like elements and conveys essential information without verbosity.

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

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

Given the tool's complexity (iterative loop, user approval, persistence), the description covers the key points: the returned pack, the required permissions, the scope of changes, and the approval step. The existence of an output schema fills in return value details.

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% with parameter descriptions. The description adds the default behavior for 'max_iterations' (defaults to 10 when omitted), but there is a slight inconsistency with the schema default of null. Overall, the schema already carries the main burden.

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 returns a 'goodeye-description-optimize pack' for an existing workflow, specifying the output structure and the scope of changes (only description). It distinguishes from other optimization tools by focusing solely on description tuning.

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 a clear workflow: the agent runs the loop locally with the user, then persists via save_workflow after explicit user approval. It also mentions the need for edit access, giving practical guidance on when and how to use the tool.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds valuable behavioral context: it returns a pack that the agent uses to run an optimization loop, drives subagents, and persists only after explicit user approval via 'save_workflow'. This clarifies that the tool itself is read-only but initiates a multi-step process.

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 three sentences and front-loads the core purpose. It is efficient, though the middle sentence is long and could be split for readability. Each sentence adds value without 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 complexity (optimization loop, subagents, persistence), the description covers the return pack structure, process flow, and requirements. The presence of an output schema reduces the need to describe return values. It is mostly complete, though it omits definitions of 'skill_md' and 'references' which likely are in the 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 coverage is 100% (both parameters described in schema). The description does not add new meaning beyond the schema; it mentions 'max_iterations' but only in the context of the pack output, not as additional parameter guidance. 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?

The description clearly states it returns a 'gooeye-workflow-optimize pack' for optimizing an existing workflow, specifying the verb (return) and resource (pack). It distinguishes from sibling tools like 'optimize_description' and 'save_workflow' by mentioning the pack's role in driving subagents and requiring user approval.

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 explains when to use the tool: to initiate optimization of a workflow. It mentions the requirement of edit access and the process of local loop with user approval. However, it does not explicitly state when not to use it or suggest alternative tools (e.g., 'teach_workflow' for different optimization strategies).

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 all annotations false, the description discloses key behaviors: it creates a public version, appends monotonic versions, and requires a claimed handle. It does not detail side effects like making the template publicly visible, which could be considered a 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?

The description is concise (4 sentences) and front-loaded with the main action. Each sentence adds necessary context without 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 output schema exists, the description adequately covers the tool's purpose, prerequisites, and demo bundling. It is missing some context like the requirement that the workflow must be saved, but overall sufficient.

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% for both parameters. The description adds no new semantic information beyond what the schema provides for workflow_id and release_notes.

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 'publish' and the resource 'workflow as a new public template version'. It differentiates from siblings like delete_template_version and unpublish_template_version by explaining the versioning behavior.

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

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

The description mentions a prerequisite ('Requires a claimed handle') and provides context about first-time vs. subsequent publishes. However, it does not explicitly say when to use this tool vs. alternatives like deprecate_template_version.

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

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

Annotations indicate mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds 'one-time' constraint, which is a key behavioral trait beyond annotations. However, it does not detail error handling 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?

Single sentence, no wasted words, front-loads the action and outcome. Perfectly concise for the tool's simplicity.

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 low complexity (1 parameter, output schema exists), the description covers the main behavioral constraint ('one-time') and purpose. Minor lack of explicit prerequisites or error cases, but adequate for a simple redeem action.

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 schema already describes the parameter 'code' as 'The referral code to redeem for one-time bonus credits.' The description does not add new semantic information beyond reinforcing the purpose, so baseline score 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 clearly states the action ('Redeem'), the resource ('referral code'), and the outcome ('claim your one-time new-user bonus credits'). It distinguishes from sibling 'get_referral_status' which checks status rather than redeeming.

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 for new users with a referral code to claim bonus credits, but does not explicitly state when not to use it (e.g., if already redeemed) or mention the alternative 'get_referral_status' for checking eligibility.

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 only says 'Remove' but does not elaborate on side effects (e.g., impact on shared workflows, permissions, or content). Annotations set destructiveHint to false, which might mislead about the actual effects of removal. No mention of reversibility or required 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?

Single sentence, front-loaded with the verb, no redundancy. Every word contributes to understanding the tool's core function.

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

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

For a simple tool with two parameters and an output schema (not shown), the description provides the essential information. However, it omits behavioral context like idempotency (idempotentHint false) and potential failure modes, which could be important for an AI agent.

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 have clear descriptions matching the tool's description. The description reinforces the accepted identifier formats but adds no new 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 clearly states the action ('Remove'), the resource ('team member'), and the allowed identification methods (UUID, email, or handle). It distinguishes from the sibling tool 'add_team_member' by specifying removal rather than addition.

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

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

No guidance on when to use this tool vs alternatives like 'cancel_invitation' for pending invites or 'leave_shared_workflow'. The description does not mention prerequisites (e.g., ownership/admin status) or scenarios where removal is appropriate.

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