Fuzzbucket AI

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 15-minute expiry window, that the response carries private request headers, and the security-critical warning that both values are credentials scoped to that one file. It stops short of stating permission requirements or what happens on repeat calls.

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

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

Three tight sentences, front-loaded with what the tool produces and what it returns, with zero filler. The closing sentence is short but carries a real security constraint rather than padding.

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 carries the return-value burden and does it well: it names both the header-bearing URL and the browser-ready downloadUrl. Missing only edge context such as required permissions or behavior when the asset is unavailable, which keeps it from a 5.

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% — both workspaceId and assetId are fully documented in the schema, including the sourcing hint for assetId. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb and resource — 'Prepares a 15-minute private download of one stored asset’s original file' — and immediately distinguishes itself from metadata-oriented siblings like fuzz_get_asset by returning a fetchable URL plus headers. An agent knows exactly what it gets without opening the schema.

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

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

Usage is implied by the purpose ('download one stored asset'), but there is no explicit when/when-not guidance and no reference to alternatives such as fuzz_preview_assets or fuzz_get_asset. An agent can infer the use case but is not told when this is the right choice over a sibling.

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

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

Annotations already declare the safe, read-only, idempotent profile, and the description adds genuinely new behavior: the 15-minute expiry, that the ZIP is private, and that fetching requires private request headers alongside an equivalent browser-openable downloadUrl. It stops short of rate limits or whether repeated exports are cached/regenerated.

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

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

Two sentences, zero waste, with the duration and privacy constraint front-loaded before the return-value details. Nothing is repeated from the title or annotations.

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

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

With no output schema, the description carries the return contract itself (private fetch URL plus headers, and a browser-openable downloadUrl), and annotations cover the safety profile. For a 3-parameter export it leaves no decision-relevant gap.

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

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

Schema description coverage is 100%, so nodeId, workspaceId, and format are already fully documented in the schema, and the description adds no format/ID semantics of its own. Baseline 3 applies when structured fields carry the parameter 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?

States a specific verb and resource ('Prepares a ... ZIP export of one canvas node') and pins the scope to a single node, which implicitly separates it from the plural sibling fuzz_export_nodes. The output shape (URL + downloadUrl) is named, so an agent knows exactly what the call produces.

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?

Scope ('one canvas node') implies when this is the right tool versus the bulk fuzz_export_nodes, and the format note says what happens when it is omitted. However, no sibling is named and there is no explicit when-not guidance, so usage is inferred rather than stated.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is low, yet the description adds non-obvious behavior: a 15-minute expiry window, that the returned URL is 'private' and needs request headers, and that a separate browser-friendly downloadUrl exists. These are traits annotations cannot express.

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

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

Two tight sentences with no filler; the export lifetime and privacy qualifier are front-loaded before the return-value sentence. Every clause carries distinct information.

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

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

There is no output schema, so the description carries the return-value burden and does so explicitly (URL + private headers, plus downloadUrl). Combined with 100% schema coverage and annotation-covered safety, an agent has everything needed to call and consume this 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% and every parameter (workspaceId, nodeIds, format) is documented inline in the schema, including format fallback/error behavior. The description adds no parameter-level detail beyond restating the workspace/node scoping, so the baseline 3 applies.

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

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

The description gives a precise verb ('Prepares'), resource ('canvas nodes'), cardinality ('several') and scope ('from one workspace'), plus the output artifact type (ZIP). The plural cardinality implicitly separates it from the singular sibling fuzz_export_node, so an agent can route without opening either schema.

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

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

It states a usage constraint (all nodes must come from one workspace) but never says when to prefer this over fuzz_export_node or fuzz_download_asset, nor any when-not condition. Usage is only implied by the plural 'several'.

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 annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds a genuine behavioral nuance beyond that: text assets return their text content while non-text assets apparently do not, which tells the agent to expect a conditional payload.

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

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

A single sentence that front-loads what is returned and lists the fields in a compact, scannable run. Every clause carries information; there is no filler.

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

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

With no output schema, the description carries the burden of describing the return value, and it does so reasonably well by enumerating fields and the text-content special case. It is slightly thin on edge behavior (missing asset, truncation of large text), but for a two-parameter read tool with full annotation coverage it is nearly 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%: assetId is documented as coming from content, node outputs, or upload completion, and workspaceId as coming from fuzz_list_workspaces/fuzz_create_workspace. The description adds nothing about the parameters, which is acceptable when the schema already does the work.

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

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

