Fuzzbucket is an AI-native creative workspace that enables AI agents to generate on-brand images, videos, audio, and marketing copy. Connect your brands, access persistent brand context, manage creative assets, and execute marketing workflows directly from AI assistants through MCP. Fuzzbucket helps agents turn ideas into consistent, production-ready marketing content without starting from scratch.
Scored across 16 tools
Each tool maps to a distinct resource and action: brands, workspaces, nodes, assets, models, runs and chat are clearly separated. Similar-looking tools such as get_asset, download_asset, preview_assets and export_node(s) are differentiated by purpose and output format.
All tools use a consistent fuzz_ prefix followed by a verb_noun pattern. Singular/plural distinctions like export_node vs export_nodes are intentional and readable.
The 16-tool surface is slightly above the typical 3-15 range but remains well scoped for a creative workspace covering brands, workspaces, nodes, assets, models, runs and chat. No obviously redundant tools inflate the count.
The server covers read, preview, download/export, and run-status operations well, but it lacks create/update/delete operations for core resources and has no tool to start a generation, chat or brand run despite providing get_run and list_models. This creates notable dead ends for agents attempting to perform creative work rather than only inspect or export existing content.
Prepares a 15-minute private download of one stored asset’s original file. Returns a URL with the private request headers needed to fetch it, and an equivalent downloadUrl that opens directly in a browser. Both are credentials for that one file.
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes | Stored content asset ID from contents, node outputs, or upload completion. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
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.
Prepares a 15-minute private ZIP export of one canvas node. The ZIP is built when the link is fetched; nothing is saved in the workspace. Returns a URL with the private request headers needed to fetch it, and an equivalent downloadUrl that opens directly in a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format. Only zip is supported, which is also the default. | |
| nodeId | Yes | Canvas nodeId returned by fuzz_list_workspace_contents or a node tool. Not an assetId. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, and closed-world. Description adds critical behavioral detail beyond annotations: the export is ephemeral (15 minutes), built on fetch, not persisted in the workspace, and returns a URL plus private request headers and a browser-openable downloadUrl.
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-load the purpose, then explain lifecycle and return values. No redundant or filler language; every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe returns—it does so precisely (URL with headers, downloadUrl). Combined with annotations and full schema coverage, the definition is complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines all parameters. The description does not add syntax, format, or constraint details beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Prepares') and resource ('ZIP export of one canvas node'), with scope conditions ('15-minute private'). Distinguishes from sibling fuzz_export_nodes by specifying 'one canvas node' and describing the return contract.
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: single-node export, private, temporary, and returns fetch instructions. Does not name fuzz_export_nodes as an alternative or state when not to use this tool, so it stops short of explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prepares a 15-minute private ZIP export of several canvas nodes from one workspace. The ZIP is built when the link is fetched; nothing is saved in the workspace. Returns a URL with the private request headers needed to fetch it, and an equivalent downloadUrl that opens directly in a browser.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Export format. Only zip is supported, which is also the default. | |
| nodeIds | Yes | Canvas node IDs returned by the server, all in the specified workspace. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint, so the safety profile is covered. The description adds rich context beyond annotations: a 15-minute expiry, private ZIP, lazy build when the link is fetched, no workspace persistence, and a return structure with private request headers plus an equivalent downloadUrl.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste; the core action and scope are front-loaded, followed by essential behavioral and return details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value (URL with private headers and downloadUrl). It covers expiry, privacy, and non-persistence, and the annotations carry the safety profile. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (format, nodeIds, workspaceId) including constraints. The description adds no parameter-specific syntax or format details beyond what the schema already provides, so it lands at 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?
States a specific verb 'export' and resource 'canvas nodes' with the scope 'several canvas nodes from one workspace'. The plural 'several' directly distinguishes it from the sibling fuzz_export_node (singular), so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multiple nodes ('several canvas nodes') but never explicitly states when to use this tool versus the singular fuzz_export_node or other export/download siblings. There are no exclusions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a stored asset’s name, MIME type, size, dimensions and, for text assets, its text content.
| Name | Required | Description | Default |
|---|---|---|---|
| assetId | Yes | Stored content asset ID from contents, node outputs, or upload completion. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
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.
Returns the creative context of one brand: tagline, description, sectors, website domains, logo usages, colors, fonts, voice, products and audience. Use it to keep content on brand; generation applies the brand logos itself. It does not return contact details, social accounts or media links.
| Name | Required | Description | Default |
|---|---|---|---|
| brandId | Yes | Brand ID returned by fuzz_list_brands or fuzz_create_brand. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it scopes the payload positively, states explicit exclusions (no contact details, social accounts, media links), and tells the agent that logo application happens during generation rather than being its job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return payload, then usage and exclusions. No filler; every clause (field list, the logo note, the exclusion list) carries information the agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return-value burden and does so by enumerating what comes back and what does not. For a single-parameter read tool already covered by annotations, only minor gaps (shape of nested fields like colors/fonts) remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%; the schema already explains that brandId comes from fuzz_list_brands or fuzz_create_brand. The description adds nothing about the identifier format or failure modes, 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 ('Returns the creative context of one brand') and enumerates the returned facets: tagline, sectors, colors, fonts, voice, products, audience. This makes it distinguishable from siblings like fuzz_get_asset or fuzz_get_workspace. It doesn't explicitly name sibling alternatives, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use it to keep content on brand' gives an implied usage context, and 'generation applies the brand logos itself' hints at a downstream workflow. However, there is no explicit when-not or named alternative (e.g., fuzz_preview_brand_logos for logos only), leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns how many brands the user has, the brand limit of their current plan, how many more they can create and whether a new brand can be created now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world. The description adds useful behavioral context by specifying the four pieces of quota information returned. It does not cover auth requirements or error conditions, but the annotations lower the burden and the return-value disclosure is valuable, especially with no 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 that efficiently lists the four return values with no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless read tool with no output schema, the description fully explains what the tool returns. The annotations cover the safety profile, and nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to explain any parameters, and the empty schema is 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 brand quota details. It clearly enumerates what is returned (current count, plan limit, remaining allowance, and whether creation is currently possible), which distinguishes it from sibling tools like fuzz_list_brands or fuzz_get_brand that deal with brand entities rather than quota.
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 guidance on when to use this tool versus alternatives, nor does it name any sibling or condition for selection. It is purely a statement of what is returned, leaving the agent to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a canvas node’s saved draft (prompt, model, settings), revision, supported inputSlots, connections, placement and output asset IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Canvas nodeId returned by fuzz_list_workspace_contents or a node tool. Not an assetId. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
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.
Returns the status, current step, pending question or approval, error, output node and asset IDs and, for chat runs, the assistant’s reply text of an asynchronous brand, chat or generation run. A run continues if the client disconnects. In clients that support MCP Apps, completed image, video and audio outputs are shown in an interactive preview.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | Opaque MCP runId returned by brand creation, chat send or node generation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuinely non-obvious behavior: that the run continues if the client disconnects, and that MCP Apps clients render completed image/video/audio output in an interactive preview. It stops short of describing terminal status values or polling guidance, so not 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 sentences, front-loaded with the returned fields, and the second sentence adds a useful behavioral caveat. The first sentence is a long comma-list that is dense but each item is informative; minimal waste overall.
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 takes on the job of enumerating return fields, including error and pending-approval cases, which is the critical gap for a status tool. It omits what the possible status values are, which would help an agent decide when to stop polling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter and schema coverage is 100%, so the schema already explains that runId is an opaque ID returned by brand creation, chat send or node generation. The description adds no format, length, or lookup behavior 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?
States a specific verb ("Returns") and enumerates the exact resource contents: status, current step, pending question/approval, error, output node/asset IDs, and chat reply text. It also scopes which run types it covers (brand, chat, generation), which is enough to separate it from siblings like fuzz_read_chat or fuzz_get_node.
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: the phrase "asynchronous ... run" plus runId hints this is a polling tool for runs created elsewhere. It never explicitly says when to use this instead of fuzz_read_chat or fuzz_get_node, nor does it say whether to poll or how often. Adequate but leaves routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one workspace and, optionally, its chat conversations that can be continued. Does not change what the user sees in the Fuzzbucket app.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. | |
| conversationsPage | No | Pagination for conversations; only valid when includeConversations is true. | |
| includeConversations | No | Include the workspace chat conversations that can be continued; requires chat:read in addition to workspace access. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral note – that it does not alter what the user sees in the Fuzzbucket app – and clarifies conversations are only those that can be continued. It says nothing about failure modes (e.g. unknown workspace ID) or the extra chat:read scope beyond what the schema already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary capability front-loaded and the optional behavior immediately after. Nothing is redundant and nothing is buried.
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 getter with full schema coverage and explicit annotations, this covers what an agent needs to call it correctly. The one gap is the absence of an output schema combined with only a one-line sketch of the return value (workspace shape, how conversations are nested), which an agent must discover at call time.
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 workspaceId, includeConversations, limit and cursor are all documented in the schema itself, setting the baseline at 3. The description only reinforces that conversations are optional and filtered to continuable ones; it adds no pagination behavior or ordering details 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 and resource ("Returns one workspace") plus an optional expansion (chat conversations that can be continued). It implicitly separates itself from fuzz_list_workspaces by being singular, but never names the sibling or the ID-based lookup explicitly, so it stops just short of a 5.
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 single-workspace fetch when the ID is known. There is no when-to-use/when-not statement and no explicit pointer to fuzz_list_workspaces for discovery or to fuzz_list_workspace_contents for content listing, despite several plausible alternatives in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the Fuzzbucket brands owned by the signed-in user. A brand holds the identity, products, audience and style used by creative work. Brands with ready=true can be used for creative work; a brand that is still being set up or whose setup failed has ready=false and a note explaining why.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional bounded page size and cursor; follow the returned cursor for more results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: what a brand composes (identity, products, audience, style) and the meaning of the ready flag plus its explanatory note, which is valuable given there is no 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?
Three short sentences, front-loaded with the identifying verb and resource, then resource semantics. No filler and nothing repeated from the schema 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 burden of describing results and does so for brand fields and the ready/note distinction. It omits that the response is paginated with a nextCursor envelope, a minor gap given the schema hints at cursor-following.
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 page object documents limit (1-50), cursor, and the instruction to follow nextCursor. The description adds nothing about pagination, 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 with explicit scope: 'Lists the Fuzzbucket brands owned by the signed-in user.' The second sentence defines what a brand contains, which disambiguates it from get-style siblings like fuzz_get_brand by making clear this is an enumerating view of the whole brand collection, though the sibling is never named.
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 rather than stated: 'Brands with ready=true can be used for creative work' tells the agent what to do with results, but there is no explicit routing guidance such as when to call this versus fuzz_get_brand or fuzz_get_brand_quota, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the models available to the user for a workspace: ID, label, provider, generation modes and a credit estimate for each. Filter by mediaType; pass modelId to get that model's supported settings (aspect ratios, resolutions, durations, reference limits) and full credit estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| modelId | No | Model ID returned by fuzz_list_models for this workspace and media type. | |
| mediaType | No | Only list models for this media type. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description only needs to add context. It does: passing modelId changes the response shape to include supported settings and a full credit estimate, which the agent could not infer from annotations. Pagination and ordering behavior remain unstated.
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 tightly packed sentences with zero filler; the enumeration of returned fields is front-loaded and the modelId drill-down behavior follows immediately.
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 returns and does so adequately, listing the per-model fields and the enriched payload when modelId is supplied. It stops short of covering ordering, pagination, or empty-result behavior, but nothing essential for a correct call 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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the semantic effect of modelId (returns that model's settings and full credit estimate) and confirming mediaType as a list filter rather than a required scoping 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?
States a specific verb and resource (lists models available for a workspace) and enumerates exactly what is returned: ID, label, provider, generation modes, and a credit estimate. No sibling tool does anything comparable, so an agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete routing guidance for its two modes: use mediaType to filter the list, and pass modelId to drill into a single model's supported settings. It does not state when not to use it or name an alternative, but no sibling overlaps this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists canvas nodes and stored assets in a workspace, with name search and pagination. Node IDs and asset IDs are different identifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Type of item to create or list. | |
| page | No | Optional bounded page size and cursor; follow the returned cursor for more results. | |
| query | No | Case-insensitive name filter. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
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 by structured data. The description adds limited but real context — that search is by name and results are paginated, and that node and asset identifiers are distinct namespaces. It does not disclose default page size, ordering of results, or what a page contains, so it clears the lower bar but does not exceed it.
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 no filler. The primary capability is front-loaded and the identifier caveat follows as a compact, high-value warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, a nested page object, no output schema, and full annotation coverage, the description needs to convey scope, filtering, pagination, and result identity — and it does all four at a high level. The remaining gap is return-shape detail (items array, nextCursor behavior), which the cursor parameter description partially covers, so this falls just short of fully self-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%, including the enum for 'kind' and the nested page.limit/page.cursor documentation, so the baseline is 3. The description reinforces the name-search and pagination semantics and adds the useful warning that node IDs and asset IDs are different identifier types (relevant when interpreting 'kind' results), but it does not explain defaults or the interaction between kind=all and pagination.
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: listing canvas nodes and stored assets within a workspace, plus the supported capabilities (name search, pagination). It is distinguishable from siblings like fuzz_get_node and fuzz_get_asset by being the collection-listing operation, but it never names those siblings explicitly, so differentiation is inferred rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description ('Lists ... in a workspace'), and an agent can reason that single-item retrieval belongs to fuzz_get_node/fuzz_get_asset. However, there is no explicit when-to-use or when-not guidance, no prerequisites, and no routing between this tool and the previews or get_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists workspaces for a brand. A workspace holds an orchestrator chat and a canvas of nodes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional bounded page size and cursor; follow the returned cursor for more results. | |
| brandId | Yes | Brand ID returned by fuzz_list_brands or fuzz_create_brand. |
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. The description's only additional contribution is domain context about what a workspace contains (chat + canvas of nodes), which aids interpretation but reveals nothing about pagination behavior or result volume. With annotations carrying the behavioral burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero waste, with the core action front-loaded. The second sentence is compact and earns its place by defining a domain term the agent will encounter repeatedly across sibling tools.
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 indicate what a listed workspace contains (e.g. id, name, timestamps). Pagination semantics are covered by the schema and safety by annotations, but the return shape remains entirely unspecified. It is adequate to invoke correctly but not 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%, with both brandId and the nested page/limit/cursor documented in the schema, including the guidance to follow nextCursor rather than enlarging the page. The description adds nothing beyond that baseline, merely restating the brand scoping. 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 scoped by owner: "Lists workspaces for a brand." The plural 'list' plus the brand scoping makes it distinguishable from the singular fuzz_get_workspace and from fuzz_list_workspace_contents, though no sibling is named explicitly. The second sentence clarifies what a workspace is, reinforcing the resource identity.
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 explicit guidance on when to use this versus fuzz_get_workspace (single workspace) or fuzz_list_workspace_contents (contents of one workspace). The brand scoping only implies the usage context. No prerequisites, exclusions, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns compact previews of up to four stored assets from one workspace: small thumbnails as image content for images and videos (a frame from the video), plus name, type and size for audio, text and other files. In clients that support MCP Apps, the previews are shown in an interactive gallery. Original files are available through fuzz_download_asset.
| Name | Required | Description | Default |
|---|---|---|---|
| assetIds | Yes | Stored asset IDs from this workspace (up to four). | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive). The description adds real value beyond them: per-asset-type return content (thumbnails/frames vs. name/type/size) and MCP Apps gallery behavior. It does not mention behavior for invalid IDs or workspace mismatches, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core return behavior, followed by conditional per-type details and a pointer to the alternative. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description explains what is returned for each asset type, which is the key unknown for this tool. Combined with complete parameter docs and rich read-only annotations, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters fully described and the four-item cap enforced by maxItems. The description reiterates 'up to four' and 'from one workspace' but adds no format or syntax detail beyond the schema, so the 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?
Specific verb + resource + scope: 'Returns compact previews of up to four stored assets from one workspace.' It is clearly distinguishable from fuzz_get_asset and fuzz_download_asset, and the explicit reference to fuzz_download_asset for originals reinforces 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 description states the context (quick previews) and explicitly names the alternative for full files: 'Original files are available through fuzz_download_asset.' However, no explicit when-not condition or error-handling guidance is given, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns small thumbnails of up to five logos of one brand as image content, with each logo’s usage (for example primary or icon). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| brandId | Yes | Brand ID returned by fuzz_list_brands or fuzz_create_brand. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the bar is lower, and the description still adds real value: the result is image content, capped at five logos, each labeled with its usage. It does not cover edge behavior such as what happens when a brand has no logos or whether the five are ordered/prioritized.
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 delivers the return shape and scope with no filler; 'Read-only' is redundant with the annotations but costs only two 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?
There is no output schema, so the description must carry the return contract — and it does, specifying image content, the five-logo cap, and per-logo usage labels. Minor gaps remain around empty-result and ordering behavior.
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 a single parameter and 100% schema description coverage (including the pointer to fuzz_list_brands / fuzz_create_brand as the source of brandId), the schema does the work. The description adds no further detail about brandId semantics, 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 and resource — returns thumbnails of logos for one brand — plus the exact scope: up to five, as image content, each annotated with usage. This clearly separates it from fuzz_get_brand (full brand data) and fuzz_preview_assets (other asset types).
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 phrase 'of one brand' and the 'up to five' cap imply a lightweight inspection use case, but the description never says when to pick this over fuzz_get_brand, fuzz_preview_assets, or fuzz_download_asset, and includes no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns persisted user and assistant messages from a workspace chat conversation, with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Optional bounded page size and cursor; follow the returned cursor for more results. | |
| workspaceId | Yes | Workspace ID returned by fuzz_list_workspaces or fuzz_create_workspace. Resources must belong to this workspace. | |
| conversationId | Yes | Workspace chat conversation ID returned by fuzz_send_chat_message or fuzz_get_workspace. Where it is optional, omitting it starts a new conversation. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds only that messages are 'persisted' and paginated; it does not say whether empty conversations error, how ordering works, or what the cursor contract implies beyond the schema's own text.
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 no filler; the resource and the pagination trait appear immediately.
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 list tool with full parameter documentation and annotations covering safety, the description is close to sufficient, and it indicates what is returned (user and assistant messages). It lacks any note on message ordering or what a page of results looks like, which matters slightly since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, including detailed notes on limit bounds and cursor usage, so the baseline is 3. The description contributes nothing beyond reiterating pagination, which the schema already explains thoroughly.
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 conversation'), plus the pagination trait. It clearly is not a mutation or a workspace listing, so an agent can separate it from siblings like fuzz_get_workspace, though it does not name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when to use this versus alternatives such as fuzz_get_workspace (which the schema notes also returns conversation IDs) or message-sending tools. The only usage-like hint is the pagination mention, which is really a behavioral note rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fuzz_get_run1 field changedInput schema / properties / cursorRemoved value: -{
- "description": "Opaque pagination/event cursor returned by the previous response. Omit for the first page.",
- "maxLength": 2048,
- "minLength": 1,
- "type": "string"
-}fuzz_get_workspace4 fields changedInput schema / properties / conversationsPageAdded value: +{
+ "additionalProperties": false,
+ "description": "Pagination for conversations; only valid when includeConversations is true.",
+ "properties": {
+ "cursor": {
+ "description": "Opaque pagination cursor returned by the previous response. Omit for the first page.",
+ "maxLength": 2048,
+ "minLength": 1,
+ "type": "string"
+ },
+ "limit": {
+ "description": "Page size from 1 to 50. Follow nextCursor rather than requesting a larger page.",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+ }
+ },
+ "required": [],
+ "type": "object"
+}Input schema / properties / includeConversationsAdded value: +{
+ "description": "Include the workspace chat conversations that can be continued; requires chat:read in addition to workspace access.",
+ "type": "boolean"
+}Input schema / properties / includeSessionsRemoved value: -{
- "description": "Include resumable chat sessions; requires chat:read in addition to workspace access.",
- "type": "boolean"
-}Input schema / properties / sessionsPageRemoved value: -{
- "additionalProperties": false,
- "description": "Pagination for sessions; only valid when includeSessions is true.",
- "properties": {
- "cursor": {
- "description": "Opaque pagination/event cursor returned by the previous response. Omit for the first page.",
- "maxLength": 2048,
- "minLength": 1,
- "type": "string"
- },
- "limit": {
- "description": "Page size from 1 to 50. Follow nextCursor rather than requesting a larger page.",
- "maximum": 50,
- "minimum": 1,
- "type": "integer"
- }
- },
- "required": [],
- "type": "object"
-}fuzz_list_brands1 field changedInput schema / properties / page / properties / cursor / descriptionPrevious value: -"Opaque pagination/event cursor returned by the previous response. Omit for the first page."New value: +"Opaque pagination cursor returned by the previous response. Omit for the first page."fuzz_list_workspace_contents1 field changedInput schema / properties / page / properties / cursor / descriptionPrevious value: -"Opaque pagination/event cursor returned by the previous response. Omit for the first page."New value: +"Opaque pagination cursor returned by the previous response. Omit for the first page."fuzz_list_workspaces1 field changedInput schema / properties / page / properties / cursor / descriptionPrevious value: -"Opaque pagination/event cursor returned by the previous response. Omit for the first page."New value: +"Opaque pagination cursor returned by the previous response. Omit for the first page."fuzz_preview_brand_logosfuzz_read_chat4 fields changedInput schema / properties / conversationIdAdded value: +{
+ "description": "Workspace chat conversation ID returned by fuzz_send_chat_message or fuzz_get_workspace. Where it is optional, omitting it starts a new conversation.",
+ "maxLength": 255,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / page / properties / cursor / descriptionPrevious value: -"Opaque pagination/event cursor returned by the previous response. Omit for the first page."New value: +"Opaque pagination cursor returned by the previous response. Omit for the first page."Input schema / properties / sessionIdRemoved value: -{
- "description": "Chat or onboarding session ID returned by an earlier call. Where it is optional, omitting it starts a new session.",
- "maxLength": 255,
- "minLength": 1,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "workspaceId",
- "sessionId"
-]New value: +[
+ "workspaceId",
+ "conversationId"
+]fuzz_export_node4 fields changedInput schema / properties / format / descriptionPrevious value: -"Optional export format supported by the node. Omit to use the normal app default; unsupported formats fail."New value: +"Export format. Only zip is supported, which is also the default."Input schema / properties / format / enumAdded value: +[
+ "zip"
+]Input schema / properties / format / maxLengthRemoved value: -32Input schema / properties / format / minLengthRemoved value: -1fuzz_export_nodes4 fields changedInput schema / properties / format / descriptionPrevious value: -"Optional export format supported by the node. Omit to use the normal app default; unsupported formats fail."New value: +"Export format. Only zip is supported, which is also the default."Input schema / properties / format / enumAdded value: +[
+ "zip"
+]Input schema / properties / format / maxLengthRemoved value: -32Input schema / properties / format / minLengthRemoved value: -1fuzz_get_brand1 field changedInput schema / properties / brandId / descriptionPrevious value: -"Brand ID returned by fuzz_list_brands or fuzz_create_brand. Optional when answering an onboarding question before the brand profile exists."New value: +"Brand ID returned by fuzz_list_brands or fuzz_create_brand."fuzz_list_models1 field changedInput schema / properties / mediaType / descriptionAdded value: +"Only list models for this media type."fuzz_list_workspace_contents2 fields changedInput schema / properties / kind / descriptionAdded value: +"Type of item to create or list."Input schema / properties / query / descriptionAdded value: +"Case-insensitive name filter."fuzz_list_workspaces1 field changedInput schema / properties / brandId / descriptionPrevious value: -"Brand ID returned by fuzz_list_brands or fuzz_create_brand. Optional when answering an onboarding question before the brand profile exists."New value: +"Brand ID returned by fuzz_list_brands or fuzz_create_brand."fuzz_preview_assets1 field changedInput schema / properties / assetIds / descriptionAdded value: +"Stored asset IDs from this workspace (up to four)."fuzz_read_chat1 field changedInput schema / properties / sessionId / descriptionPrevious value: -"Chat or onboarding session identifier returned by the corresponding tool. Omit on a new send/create when no session exists."New value: +"Chat or onboarding session ID returned by an earlier call. Where it is optional, omitting it starts a new session."fuzz_download_assetfuzz_export_nodefuzz_export_nodesfuzz_get_assetfuzz_get_brandfuzz_get_brand_quotafuzz_get_nodefuzz_get_runfuzz_get_workspacefuzz_list_brandsfuzz_list_modelsfuzz_list_workspace_contentsfuzz_list_workspacesfuzz_preview_assetsfuzz_read_chat
Add one secure layer between your agents and this server.