Meta Muse MCP Server by useapi.net (third-party)

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

Annotations only declare safety flags (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description adds substantive behavior: that it follows the chat up to ~50 s and returns the rest of the answer unless wait is false, and that allow_always persists a permission for the whole account from now on. Auth requirements and error 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?

Three front-loaded sentences that lead with the action and follow with behavior and endpoint. Tight overall, though the trailing POST /chats/{chatId}/approvals/{approvalId} is somewhat redundant with the parameter names.

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 by describing the follow-up polling ('follows the chat up to ~50 s and returns the rest of the answer'). Given the 4-param mutation it fully equips the 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it expands the 'decision' values (allow_once, allow_always with an explanation that it grants site-wide, account-level, persistent permission, deny) and explains the wait flag's follow-up behavior. This goes beyond the schema's terse descriptions.

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

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

States a specific verb (answer) and resource (the agent's permission request/approval), and clarifies that the approval originates from muse_chat, muse_get_chat or muse_list_approvals. An agent can distinguish this from the other sibling tools (e.g. muse_answer_widget) 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?

Explains the context in which the tool applies (answering a permission request surfaced by sibling tools) and enumerates the valid decisions. It does not explicitly contrast against muse_answer_widget or state when NOT to use it, but the surrounding context is clear.

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

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

Annotations declare a non-idempotent, open-world mutation, and the description usefully adds the consequence ('the answer is a new message in the chat') plus the blocking behavior ('follows the reply up to ~50 s'). That is real context beyond the annotations, though permission or rate-limit context is absent.

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

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

One dense paragraph that leads with the action, then the exclusivity rule, then the effect and wait semantics, and ends with the endpoint. Every clause carries information; 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?

For a write tool with no output schema, the description covers the key unknowns: what gets created, whether the call blocks, and how long. It does not describe the format of the returned reply, which is a minor gap against the ~50 s follow behavior it promises.

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 option index origin, the 5000-char text limit, wait default, and the option/text exclusivity. The description largely repeats this, adding little that the schema does not already state, 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: answers a quick-reply widget from the agent's message, with two ways to answer (option index or free text). The parenthetical '(kind option)' hints at widget kinds and thus differentiates from the approval sibling only implicitly, so it is clear but not fully disambiguated.

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 context is implied ('from the agent's message') and the option-vs-text choice is described, but there is no explicit when-not guidance and muse_chat is referenced only as a behavioral parallel for waiting, not as an alternative to choose between. The agent must infer when this tool applies.

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=false, destructive=true, idempotent=true, openWorld=true, so safety and repeat-call behavior are covered. The description adds a genuine behavioral fact not derivable from those hints: the answer terminates in an "interrupted" state rather than being deleted or silently discarded. It stops short of saying whether partial output is preserved.

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

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

One front-loaded sentence carrying purpose, scope, and outcome, followed by a compact endpoint reference. No filler and nothing 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?

For a single-parameter, no-output-schema action whose safety profile is fully covered by annotations, the description supplies enough to call it correctly. Minor gaps remain around error/edge behavior (calling when no answer is running) and whether partial results survive.

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 sole parameter's own schema text is a bare restatement ("The chatId."). The description adds no format, source, or format-of-id detail beyond echoing the path template, 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?

Specific verb ("Stop") plus a precise resource and scope ("the answer Muse is working on in a chat"), with the observable outcome in parentheses. It is unambiguous and clearly distinct from the delete_* / stop_browser siblings, though it does not name an alternative tool 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 by the verb: an agent can infer it applies while a generation is in flight. There is no statement of when not to use it, no prerequisites (e.g. an active answer must exist), and no routing against siblings such as muse_chat or muse_get_chat.

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

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

Annotations declare this is not read-only and is open-world but say nothing about latency, cost, or payload. The description fills those gaps: ~50 s wait, a named status enum (completed / waiting_for_approval / running / interrupted), the fact that the account's weekly Muse allowance is consumed, and that pending permission requests may be returned. This is exactly the context 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?

Front-loaded with purpose, then return payload, then the escalation path; every sentence carries information. The trailing endpoint trace ('POST /chats or POST /chats/{chatId}/messages, then GET ...') is low-value for an agent choosing a tool and is the only expendable line.

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 the return shape itself — and it does: chatId, status, agent text, created assets with download urls, widgets, and pending permission requests. Combined with the timeout and quota disclosure, an agent has everything needed to call this correctly and handle the partial-result case.

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 the email, files, chatId, and message semantics plus the image_1/video_1 naming convention, so the schema already does the heavy lifting. The description restates the chatId new-vs-continue behavior but adds no syntax or constraint detail beyond the schema, making the baseline 3 correct.

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

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

Specific verb+resource ('Send a message to Muse ... and get its answer') with a scope qualifier that separates the new-chat and continue-chat modes. It also names the sibling tools it complements (muse_get_chat, muse_list_chats), so an agent can place it in the toolset 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?

Explicit branching rule: omit chatId to start a new chat, supply chatId to continue one. It further routes the agent to muse_get_chat (chatId, wait: true, after: lastEventId) precisely when status comes back 'running', which is a concrete when-to-use-alternative instruction rather than an implication.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is conveyed structurally. The description adds context about what an 'asset' covers and the underlying DELETE endpoint, but says nothing about reversibility, confirmation steps, or permission requirements.

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 front-loads the action and resource, then adds scope detail. No filler or redundancy.

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

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

For a one-parameter destructive delete whose annotations carry the safety profile and with no output schema to explain, the description covers action, identifier, and asset scope adequately. The only shortfall is the absence of any irreversibility or alternative-tool guidance.

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

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

Schema coverage is 100% with a single required assetId; the schema's own description is bare ('The assetId.'), and the tool description only restates 'by assetId' without format, source, or how to obtain one. This is the baseline expected 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?

Specific verb (Delete) plus resource (an asset from the Muse Library), with the scope clarified by enumerating asset kinds (media file, document, web app, podcast episode). This helps separate it from muse_delete_file and other delete siblings, though it never explicitly names the alternative it is distinct from.

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

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

States the required identifier ('by assetId') but gives no when-to-use or when-not-to-use guidance, no mention that deletion is irreversible, and no pointer to sibling tools like muse_delete_file or muse_delete_chat. Usage must be inferred entirely.

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 supply destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description still adds meaningful context beyond them: it discloses the blast radius (files created by the chat survive) and that the removal propagates to the muse.ai app, i.e. this is not a soft/hidden delete. It stops short of saying whether deletion is reversible or what permissions are required.

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

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

Three short, front-loaded sentences with zero filler: what it deletes, what survives, and the underlying endpoint. Every sentence contributes information an agent can act on.

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

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

For a single-parameter destructive tool with full annotation coverage and no output schema, the definition covers the essentials: the target, the persistence of derived files, and the external visibility of the delete. Nothing an agent needs in order to invoke 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% for the single chatId parameter, so the structured field already carries the naming burden. The description's 'DELETE /chats/{chatId}' reinforces how chatId is bound into the path but adds no format, source, or lookup guidance beyond the schema. 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 pairs a specific verb (Delete) with a specific resource (Muse chat) and further disambiguates it from the sibling delete tools (delete_asset, delete_file, delete_permission_rule) by naming the target object explicitly. It also states the visible consequence (it disappears from the muse.ai app), which confirms the effect of the operation.

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

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

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives such as muse_cancel_chat, which is the obvious sibling for stopping a chat without destroying it. The clarification 'the files it made stay' is a side-effect note, not usage guidance, so the agent must infer the selection criteria on its own.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the path-scoped targeting and the underlying REST mapping (DELETE /files), but says nothing about permanence, recoverability, or required scope beyond what annotations imply.

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 action front-loaded and no filler. The trailing 'DELETE /files' is mildly redundant for an agent but does anchor the tool to its API surface.

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 two-parameter destructive tool with full schema coverage and annotations covering safety, this is minimally adequate. An agent can call it correctly, but nothing warns about irreversible loss or failure modes (missing path, wrong workspace).

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 both parameters are already documented, including that email is optional when the token has a single Muse account. The description's 'by path' phrasing loosely reinforces the required path parameter but adds no format, encoding, or edge-case detail. 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?

Specific verb (Delete) plus resource (file in Muse workspace) scoped by path, which is more precise than a bare name restatement. It does not differentiate itself from nearby siblings like muse_delete_asset or muse_delete_chat, leaving the agent to infer the file-vs-asset distinction from names 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?

The description states what happens but gives no guidance on when to use this over muse_delete_asset or when a deletion is inappropriate. No prerequisites, no confirmation guidance, no mention of permissions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context by explaining the post-deletion behavior — the agent falls back to asking again per the defaults — which is not expressed in any structured field.

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

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

One compact sentence plus the endpoint, with the verb and resource front-loaded. The trailing clause about the agent asking again is slightly compressed and reads awkwardly, but no sentence is wasted.

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

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

For a two-parameter delete tool with rich annotations, the description covers purpose, identifier provenance, and the observable consequence of deletion. Missing auth/permission requirements and failure behavior are minor given the annotation coverage and the absence of an output schema.

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

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

Schema coverage is 100%, so both email and permissionId are already documented, including the note that permissionId comes from muse_get_permissions. The description's endpoint path restates those same parameters without adding format, validation, or edge-case detail, 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 and resource ('Delete one permission rule') and identifies where the identifier comes from ('from muse_get_permissions'), which distinguishes it from muse_set_permission_rule and muse_set_permission_defaults. It stops short of explicitly naming the sibling to use instead when the intent is to modify rather than remove.

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 when-to-use or when-not-to-use guidance and no routing to alternatives such as muse_set_permission_rule. The clause about the agent asking again next time describes the consequence of deletion, not the conditions under which this tool should be selected.

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=false (mutation), openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds key behavioral context: it waits up to ~50 seconds, returns either the finished image or a jobid to poll, uses the account's weekly allowance, and the endpoint. This goes beyond annotations by detailing timeout and return behavior.

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

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

The description is a single, dense sentence that front-loads the core action and then details optional inputs and return behavior. It is efficient but slightly packed; still, every part earns its place.

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

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

Given 11 parameters with full schema coverage and no output schema, the description provides necessary context: input handling, timeout, return values, and allowance usage. It is complete enough for an agent to call correctly, though it could mention error handling or rate limits.

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 parameters thoroughly. The description adds some usage detail (naming images in the prompt, specifying aspect ratio) but does not add significant new meaning beyond what the schema provides. Baseline 3 is appropriate when 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?

States a specific verb+resource ('Make one image with Muse') and distinguishes itself from the sibling muse_generate_video by naming the resource type. It also clarifies scope by noting optional editing/combining of up to 9 input images.

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

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

Explains when to use it (to generate an image from a prompt) and how to use inputs, but does not explicitly state when to use alternatives like muse_generate_video or when not to use this tool (e.g., for simple asset retrieval). It provides clear context but lacks exclusions.

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

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

Annotations only supply the generic non-read-only/open-world profile; the description adds the substantive traits: a ~50 s wait cap, that the call usually returns a jobid rather than the finished video, the required follow-up tool, and that it consumes the account's weekly Muse allowance (quota). That is real operational context the annotations cannot convey.

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?

Front-loaded with the action and its optional inputs, then the prompt conventions, then the async/waits behavior and cost, closing with the endpoint. No sentence is filler and the ordering matches how an agent would need the information.

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

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

For a 17-parameter mutation tool with no output schema, the description covers the async job lifecycle, required follow-up call, and quota cost. It could say a bit more about failure/error handling or job-status semantics, 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 adds usage semantics the schema lacks: inputs must be referred to by name (image_1, video_1, audio_1…) inside the prompt, videos are typically passed 'to edit', and aspect ratio/spoken lines are prompt-level requirements. This is genuinely additive rather than a restatement.

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+resource ('Make one video with Muse from a prompt') and immediately scopes the optional input modalities, which is exactly what separates it from the sibling muse_generate_image. An agent can pick it 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?

Gives clear invocation context: which asset id types to pass, that aspect ratio and spoken lines belong in the prompt, and that the follow-up path is muse_get_job (wait: true) after the ~50 s wait. It does not state when-not to use it (e.g. vs. muse_generate_image), so it stops short of full alternative routing.

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 cover read-only, idempotent and non-destructive semantics, but the description adds real context: it hits a live endpoint (GET /accounts/{email}), enumerates the returned fields (tier, percentUsed, resetsAt, quotaStatus, topup*, session state), and warns that topupBalance/topupTotal are in Muse's own unit, not tokens. That unit caveat is the kind of thing annotations cannot convey.

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?

Front-loaded with verb, resource and the LIVE qualifier, then the sibling disambiguation, then the return shape. The parenthetical quoting a literal UI string ('0% used (1B tokens left)') is slightly verbose but earns its place by anchoring the unit semantics.

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 naming the returned fields and the route (GET /accounts/{email}) is necessary and it is done well. Only minor gaps remain, such as behavior when the email is unknown or ambiguous across multiple accounts.

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

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

Schema coverage is 100% and the schema already explains that email is 'Optional when the API token has one Muse account.' The description does not add any further meaning to the parameter, so the baseline 3 applies since the schema 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?

States a specific verb and resource ('Read one Muse account') plus its defining trait: the read is LIVE against Muse rather than the stored copy. It explicitly names the sibling muse_list_accounts as the non-live alternative, 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?

Gives an explicit use/avoid split: 'Each call reads Muse: muse_list_accounts shows the stored copy without a call.' This tells the agent both what this tool costs (a live call) and which sibling to pick when a cached read suffices.

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 only cover the safety profile (readOnly, idempotent, openWorld, non-destructive). The description adds substantially beyond that: size thresholds (~1 MB image, 256 KB text), what is returned for unhandled types (type/size/name/download url), the requirement to reuse the Authorization header when GETting the url, and the ~10 s PDF conversion that re-runs on each fetch.

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?

Front-loaded with the operation and organized by return branch, part, then format, ending with the raw endpoint. Dense but essentially waste-free; readability suffers slightly from packing many clauses into a single long sentence.

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 fully — it explains the three possible response shapes, the download-url path and its auth requirement, and conversion timing. Nothing material for correct invocation 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 adds meaning beyond the schema: format=pdf is described as a server-side conversion taking about 10 seconds whose download url re-converts when fetched, and part=cover is tied to the podcast cover flow.

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

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

States a specific verb and resource ('Fetch an asset by assetId') and then details the three distinct return paths by asset type and size. An agent can distinguish this from list-style siblings like muse_list_assets or muse_read_file 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?

The description establishes clear context: this is the by-id retrieval tool, with part=cover scoped to podcast assets and format=pdf scoped to document assets. It does not explicitly name alternatives (e.g. use muse_list_assets to discover assetIds), so it stops short of full when/when-not routing.

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 safety profile is covered. The description adds substance beyond that: it discloses the returned state fields, including 'who controls it (agent or user)' and 'previewAvailable, parkedExpiresAt', which conveys the lifecycle behavior of the browser session.

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 dense sentence front-loads the resource and its state fields, then cites the REST endpoint. Every clause carries information; minor cost is that the enumerated field parentheticals make it slightly crowded.

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 burden of describing returns (status, page, controller, preview/park expiry, ended), which is sufficient for a read tool. It stops short of defining possible status values or pagination, but nothing critical for invocation 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 adds real meaning by explaining that taskId is the id of a browser event drawn from muse_chat / muse_get_chat. chatId remains unexplained beyond the schema's terse 'The chatId.'

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 read operation ('the state of a browser the agent opened'), and enumerates the return surface: status, page, controller, watchability, ended. It partly distinguishes itself by tying taskId to browser events from muse_chat / muse_get_chat, but it does not contrast against browser siblings like muse_stop_browser or muse_open_browser_viewer.

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

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

It tells the agent where taskId comes from (a browser event of muse_chat / muse_get_chat), which is genuinely useful usage context. However, it gives no explicit when-to-use-vs-when-not relative to the other browser tools and no prerequisites or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real behavioral value on top: the ~50 s follow budget, what the non-wait path returns (recent messages with files and widgets, chat status, pending permission requests), and the underlying endpoints. It does not discuss auth or rate limits, but nothing here contradicts 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?

Front-loaded with the one-line purpose, then the wait mode, then the default mode, then the endpoints — a sensible ordering with little filler. It is denser than it needs to be (the endpoint strings add little for an agent), but no sentence is wasted.

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

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

There is no output schema, so the description carries the return-value burden and does so for both modes: latest answer (or post-cursor events) for wait, and messages/files/widgets plus status and pending permission requests otherwise. Combined with annotations covering safety, 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 description coverage is 100%, so the schema already documents wait, after, limit, before and chatId, including defaults and bounds. The description restates the wait/after interaction rather than extending it with new format or edge-case 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 ("Read a Muse chat") and immediately splits the behavior into the wait and non-wait modes, which lets an agent tell it apart from write-oriented siblings like muse_chat, muse_cancel_chat, or muse_delete_chat. It stops short of naming a sibling directly, so the differentiation is inferential rather than explicit.

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

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

Gives explicit when-to-use guidance for the streaming path — "use this to get the rest of an answer still running" — and ties the after parameter to that scenario. It also implicitly frames the no-wait path as the general read case. What is missing is any explicit exclusion relative to siblings (e.g. when to prefer muse_list_chats or a poll loop instead).

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), yet the description adds real value beyond them: the ~50 s wait ceiling, the status lifecycle, and the fact that 'history' is slower for troubleshooting. It omits what happens if the job is still running when the wait window expires.

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

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

One dense but tightly front-loaded paragraph that leads with the action and resource, then the wait behavior, then the endpoint. Every clause carries information; only the trailing 'GET /jobs/{jobid}.' is arguably 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 correctly takes on the burden of describing return values (status lifecycle and result file fields) and documents the two optional flags. The only gap is timeout/edge-case behavior when a job never finishes during the wait window.

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 spelling out what a completed job yields (assetId, download url, small-image previews) and by framing 'wait' as a bounded ~50 s hold. 'history' is given no extra explanation in the description.

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

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

States a specific verb ('Read') and resource ('an image or video job by jobid'), plus the three status values it can return. 'By jobid' implicitly distinguishes it from the sibling muse_list_jobs, so an agent can route correctly 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?

Gives clear usage context: jobids come from muse_generate_image / muse_generate_video, and 'wait: true' is the mode for waiting on a running job. It does not state when NOT to use it (e.g., polling multiple jobs vs. muse_list_jobs), so it stops short of full alternative routing.

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, open-world, so the safety profile is covered. The description adds genuine value beyond them by describing what data is surfaced (defaults by category, per-site/per-action rules, permissionId, allowed modes), which is behavioral context the annotations don't 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?

One dense sentence that front-loads the action and resource, then unpacks the returned structure, ending with the route. 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?

No output schema exists, so the description carries some burden of describing return content, and it does so reasonably (defaults, per-rule modes, permissionId). It omits pagination or format details, but for a read-only inspection tool with full annotations this is close to 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?

With a single parameter at 100% schema description coverage, the schema already fully documents 'email' (including its optional-when-single-account behavior). The description only echoes it via the GET path template and adds no new meaning, 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?

The description states a specific verb (Read) and resource (the agent's permission settings on a Muse account) and enumerates the concrete contents: web/connector defaults plus per-site/per-action rules with permissionId and allowed modes. This lets an agent distinguish it from the set/delete permission siblings at a glance.

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 read-only framing, but there is no explicit when/when-not guidance and no naming of alternatives like muse_set_permission_rule or muse_set_permission_defaults (e.g., 'call this before modifying rules'). The context is inferable but not 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 cover read-only, idempotent and safe semantics, and the description adds genuinely useful context beyond them: quota figures are 'as stored at readAt' rather than live, and it exposes the backing endpoint GET /accounts. It stops short of noting pagination or rate limits, which for a list endpoint would be the remaining gap.

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

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

Front-loaded with the action and returned fields, then a one-clause disambiguation, then the endpoint. No filler sentences; the dense field list is informative 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 input params and no output schema, the description must carry the return-value burden, and it does so by enumerating the salient per-account fields. It does not describe the overall response shape (e.g. list vs map, or account identifiers), a minor remaining gap for a schema-less list tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The text also confirms the only implicit input, the API token scope, is what determines the result set.

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 (list the Muse accounts for this API token) and enumerates the per-account fields returned (health, maxJobs, session expiry, weekly usage/top-up with readAt). It explicitly contrasts with muse_get_account, so an agent can distinguish it from the sibling 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?

Names the alternative tool and the condition that selects it: muse_get_account reads one account live, whereas this returns the stored snapshot for all accounts. The choice between the two is unambiguous.

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 cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower; the description adds genuine context by disclosing that results span all chats and include both pending and recently decided requests. It does not discuss pagination or rate limits, but that is minor against the annotation coverage.

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 resource and scope, with the routing hint following. Ends with a compact endpoint reference that adds minor verification value; nothing is padded.

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 list tool with no output schema, the description supplies scope, the answering workflow, and the endpoint, which is enough to call it correctly; annotations carry the safety profile. Return-field details are only partially covered (chatId/approvalId named, others implied).

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 all three parameters (email, limit, status) are documented with defaults and enum meaning in the schema itself. The description adds no syntax or semantics beyond the schema, 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 (List) and resource (the agent's permission requests/approvals) plus scope (across all chats, pending and recently decided). It is clearly distinguishable from sibling muse_answer_approval, which it names as the answering counterpart.

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 pending case to muse_answer_approval and tells the agent which identifiers (chatId, approvalId) to use, giving clear context for what to do with the results. It stops short of stating when-not to call this versus other read siblings, so it is strong but not fully enumerated.

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 mark this as a safe, idempotent read, but the description adds useful behavior: items are newest first, each has type/name/assetId, assetId may be null for undownloadable kinds, and assetIds can be used in jobs/chats or downloaded via url. It does not mention pagination behavior or authentication needs beyond what the schema provides.

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

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

The description front-loads the core listing action and asset categories, then adds return-item and usage details without filler. Every sentence contributes useful information, with the final endpoint note being brief.

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 annotations covering safety and a fully documented schema, the description supplies substantial return-value context despite the absence of an output schema. It is nearly complete, though it omits pagination guidance and explicit 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 coverage is 100%, so the schema already documents each parameter. The description adds some meaning by enumerating asset types and origin categories, but it does not explain email, limit, or cursor behavior, so it remains at the baseline level.

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?

State a specific verb and resource: 'List the Muse Library of an account,' and enumerates the asset kinds included. It is clear what the tool returns, though it does not explicitly contrast itself with siblings such as muse_list_files or muse_search_files.

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

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

The description explains what is listed but gives no explicit when-to-use guidance or alternatives. It does not say whether to prefer this over muse_list_files, muse_search_files, or muse_get_asset, nor does it note pagination context beyond the schema.

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, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: ordering ('newest first') and the shape of each item (title, snippet, status values). It stops short of describing pagination behavior or rate limits.

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

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

One sentence plus a compact endpoint tag; the scope, ordering, and returned fields are all front-loaded with no filler. 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, the description usefully compensates by naming the returned fields and ordering, and the schema fully covers parameters and pagination. Only minor gaps remain (no mention of total counts or next-cursor semantics), so it is nearly complete for a read-only list tool.

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

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

Schema description coverage is 100%, so all three parameters (email, limit, cursor) are already documented with defaults and ranges. The description adds only the loose phrase 'on an account', which does not extend parameter meaning beyond the schema. 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 ('List the Muse chats on an account') and goes further to name the returned fields and sort order, which clearly separates it from the single-chat sibling muse_get_chat. An agent knows exactly what this returns 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?

The listing purpose implies when to use it (browse an account's chats, paginate with cursor), but there is no explicit when/when-not guidance or named alternative against siblings like muse_get_chat. Usage is inferable 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: it discloses the exact fields returned and that media files carry an assetId, which matters because 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?

One well-formed sentence front-loads the action and scope, followed by a terse endpoint note. The trailing 'GET /files.' is low-value implementation detail but does not bloat the definition.

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, describing the returned fields is the right compensation, and annotations cover the safety profile. The main omission is any signal about filtering, pagination, or how this relates to sibling listing/search tools.

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

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

Schema coverage is 100%, so both parameters are already documented, and the baseline is 3. The description adds only the framing of the workspace as 'the agent's computer' and the default-workspace behavior, which is marginal added meaning.

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

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

States a specific verb (list) and resource (a workspace folder or single file), and enumerates the returned fields, so the agent knows exactly what it gets back. It does not name or distinguish itself from close siblings like muse_search_files or muse_read_file, which keeps it 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?

The description implies browsing a directory listing but gives no when-to-use guidance, no prerequisites, and never mentions the alternatives (muse_search_files for filtered lookup, muse_read_file for contents). An agent must infer the routing decision entirely on its own.

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. The description adds meaningful scope context beyond that: only currently running jobs are returned (not historical), and the response includes per-account saturation against maxJobs, which is a useful signal an agent can act on.

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 covering scope and return content, plus the endpoint reference 'GET /jobs.' Nothing is padded, though the trailing endpoint note is marginally redundant for an agent that only needs selection semantics.

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 usefully compensates by naming what comes back: running image/video jobs plus per-account running counts against maxJobs. With zero inputs and safety fully covered by annotations, an agent has enough to call it correctly; pagination or result-size behavior is the only unaddressed area.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to document. The description's mention of maxJobs describes response content rather than input, which is harmless.

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 (List) and resource (image and video jobs running now), and further specifies what is included beyond the jobs themselves (each account's running count against maxJobs). This clearly separates it from the singular muse_get_job, though it never names that sibling explicitly.

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

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

'Running now' implies the usage context (current-state overview rather than historical lookup), but there is no explicit when-to-use guidance or pointer to alternatives such as muse_get_job or muse_generate_image. The agent must infer that this is the overview tool.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the description only needs to add what they don't say. It does add real context: streams are account-scoped, there is a hard limit, exceeding it produces a 429, and the payload shape (chatId, opened, last seen).

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 dense sentence, front-loaded with what is being listed, then the limit/429 consequence, then the fields. The trailing 'GET /chats/streams' is marginally redundant but cheap and informative.

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

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

With no output schema, the description usefully enumerates the returned fields and explains the limit semantics, which is what an agent needs to interpret the result. It is not missing anything essential for a zero-required-parameter read call.

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

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

Schema coverage is 100% for the single optional 'email' parameter, and the description never mentions it — including the important nuance that it is only needed when the token spans multiple accounts. Baseline 3 applies since the schema carries the parameter on its own.

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 names the resource and its scope precisely: 'the chat streams open on an account right now', with the returned fields and the backing endpoint. It is clearly a report of currently-open streams rather than a general chat listing, though it does not explicitly contrast itself with siblings like muse_list_chats or muse_get_chat.

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 supplies concrete context for when the tool matters — checking usage 'against its limit' before a chat call fails with 429. There are no explicit exclusions or named alternatives, so it stops short of a 5.

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

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

Goes well beyond the annotations by disclosing the single-use nature of the link, the ttl open-window (default 60, capped at 300), the 30-minute session ceiling, and the one-viewer-per-account concurrency constraint. These are non-obvious operational traits the agent would otherwise have to discover, and nothing contradicts the readOnly=false/openWorld=true 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?

Front-loads the core deliverable (single-use live-view link) and its constraints, then appends quality/compression and the endpoint. Dense but nearly every clause carries load; the trailing raw endpoint is the one element that adds little for an agent choosing a tool.

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 explains what the tool returns (a shareable link) plus its TTL and session lifetime, and it covers the concurrency limit. It omits required permissions/authorization context, which is a minor gap for an open-world mutation-style 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%, so the baseline is 3; the description adds genuinely new meaning by framing quality/compression as the 'starting picture quality, changeable in the viewer' and clarifying that ttl is the deadline to open the link, not the session length. It does repeat the 0-9 ranges and defaults already present in the schema, capping the score below 5.

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 concrete verb+resource (opens a live view of the agent's browser via a single-use link) and explains the two modes, so the agent knows exactly what the tool produces. It does not, however, name or contrast sibling tools such as muse_get_browser, muse_release_browser, or muse_revoke_browser_viewers, leaving 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?

Usage is implied through the mode descriptions (view to watch, control to watch and take over with mouse/keyboard), which tells the agent the intended audience and task. But there is no explicit when-to-use/when-not or routing to alternative tools, so the guidance is suggestive rather than directive.

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, openWorld, so safety is covered; the description adds genuinely useful behavior beyond that: the ~200 KB text limit, ~1 MB image limit, and the type+size fallback for other files. It does not mention auth requirements or error behavior for missing/oversized files, keeping it below 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?

A single tightly-packed sentence plus the endpoint, with the core action front-loaded and the size/return semantics following. 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 return-value burden and does so well by explaining text/image/type-size outcomes. It stops short of describing failure modes (missing file, exceeding limits) but is otherwise complete for a simple read tool.

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

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

Schema description coverage is 100%, so both parameters (path and optional email) are already fully documented in the schema. The description adds no syntax or format detail beyond 'by path', 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 (read) and resource (a file from the Muse workspace) scoped by path, and describes the return behavior for each file category. It is clearly distinguishable from siblings like muse_list_files, muse_search_files, and muse_write_file.

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

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

Usage is implied by 'by path' — an agent infers this is the tool to fetch a single known file — but there is no explicit when-to-use guidance and no mention of alternatives such as muse_search_files for discovering a path. Adequate but with a clear gap.

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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value the annotations cannot: it discloses the state transition being performed and the precondition (a prior user takeover) that must hold, though it says nothing about what happens if no takeover occurred.

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, both earning their place: the behavioral purpose first, then the endpoint for implementers. Nothing redundant and the key constraint is front-loaded.

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

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

For a two-parameter, non-destructive, idempotent state-change tool with no output schema, the description covers what it does and when it applies. It omits error/precondition-failure behavior, which is a minor gap given the annotations already cover safety and idempotency.

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% for both required parameters, so the baseline is 3. The endpoint path in the description echoes chatId and taskId but adds no format, sourcing or constraint 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?

The description names a specific verb and resource (give browser control back to the agent) and states the exact triggering condition (after the user took it over in a live view), which cleanly separates it from siblings like muse_get_browser, muse_stop_browser and muse_revoke_browser_viewers.

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 clearly states the situation in which the tool applies (returning control after a user takeover in a live view), which is genuine when-to-use guidance. It does not name alternative tools or state when not to use it, so it stops short of a 5.

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

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=false), but the description goes well beyond them: it enumerates exactly what is destroyed, states irreversibility, documents the two-step confirm handshake including that the first call is a no-op that returns a warning, and gives non-retry guidance on error/timeout with a verification alternative. This is exactly the kind of context annotations cannot convey.

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?

Front-loads the destructive scope and irreversibility, then the usage gate, then the two-step protocol and failure handling, closing with the endpoint. Six sentences, none of them filler — every clause carries either a constraint or a recovery instruction.

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, but the description fills that gap by stating what the first call returns (the warning to show the user) and what a failure implies. For an idempotency-unsafe destructive tool with 2 params, nothing an agent needs to call it safely 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 baseline is 3, but the description adds real semantics the schema does not: confirm must be the account email typed by the user themselves after reading the warning, and omitted entirely on the first call. The safety meaning of the email/confirm pairing is clarified beyond the field descriptions.

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

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

States a specific verb and resource ("PERMANENTLY DELETES everything on a Muse account") and enumerates the exact scope — chats, files, documents, web apps, podcast, memory, name. This distinguishes it cleanly from the many sibling deletion tools (muse_delete_chat, muse_delete_file, muse_delete_asset), which are narrower.

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

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

Explicit when-to-use ("only when the user explicitly asks to reset the account"), an explicit when-not (never fill confirm on your own), and an explicit alternative path after failure (check with muse_get_account or muse_list_chats). It even names the pre-condition that must hold before the second call.

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 destructiveness, idempotency and open-world behavior, but the description adds genuinely new behavioral detail: sessions close within ~15 s and unused links stop working. That timing and post-condition disclosure is meaningful beyond the structured hints, though permissions/auth needs are not addressed.

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: purpose first, qualifying behavior second, with the endpoint as a trailing anchor. Every clause carries information with no 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?

For a destructive two-parameter mutation with no output schema, the description conveys the action, its effect, and its timing well. It omits any mention of who can invoke it or what the caller gets back, but with no output schema that gap is minor.

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 both chatId and taskId are already documented, and the endpoint path in the description only restates where they slot in. The description adds no format or constraint meaning beyond the schema, 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 uses a specific verb and resource ('End every live view of the agent's browser'), clearly stating what the tool does and distinguishing it from the inverse muse_open_browser_viewer. It stops short of explicitly naming siblings, so it is clear but not maximally differentiated.

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 by 'End every live view' — there is no explicit when-to-use, when-not-use, or pointer to alternatives such as muse_release_browser or muse_stop_browser. An agent can infer the intent but gets no routing 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 cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the description's main added value is the recursion behavior — searching the target folder and its subfolders. That is a meaningful behavioral detail, but nothing is said about result ordering, matching semantics (substring vs exact), or pagination behavior.

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

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

Two sentences, front-loaded with the core action and criteria, followed by the invocation constraint and the endpoint. Every clause earns its place with no 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?

For a read-only search tool with full parameter descriptions and an explicit at-least-one-input rule, the definition covers everything needed to invoke it correctly; pagination fields are documented in the schema, and no output schema means return-value detail is not required.

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 adds value the schema does not: although 'required' is empty, the API needs at least one of name or extensions, and the description states this explicitly. It also confirms the folder+subfolder scope of 'path', which the schema only calls 'the folder to search in'.

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

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

States a specific verb (search) plus resource (Muse workspace files) and the matching criteria (part of name and/or extensions, within a folder and its subfolders). It is clear, but it never names a sibling such as muse_list_files to distinguish browsing from searching, so sibling differentiation is left 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?

The line 'Send at least one of name and extensions' gives a real invocation constraint, which is useful guidance. However, there is no explicit when-to-use or when-not-to-use versus muse_list_files or muse_read_file, so the usage context is only implied.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the POST endpoint and clarifies what 'auto_allow' vs 'always_ask' actually govern, but says nothing about auth/permission requirements or the effect on previously configured settings.

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 core action and the constraint. The trailing endpoint path is mildly redundant with the schema but compact; almost nothing is wasted.

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

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

For a small mutation tool with full schema coverage and annotations carrying the safety semantics, the description covers the action, the two settings, the accepted values, and the minimum-argument rule. It omits auth requirements and the treatment of unspecified fields, but no output schema means return values need not be explained.

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 field docs carry most semantics, but the description adds value beyond the schema by stating 'at least one' of web/connectors must be sent even though the schema lists zero required parameters. It also expands 'web' and 'connectors' into their real-world meaning (reaching websites, acting in connected apps).

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 ('Set') and resource ('permission defaults') and spells out the two dimensions being controlled (websites/web and connected apps/connectors). An agent can tell it configures account-level defaults rather than a single rule, though it never explicitly names or contrasts with the sibling muse_set_permission_rule.

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 'Send at least one' instruction gives a real invocation constraint, but there is no explicit when-to-use guidance versus muse_set_permission_rule or muse_get_permissions, nor when-not conditions. Usage is implied at best, leaving the agent to infer the distinction between defaults and per-rule settings.

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=false, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the HTTP shape (POST /accounts/{email}/permissions/{permissionId}) and confirms that only a single rule's mode is touched, but says nothing about required account permissions or what happens if the rule/email is invalid.

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

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

One tight sentence front-loads the action and scope, with the endpoint as a short trailing clause. Slightly redundant phrasing ('to allow, ask or deny — one of the rule's modes') costs it the top score.

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 three-parameter, fully documented mutation with clear annotations and no output schema, the description covers the essentials: what changes, which entity, and the underlying endpoint. Missing only the permission/precondition context an agent would want before calling it.

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

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

Schema description coverage is 100% and the mode enum is fully declared, so the schema already carries the parameter detail. The description merely restates the three modes and the single-rule scope, adding no format or constraint information beyond structured data, which is the baseline 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 and resource: change the mode of one permission rule to allow/ask/deny, and names the enumerating sibling (muse_get_permissions) as the source of the rule ID. It does not explicitly contrast itself with muse_set_permission_defaults or muse_delete_permission_rule, so an agent must infer the single-rule-vs-defaults distinction from the name 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?

The description tells the agent where the permissionId comes from (muse_get_permissions), which implies the read-then-write workflow, but gives no explicit when-to-use or when-not guidance and never mentions the defaults sibling that an agent could confuse this with.

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 only declare the generic safety profile (not read-only, open-world, idempotent, non-destructive); the description adds real behavior: a ~15 s Muse review that can refuse and report specific issues, the public visibility consequence, the required user confirmation, and the idempotent republish semantics. None of that is recoverable from 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?

Four tightly packed sentences, each carrying distinct information (destination, review behavior, idempotency, confirmation requirement), with the outcome front-loaded. Parentheticals add precision rather than 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?

For a one-parameter publish tool with no output schema, the description covers everything an agent needs: what gets exposed, that review may reject with reasons, latency expectations, republish semantics, and the user-consent prerequisite.

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

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

Schema coverage is 100% and the single assetId parameter is already documented as the assetId of a web app. The description reinforces this implicitly ('an asset of type web', 'the current version') but adds no format or lookup detail, 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 (publish) and resource (a web app the agent built, asset of type web) plus the concrete outcome: a public link viewable by anyone, signed in or not. It is clearly distinguishable from the sibling muse_unshare_web_app and from muse_list_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?

Gives clear operating context: publish only after confirming with the user, and re-calling republishes the current version. It does not explicitly name an alternative sibling or state when NOT to publish, which keeps it short of a 5.

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

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

Annotations already declare destructive=true, idempotent=true, and readOnly=false, so the safety profile is covered. The description adds non-obvious behavioral context beyond the annotations: the per-account browser cap of 2, the Queued status for waiting browsers, and the irreversibility of the chat-deletion ordering. It could say more about what state is lost when a browser is stopped.

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

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

The core action is front-loaded in the first sentence and the constraint/ordering caveats follow compactly. The raw endpoint string at the end adds little for an agent that will call the tool by name, but nothing is padded or 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 and only two required params, the agent needs mainly lifecycle and ordering context, which the description supplies (concurrency cap, queued state, stop-before-delete rule). Return/confirmation behavior is not addressed, a minor gap for a destructive operation.

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

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

Schema description coverage is 100% for both required parameters, so the schema already documents chatId and taskId. The description embeds both in the endpoint path but adds no format or sourcing guidance, making the baseline 3 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 ('Close a browser the agent opened') and even names the HTTP endpoint, so the action is unambiguous. It does not, however, distinguish itself from the sibling tool muse_release_browser, which an agent may reasonably confuse with this 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?

Gives explicit when-to-use context (stop one that is no longer needed), explains the concurrency constraint that motivates it (max 2 browsers, new ones queue), and states a hard ordering rule: always stop before deleting the chat, because a deleted chat's browser becomes unreachable.

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 destructive=true, idempotent=true, and openWorld=true, and the description meaningfully extends them by scoping the destruction: only the public link stops working while 'the app itself stays in the Library.' It also discloses the underlying DELETE endpoint, so the agent understands exactly what is and is not removed.

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 clauses with the primary effect front-loaded, the non-destructive scope next, and the endpoint last. No sentence is wasted.

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

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

For a single-parameter tool with no output schema and rich annotations, the description supplies everything needed: the trigger, the resulting state change, what is preserved, and the underlying endpoint.

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

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

Schema coverage is 100% and the single assetId parameter is already documented as 'the assetId of a shared web app.' The description's endpoint template confirms assetId is a path parameter but adds no format or sourcing detail beyond the schema, 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 (stop sharing) and resource (a published web app), and its effect is the exact inverse of the sibling muse_share_web_app, so an agent can distinguish it without opening either schema. The added endpoint 'DELETE /assets/{assetId}/share' reinforces the operation 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 clear context for when to call it — when you want a published web app's public link to stop working — but names no explicit alternative or when-not-to-use condition (e.g., versus muse_delete_asset). The usage is strongly implied rather than spelled out.

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 mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower; the description still adds that no sign-in is required and that only the setting itself is changed, which clarifies the blast radius and auth posture. It does not explain failure behavior for an unknown email or what a successful response contains.

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 action and its scope; nothing is padded. The telegraphic "No sign-in: only the setting changes" phrasing is slightly cryptic, keeping it short of a 5.

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 2-parameter, single-setting mutation with no output schema, the description covers the operation, the range constraint, the endpoint, and the no-auth characteristic, which is enough to call it correctly. It could still note what happens on an unknown email or how success is signalled.

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 both email and maxJobs (with the 1-50 min/max) are already fully documented in structured data. The description restates the maxJobs range and names the POST /accounts payload but adds no format, default, or error semantics 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+resource (change an account's maxJobs) and explicitly scopes it to the image/video concurrency setting with a 1-50 range. It is clearly distinguishable from the read/sibling account tools (get_account, list_accounts), though it never names an alternative outright.

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 sign-in: only the setting changes" hints at a precondition and implies limited effect, but there is no explicit when-to-use statement, no mention of when NOT to use it, and no routing to siblings such as reset_account or set_permission_rule. Usage must be inferred.

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 flag openWorld, non-readOnly and non-idempotent. The description adds genuinely useful behavior beyond that: throughput (~1 MB/s), the 50 MB cap, and the return value (assetId) with how to reference it (image_N/video_N/audio_N). No auth/permission details, but strong coverage.

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, all content load-bearing: formats, size/rate limits, and return value. Front-loaded with the action and source, 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 correctly supplies the return contract (assetId and its downstream use), plus format, size and timing constraints. Nothing needed to call it correctly appears to be 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%, so both 'url' and 'email' are already documented. The description adds context on how the returned assetId is consumed but no extra meaning for the input parameters themselves, 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+resource (upload an asset) and the source mechanism (a public https URL), plus the exact media types accepted. An agent can distinguish this from siblings like muse_generate_image or muse_write_file 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?

The 'from a public https URL' constraint and the media-type list implicitly define the usage context, but there is no explicit when-to-use-vs-alternatives routing (e.g., versus muse_write_file or muse_generate_image). Usage is inferable 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 destructiveHint=true and idempotentHint=true, so the bar is lower; the description nonetheless adds real operational context: existing files are replaced, the size ceiling is 50 MB, and a large file may take about a minute. That latency and limit information is genuinely useful for planning. It does not mention permission requirements or what happens on failure.

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?

Dense and front-loaded: the overwrite behavior and the muse_chat handoff come before secondary details like size limits and the POST /files endpoint. Every clause carries information, though the trailing HTTP endpoint reference adds little for an agent choosing a tool.

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

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

For a five-parameter write tool with full schema coverage and annotations covering the safety profile, the description is nearly complete: it covers overwrite behavior, encoding options, limits, and latency. The one gap is return semantics — there is no output schema and the description never says what the call yields (e.g. the stored path or file id), which the agent needs for the subsequent muse_chat step.

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 five parameters, including the content/contentBase64 split. The description largely restates that split and adds only the 50 MB constraint, which does not map to a single parameter. Baseline 3 is appropriate when the schema carries the weight.

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 (write a file into the Muse workspace) and clarifies overwrite semantics for an existing path. It also names the downstream handoff tool, muse_chat, so the agent understands the write is prep for a chat reference. It stops short of explicitly contrasting with siblings like muse_read_file, muse_delete_file, or muse_upload_asset.

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 a concrete usage scenario — writing a document, data, or code file for the agent to use, then sending its path in muse_chat with an example prompt. That is clear positive guidance with a worked example. It offers no exclusions (e.g. when to prefer muse_upload_asset for binary assets) and no stated prerequisites for the call.

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