The description gives a specific verb (Returns) plus the resource (a stored asset) and enumerates exactly which fields come back: name, MIME type, size, dimensions, and text content for text assets. It is unambiguous about what the tool does, though it never names or contrasts the obvious siblings fuzz_download_asset and fuzz_preview_assets.

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

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

There is no when-to-use or when-not-to-use guidance. The presence of fuzz_download_asset and fuzz_preview_assets as siblings makes the choice non-obvious, and the description does nothing to route the agent between retrieving metadata versus downloading or previewing the asset.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. With no output schema, the description usefully adds what is returned: the brand's context, onboarding state, and pending onboarding questions. It stops short of describing structure or format, but it meaningfully extends 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?

A single front-loaded sentence that names the resource and the notable return content with zero filler. Nothing is wasted and the key information leads.

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 tool with full annotation coverage, the description is nearly complete, covering what is returned since no output schema exists. It is slightly loose on the exact shape of 'context' and 'onboarding state,' but nothing critical for calling it correctly is missing.

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

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

Schema description coverage is 100% and the schema already documents brandId thoroughly, including its source (fuzz_list_brands / fuzz_create_brand) and the onboarding edge case. The description adds nothing beyond implying a single-brand lookup. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: it returns one brand's context and onboarding state. Using 'one brand's' implicitly contrasts with the list_brands sibling, though it does not name that sibling explicitly. The purpose is clear without opening the schema.

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

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

There is no when-to-use or when-not-to-use guidance. An agent must infer that this retrieves a single brand versus fuzz_list_brands or fuzz_get_brand_quota. The onboarding-question edge case lives in the schema, not the description, so it is not surfaced as usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on auth requirements, plan edge cases (e.g. unlimited tiers), or error conditions — so it earns no extra credit.

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

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

A single sentence that front-loads the returned value and contains no filler. There is no wasted clause.

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 trivial zero-param read tool with no output schema, the description is sufficient: it explains the semantic meaning of the returned number, which compensates for the absent return schema. Only marginal detail (e.g. behavior when quota is exhausted or unlimited) 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 takes no parameters at all, which is the baseline-4 case; there is nothing for the description to clarify beyond the schema. The schema is an empty object with additionalProperties false, so description and schema are consistent.

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

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

The description states a specific verb and resource: it returns the remaining brand-creation allowance for the user's plan. That is clearly distinct from siblings like fuzz_get_brand and fuzz_list_brands, though it never names or contrasts 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?

Usage is only implied: an agent infers you call this when you need to know whether another brand can be created. There is no stated condition, prerequisite, or named alternative, but for a zero-argument read tool the intended context is fairly self-evident.

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 establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real value by disclosing the return payload shape — the saved draft, revision, inputSlots, connections, placement, and output asset IDs — which is meaningful context in the absence of an output schema.

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

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

A single front-loaded sentence with zero filler. Every listed item (draft contents, revision, inputSlots, connections, placement, output asset IDs) earns its place by describing the return payload.

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 carries the return-value burden and does so thoroughly by enumerating the node's contents. For a simple two-parameter read tool this is largely complete, though it omits usage context and any guidance on missing/invalid node IDs.

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

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

Schema description coverage is 100%, and the schema itself documents both nodeId (with the 'not an assetId' clarification) and workspaceId. The description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Returns') tied to a precise resource ('a canvas node's saved draft') and enumerates the returned fields (prompt, model, settings, revision, inputSlots, connections, placement, output asset IDs). This clearly differentiates it from siblings like fuzz_get_asset or fuzz_read_chat, though it doesn't explicitly name those alternatives.

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

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

The description offers no when-to-use guidance, no prerequisites, and no reference to alternative tools. A reader learns what comes back but nothing about when this tool is the right choice over fuzz_list_workspace_contents or fuzz_export_node.

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 establish the safe read profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower, and the description adds real value: it discloses that runs survive client disconnection, that pending questions/approvals can be surfaced, that errors are returned, and that MCP Apps clients render interactive previews. It stops short of describing rate limits, cursor semantics, or whether polling frequency matters.

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

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

Three tight sentences with zero filler, front-loaded with the return payload before the lifecycle and client-rendering details. Every sentence conveys distinct 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 correctly carries the burden of describing return content (status, events, questions/approvals, errors, asset IDs) and does so thoroughly. The one gap is the pagination/cursor flow, which is left entirely to the schema.

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

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

Schema description coverage is 100% and both parameters (runId, cursor) are fully documented in the schema as opaque values. The description adds no additional semantics about either parameter, so the baseline 3 applies.

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

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

