Cutshed

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

No annotations are supplied, so the description carries the burden and does disclose two real behavioral facts: the required OAuth scope studio:generate and the provenance of the id argument. It leaves out whether results can be incomplete/in-progress or whether repeated calls are rate limited, which matters for a status-polling read.

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

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

Three short sentences, zero filler. The core action and scope come first, followed by the auth prerequisite and the argument's source.

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

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

For a one-parameter read with no output schema and no annotations, the description covers what it returns ('status and results'), the auth requirement, and the input's origin. Only polling/status-lifecycle semantics are missing.

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

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

Schema coverage is 100% on the single id parameter, so the baseline is 3, but the description adds meaning beyond the schema's bare 'Generation id.' by specifying that it must be the id returned by start_generation.

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

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

Specific verb (Read) plus resource (one Studio generation's status and results) with the scope of the call stated ('for the token's account'). It is clearly separable from the sibling start_generation, which creates generations rather than reading them.

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

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

It tells the agent where the required argument comes from ('Pass the id returned by start_generation'), which implicitly frames this as the follow-up to start_generation. It never states when not to use it or whether to poll versus fetch once, so it stops short of explicit alternatives/exclusions.

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

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

No annotations are provided, so the description carries the full burden and does disclose the two facts that matter most: this is a read-only operation and it needs an OAuth token with the profile:read scope. It does not describe failure behavior when the token is missing or under-scoped, which would have made it a 5.

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

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

Two short sentences with zero filler: the operation and its returned fields come first, the auth requirement second. Nothing here could be cut without losing information.

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

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

With no output schema, the description steps in to name the returned fields (email, display name) and the auth scope, which is enough for an agent to call it and interpret the result. Only the unauthenticated/error path is left unspecified.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly adds no parameter noise.

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?

'Read' is a specific verb and 'the signed-in person's email and display name' names exactly what is returned, which clearly separates it from siblings like get_my_credits or get_studio_pricing. It stops short of naming an alternative outright, but the resource scope is unambiguous.

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

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

The description supplies a concrete precondition ('Requires an OAuth bearer token with profile:read'), which tells the agent when the call can succeed. However, it never states when to prefer this over the other 'my'-scoped siblings or what to do when identity is already known, so usage routing is only implied.

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

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

No annotations are provided, so the description carries the full load. It does useful work by disclosing the required OAuth scope (credits:read) and implying a read-only operation, but it says nothing about rate limits, whether history is paginated or time-bounded, or what happens when unauthenticated.

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

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

Two compact sentences, front-loading the capability before the auth requirement. Nothing wasted.

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

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

For a zero-parameter read tool with no output schema, the description covers the essential prerequisites and the kind of data returned. A brief note on what the balance/history fields represent would close the remaining gap.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter behavior the description needs to clarify.

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

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

States a specific verb and resource: reads credit balance plus recent credit history. Clear enough to act on, but it does not differentiate from the close sibling get_my_account, which may also surface credit information, so the agent must guess which to call.

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

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

Usage is implied by "credit balance and recent credit history," but there is no explicit when-to-use framing and no mention of alternatives such as get_my_account or get_studio_pricing for pricing questions.

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

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

With no annotations, the description carries the burden and does disclose side-effect-free behavior ('does not start a purchase or a generation'), the live vs. cached nature of the catalog, and the units of the returned values. It omits any auth requirement or rate-limit context, but for a zero-parameter read lookup the disclosed traits cover the operationally important ground.

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

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

Two short sentences, front-loaded with what is returned, followed by the units and the side-effect disclaimer. Every clause earns its place.

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

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

No output schema exists, so the description must characterize the return value, and it does: 'credit packs and model prices' with units ('credits and provider cents'). A brief note on structure or freshness would round it out, but nothing essential is missing for a parameterless lookup.

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

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

The tool takes no parameters (schema coverage 100%), so there is nothing for the description to compensate for; baseline 4 applies. The description does not mention parameters, correctly, since there are none.

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

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

States a specific verb and resource ('Return Studio credit packs and model prices') plus the data source ('live catalog'). It implicitly distinguishes itself from the sibling get_my_credits by clarifying these are catalog prices rather than the user's balance, but it never names that sibling, so an agent must infer the boundary.

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

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

The closing sentence gives an explicit negative boundary — 'This does not start a purchase or a generation' — routing the agent away from start_generation and quote_clipper. It stops short of a positive 'use this when the agent needs pricing before generating', so it is clear context plus one exclusion rather than full when/when-not/alternatives 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses only that a tool is returned; it does not state error behavior (e.g., unknown slug), whether 'free' restricts the result set, or any authentication or rate-limit 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 brief sentences, front-loaded with the action and resource. The example earns its place as a concrete illustration.

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

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

For a one-parameter lookup with no output schema, the description is minimally sufficient: it says what is returned and by which identifiers. It omits error handling and the sibling distinction with list_tools, which an agent might need when discovery is ambiguous.

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 description repeats the same accepted forms (slug, title, path) plus an example already present in the schema. It adds no semantic detail beyond the structured field.

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

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