States a specific verb ('Returns') and resource ('status, progress events, pending questions or approvals, errors and output asset IDs of an asynchronous brand, chat or generation run'), enumerating the payload so the agent knows exactly what it retrieves. It is clearly distinguishable from read-oriented siblings like fuzz_get_asset or fuzz_read_chat because it is scoped to asynchronous run tracking.

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 polling use case by framing the run as asynchronous and noting it continues if the client disconnects, which hints that this tool is how you resume/monitor work. However, it never explicitly states when to prefer it over siblings such as fuzz_read_chat or fuzz_get_node, nor does it mention the cursor-based pagination workflow. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered upstream. The description adds one genuine behavioral note – that the call does not affect what the user sees in the app – which is useful side-effect context, but it omits anything about return payload scope or the cost of enabling sessions.

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

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

Two short sentences, front-loaded with the primary behavior and zero filler. The optional-sessions clause and the non-UI-impact note each carry information, though the second sentence is slightly oblique in wording.

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

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

For a read-only fetch with nested pagination and no output schema, the description covers the retrieval and the optional sessions flag but says nothing about what a workspace object contains or how this differs from fuzz_list_workspace_contents. Adequate but with a visible gap around return content and sibling routing.

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

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

Schema description coverage is 100%, so all three parameters (including the nested pagination object) are already documented in the schema, including the nextCursor guidance and the chat:read requirement for includeSessions. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('Returns one workspace'), plus an optional expansion ('its resumable chat sessions'). It is clearly distinguishable from fuzz_list_workspaces by the singular object, but it never names a sibling or contrasts itself explicitly with alternatives like fuzz_list_workspace_contents.

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

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

Usage is only implied: an agent can infer this is the by-ID single-fetch tool versus fuzz_list_workspaces, and that includeSessions is opt-in. There is no explicit when-to-use/when-not guidance, no stated prerequisites (e.g. needing an ID from fuzz_create_workspace), and no routing to related siblings such as fuzz_list_workspace_contents.

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 read-only, idempotent and non-destructive, so the safety profile is covered. The description adds domain-specific behavior the annotations cannot: the ready=true/false distinction and the instruction to relay failure notes to the user, which materially affects how an agent handles results.

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

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

Three tight sentences, front-loaded with what the tool returns, then the brand concept, then the ready-flag handling rule. Every sentence earns its place with no repetition of schema or annotation 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?

No output schema exists, so the description partially compensates by describing brand contents and the ready/note fields returned. Pagination mechanics live in the schema and the read-only safety profile is covered by annotations, so an agent has enough to call it correctly; only a fuller return-shape description 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?

Only one parameter (a nested page object) and schema description coverage is 100%, so the schema already documents limit, cursor and the follow-nextCursor instruction. The description adds nothing about pagination, 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?

States a specific verb and resource ('Lists the Fuzzbucket brands') and scopes it to the signed-in user, then defines what a brand contains (identity, products, audience, style). Clear and specific, though it never explicitly positions itself against the singular sibling fuzz_get_brand, leaving that differentiation to inference.

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

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

Gives concrete operating guidance: use brands with ready=true, and for ready=false brands surface the note to the user. That is real when/when-not guidance for consumers. It does not name an alternative tool or state prerequisites, so it stops short of the top tier.

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

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

Annotations already declare readOnlyHint/idempotentHint/openWorldHint=false, so safety is covered; the description adds that the call is workspace-scoped and that the modelId path returns a richer payload (aspect ratios, resolutions, durations, reference limits). No pagination or auth notes, but for a read-only list this is solid added 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 filler, with the primary list behavior front-loaded and the modelId detail path second. Every clause carries information about either output fields or parameter behavior.

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 usefully enumerates what the list returns and what the modelId detail mode returns, which is the main completeness requirement here. Minor gaps (no mention of empty results, pagination, or error cases) keep it short of a 5.

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?

mediaType has an enum but no schema description, and the description supplies its meaning as a filter; modelId's schema text is reinforced by explaining that it triggers the detail payload. workspaceId's scoping is already in the schema and the description confirms it, so coverage of the less-documented params is genuinely improved.

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 (Lists) and resource (models) scoped to a workspace, and enumerates the returned fields (ID, label, provider, generation modes, credit estimate). It also distinguishes the two modes of the call, so an agent knows it can either enumerate models or drill into one.

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 filter by mediaType and to pass modelId to get that model's supported settings and full credit estimate — a clear statement of the two usage paths. It does not name exclusions or when not to use it, but the conditional guidance is direct and actionable.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds real value beyond that: it discloses that two resource types are mixed in one result, that results can be name-searched, and that pagination applies. It still omits ordering and whether results are truncated.

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, both front-loaded with the resource list first and the identifier caveat second. No filler and every clause carries information.

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

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