States a specific verb 'Return' and resource 'one free Cutshed tool', plus the accepted identifiers (slug, title, path). It distinguishes itself from list_tools by returning a single tool, though it never names that sibling explicitly.

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

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

The example slug implies usage when you already know a tool's identifier, but the description gives no explicit when-to-use condition or points to list_tools as the alternative for discovery. Usage is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the returned fields (public URL and one-line description), but it does not mention ordering, pagination, authentication needs, or any other behavioral traits beyond the basic listing behavior.

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

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

The description is two sentences, front-loads the primary action and return contents, and then immediately states the exclusion boundary. Every sentence earns its place with no redundant 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?

For a zero-parameter listing tool with no output schema, the description is nearly complete: it explains what is listed, the fields returned, and what is excluded. A minor gap is the absence of details such as ordering or whether the list is paginated, but no critical invocation information is missing.

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

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

The tool has zero parameters, which is the baseline for a 4 under the rubric. The description does not need to explain parameter semantics because there are none to explain.

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

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

The description states a specific verb and resource: listing Cutshed's free browser tools with their public URL and a one-line description. It also explicitly excludes Studio, checkout, and account actions, which helps distinguish it from siblings such as get_my_account and get_studio_pricing.

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 scopes usage by saying which tool categories are included and excluded. However, it does not explicitly name alternative siblings to use for the excluded categories, so it falls short of a full when/when-not/alternatives statement.

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

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

With no annotations, the description carries the burden and does disclose that this is a public quote, lists return fields, and explains credits as the vision price when vision is true. It still does not explicitly state read-only behavior, auth requirements, side effects, or rate limits.

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

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

The description is front-loaded and short, with the purpose stated first and the field list plus pricing notes earning their place because there is no output schema. It is slightly dense but has no filler.

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

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

Given one optional parameter and no output schema, the description lists the quote fields and explains key semantics like audio-only being free and credits representing vision pricing. It does not define every returned field in detail, but the field names and low-complexity shape make it reasonably complete.

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

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

Schema coverage is 100% for the single optional windows parameter, so the schema already explains that it should be omitted or set to 8. The description reinforces the fixed 8-window nature of the public quote but adds little beyond the schema text.

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

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

It states a specific verb and resource: return the public clipper quote for an 8-window highlight pass, and names the returned fields. The resource is specific enough to separate it from pricing/account siblings, though it does not explicitly contrast with get_studio_pricing or get_my_credits.

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

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

Usage is implied by the tool name and the note that audio-only scoring on the site is free, which hints at when this quote matters. However, it does not explicitly say when to use this versus get_studio_pricing, get_my_credits, or start_generation.

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

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

With no annotations, the description carries the burden and does well: it discloses the read-only scope boundary (public guide only, not account data) and the auth characteristic of the alternatives (OAuth). It also states the return shape ('short matching excerpts'). It does not mention result limits, ranking, or pagination behavior, which are minor gaps for a static-guide search.

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

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

Three short, front-loaded sentences with zero filler. Scope, return shape, and the account-data boundary are each stated once and in priority order.

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 tool with no output schema and no annotations, the description covers the essentials: what is searched, what is returned, and what is out of scope. Only minor details (result count limits, ranking) are absent, and those are unlikely to affect correct invocation.

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

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

Schema description coverage is 100% and the single 'query' parameter is already documented as 'Words to find in the public site guide.' The description adds no syntax, format, or matching semantics beyond the schema, so baseline 3 applies.

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

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

States a specific verb (search) and a specific resource scope (public Cutshed guide / llms.txt and the free-tool list). It explicitly excludes account data, distinguishing it from siblings like get_my_account and get_my_credits without requiring the agent to open any schema.

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

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

Clearly signals the when-not condition ('does not search account data') and points to the alternative ('account tools are separate and need OAuth'). It stops short of an explicit 'use this when you need public docs' framing, so it is slightly less than fully prescriptive, but the routing context is solid.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses OAuth scopes, pricing/balance checks, and per-account limits, but omits whether generation is asynchronous, what is returned, and failure behavior for insufficient credits.

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

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

Two compact sentences with no wasted text. The primary action is front-loaded, followed by prerequisite auth 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 16-parameter generation tool with no annotations, no output schema, and no schema descriptions, the description is far too thin. Auth and billing context helps, but parameter semantics and async/return behavior are missing.

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

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

There are 16 parameters with 0% schema description coverage, and the description adds no parameter meaning at all. It does not even mention the required model parameter or explain any of the various generation options.

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

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

The description states a specific verb and resource: "Start a Studio generation." It is clearly distinguishable from the read-oriented sibling get_generation, though it does not explicitly name alternatives.

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

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

It implies this is the action tool for creating a generation, but gives no explicit when-to-use/when-not-to-use guidance or routing to siblings such as get_studio_pricing or get_my_credits before starting.

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