With no output schema and a nested page object, the description carries return-shape burden and only says what categories come back. It does not describe the default behavior of kind, result ordering, or the exact fields of a node/asset entry, leaving gaps for a 4-parameter tool.

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

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

Schema description coverage is only 50%, so the description must compensate. 'Name search' maps to the otherwise undocumented query parameter, and pagination is covered by both the description and the nested page schema, but the kind enum values (node/asset/all) are never explained in prose or schema.

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

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

The description states a specific verb (lists) and resources (canvas nodes and stored assets) scoped to a workspace, which is enough to separate it from fuzz_get_node/fuzz_get_asset. It does not explicitly name a sibling alternative, so an agent must infer the boundary from the verb alone.

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

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

Usage is implied by the mention of name search and pagination and by the 'Node IDs and asset IDs are different identifiers' warning, which hints at how downstream lookups should be routed. However, it never states when to prefer this tool over fuzz_get_asset, fuzz_get_node, or fuzz_preview_assets, nor any prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds useful domain context about what a workspace contains but says nothing about pagination behavior or result shape beyond what the schema already documents.

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

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

Two short sentences, front-loaded with the verb and resource, with the second sentence earning its place by defining the workspace concept an agent needs to interpret the result. No filler or restatement of the name.

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

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

No output schema exists, so the description ideally would hint at the returned shape or pagination, but it stays silent on both. Combined with a fully documented input schema and complete safety annotations, it is adequate but not complete for a list tool with cursor pagination.

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

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

Schema description coverage is 100% and the schema itself documents brandId provenance and the bounded page/cursor semantics in detail. The description adds no parameter-level meaning, so the baseline of 3 applies.

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

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

States a specific verb (Lists) and resource (workspaces) scoped to a brand, clearly distinguishing itself from fuzz_get_workspace and fuzz_list_workspace_contents by name. It does not explicitly name or contrast alternatives, but the resource boundary is unambiguous enough for an agent to route correctly.

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

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

No when-to-use, when-not-to-use, or alternative routing guidance appears in the description. The second sentence is domain context (what a workspace is), not usage guidance, and the brandId provenance hint lives only in the schema, not the description.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world. The description adds real behavior beyond that: the four-asset cap, that images come back as image content while other types return metadata only, and the MCP Apps gallery rendering. That is meaningful return-behavior context the annotations cannot carry.

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?

Roughly two sentences, front-loaded with purpose and scope, followed by the fallback routing. Every clause carries information; nothing is redundant.

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

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

With no output schema, the description carries the burden and does describe what comes back per asset type, which is the key gap for a preview tool. It omits edge cases such as behavior when an asset is missing or oversized, so it is strong but not exhaustive.

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

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

Schema coverage is only 50%, with assetIds carrying no inline description, but the description compensates by stating 'up to four stored assets from one workspace', which explains both the maxItems=4 bound on assetIds and the single-workspace constraint on workspaceId. It adds material meaning over the bare array/string schema.

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

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

States a specific verb and resource ('Returns compact previews of up to four stored assets'), plus the scope constraint of a single workspace. It also distinguishes itself from sibling fuzz_download_asset, which serves originals, so an agent can route correctly without opening any schema.

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

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

Explicitly routes the agent to fuzz_download_asset when original files are needed, which is a clear alternative with a selecting condition. It does not spell out an explicit 'do not use this when...' case, but the preview-vs-original split is clear enough.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds only that messages are 'persisted' (implying stored history rather than a live stream) and that pagination applies, which is modest added context beyond the structured fields.

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

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

A single tight sentence with the pagination caveat placed at the end; no filler or repetition. It is appropriately sized, though it is on the thin side for a tool whose return shape is undocumented.

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

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

For a read-only, closed-world tool with 3 parameters, 100% schema coverage and no output schema, the description covers what is needed to call it. It does not hint at the shape or volume of returned messages, but annotations and schema carry the rest.

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%, with the nested page object's limit and cursor semantics fully documented inline, so baseline 3 is exceeded only slightly by the description's 'pagination' mention. The description adds no syntax or format detail beyond the schema.

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

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

States a specific verb ('Returns') and resource ('persisted user and assistant messages from a workspace chat session'), so the agent knows exactly what it retrieves. It does not differentiate itself from any sibling tool, though the chat-history scope is distinct from the asset/node/workspace tools listed.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named. The schema mentions where sessionId comes from, but the description itself leaves all routing decisions to inference.

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