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

With no annotations, the description carries the full burden and does disclose two important traits: it blocks until streaming finishes (synchronous completion), and it consumes the caller's own session and token quota. It omits failure/timeout behavior and whether the call mutates conversation state, so it is not fully transparent.

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 core action, and the quota/session caveat placed second. Every clause earns its place with 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?

There is no output schema, and the description does state the return value (the assistant reply) plus the blocking nature of the call. Combined with the fully documented schema, an agent has enough to invoke it, though timeout/error outcomes are left unspecified.

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

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

Schema description coverage is 100%, so all five parameters (chat, files, prompt, new_thread, timeout_sec) are already documented with defaults in the schema. The description adds no extra parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Send a prompt to Muse and return the assistant reply'), which clearly separates it from read-only siblings like muse_read_chat or muse_read_last. It does not explicitly name or contrast with the closest alternatives (muse_new_chat, muse_open_chat), so it falls short of a 5.

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

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

Usage is implied — this is the tool you call to actually send a message — and the note about using your own logged-in session is a useful prerequisite. But there is no explicit when-to-use versus muse_new_chat/muse_open_chat, and no stated conditions such as needing to log in first (muse_login).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that results include an "active flag" and which sidebar categories are returned, but says nothing about authentication requirements, ordering, result volume, or pagination.

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

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

Two tight sentences with the core action and scope front-loaded and 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?

For a zero-required-parameter read tool with no output schema, the description covers scope, categories, the active flag, and the optional filter. It is nearly sufficient, with only auth/ordering behavior left unstated.

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 single `query` parameter is already documented as an optional case-insensitive title filter. The description's "Optionally filter by title" merely restates the schema, adding no new syntax or behavior.

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 ("chats in the Muse sidebar"), and enumerates the three chat categories it covers. It does not explicitly differentiate itself from siblings like muse_read_chat or muse_open_chat, so it falls short of a 5.

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

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

Usage is only implied: an agent can infer you list chats to discover them before opening or reading one, but the description never states when to use this versus muse_open_chat, muse_read_chat, or muse_read_last, and names no alternatives.

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

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

With no annotations provided, the description carries the full burden. It discloses the two observable effects (window closes, profile released), which is useful, but omits whether the call is idempotent, what happens if no window is open, and whether in-flight chat state is lost.

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

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

A single front-loaded sentence with two concrete effects and zero filler. Every word earns its place.

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

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

For a zero-parameter lifecycle tool with no output schema, the description is nearly sufficient: it names both the action and its cleanup side effect. Only edge-case behavior (calling when nothing is open, effect on session data) is missing.

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

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

The tool takes zero parameters, so the schema fully covers the input contract. The description correctly adds no parameter detail, which is the expected baseline for a no-arg tool.

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 ('Close') and resource ('the dedicated Chrome window') and adds the side effect of releasing the profile. It is unambiguous what the tool does, though it never names a sibling or scope condition to differentiate it from the muse_open_chat/muse_chats family.

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 guidance on when to call this versus alternatives, nor any precondition (e.g. whether a Muse session must be active). The agent must infer that this is a teardown step to use at the end of a session.

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

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

No annotations are provided, so the description carries the full behavioral burden. It doesn't say whether this mutates state, requires login/auth, is read-only, is expensive, or whether the dump is stable. The trigger condition is useful but leaves most behavioral context unaddressed for a diagnostics tool with zero annotation support.

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?

It is a single tight sentence with no filler, and the trigger condition is front-loaded after the noun phrase. Nothing is wasted, but structure could more explicitly separate output from condition.

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 diagnostics tool with no annotations and no output schema, the description is thin: it doesn't describe the return shape beyond 'element counts and transcript HTML,' doesn't state auth or environment requirements, and doesn't cover the failure mode it's meant to diagnose in any detail. The schema covers its one parameter, but the description leaves the tool's behavior underspecified.

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

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

The schema documents max_chars fully with a default and a 200000 cap, so coverage is 100% and the description needn't repeat it. The description adds no parameter-level detail beyond the schema, which matches the baseline 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 names a deliverable ('element counts and transcript HTML') and a trigger ('use if selectors stop matching'), so the diagnostic intent is visible. But the verb is a bare label ('Dump Muse DOM') and the tool isn't clearly distinguished from its siblings (muse_status, muse_read_chat) in a way an agent can route on. Purpose is implied rather than stated as a specific verb+resource.

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

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

It gives an explicit use condition: 'Use if selectors stop matching after a Muse update.' That is a clear when-to-use trigger. It doesn't name an alternative sibling to try before or instead, so it stops short of the top band.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the key non-obvious trait: this launches a browser window and blocks waiting for an interactive human Meta sign-in, which is not derivable from the schema. It omits what happens on timeout or failure (e.g., error vs. status return), so it is not fully complete.

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 followed by the usage condition; 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, no-output-schema tool, the description covers what it does, its side effect, and when to call it. Only post-call expectations (success/failure signaling, whether it returns login state) are left unstated.

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

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

The single parameter timeout_sec is already fully documented in the schema (100% coverage), including default and bounds. The description's 'wait for sign-in' phrasing implies blocking behavior but adds no format or default detail beyond the schema, 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 action (open muse.ai in the dedicated Chrome window) and its outcome (wait for Meta sign-in), so the agent knows exactly what the tool performs. It is clearly distinguishable from siblings like muse_status, which it references by name rather than duplicating.

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 trigger condition: 'Use when muse_status reports loggedIn=false,' which ties the tool to a specific sibling's output. It stops short of stating when not to use it (e.g., already logged in, or while another login is pending), so there is a small amount of inference left.

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

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

With no annotations, the description carries the full burden. It usefully discloses that download is opt-in and that the chat may be opened first, but it says nothing about authentication/login requirements (muse_login exists), permissions, or what happens when a chat cannot be opened. The side-effect disclosure is helpful but incomplete.

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

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

Two tight sentences with the core action front-loaded and the optional side effect second. Nothing is wasted or buried.

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

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

No output schema and no annotations, so the description should ideally sketch the return shape (e.g., a list of URLs vs. downloaded file paths) and the login/chat prerequisites. It covers the core intent but leaves these gaps for a tool in a larger chat-automation family.

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 three parameters (dir, chat, download) are already fully documented in the schema. The description restates only the optional download behavior and adds no new semantics for dir or chat, 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 (extract image/video/attachment links from a chat) and clarifies what those links are (Muse share links for generated media). That is enough to distinguish it from muse_read_chat or muse_chats, though it never explicitly contrasts itself with any sibling.

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?

"Optionally download them" implies the two modes (link extraction vs. download), but there is no explicit when-to-use guidance, no prerequisites (e.g., must be logged in or have a chat open), and no named alternative for reading chat text. Usage is only inferable.

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

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

With no annotations, the description carries the full behavioral burden; it does usefully disclose the navigation side effect (goes to the home composer). However, it omits auth requirements, whether the current thread is discarded, and any state-change implications, leaving notable gaps for a UI-mutating action.

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

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

A single tight sentence with the core action front-loaded and the clarifying side effect in a parenthetical. No filler or redundant phrasing.

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

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

For a no-parameter navigation tool with no output schema and no annotations, the description conveys the action and its visible effect, which is nearly all an agent needs. Only minor context (auth/state implications) is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline for a parameterless tool is 4. The schema coverage is trivially 100% with an empty property 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 ('Start a fresh Muse thread') and the parenthetical clarifies the effect (navigates to the home composer). The word 'fresh' implies a distinction from siblings like muse_open_chat, but no sibling is named explicitly, so differentiation relies on 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 only implied: an agent can infer you call this when you want a brand-new thread rather than opening an existing one. There is no explicit when-to-use or when-not-to-use guidance, and alternatives such as muse_open_chat or muse_chat are not referenced.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the key stateful effect (opening a chat changes the target for later reads/sends), but it omits other relevant traits such as authentication prerequisites, error behavior when the target is not found, and what the call returns.

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 definition is a single front-loaded sentence with no wasted words. It states the action and its immediate consequence efficiently, with no redundancy or buried information.

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

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

For a simple one-parameter state-setting tool with a rich schema and no output schema, the description provides the essential context: what it opens and how it affects later operations. It is nearly complete, though it could mention prerequisite state such as login or what happens if the chat is not found.

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 fully documents the single 'target' parameter, including the accepted formats (title substring, index, URL, thread id). The description does not add syntax or format meaning beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description pairs a specific verb ('Open') with a specific resource ('Muse chat') and states the resulting scope ('so later reads/sends target it'). It also distinguishes the action from the default behavior by explicitly saying this targets a specific chat instead of the main chat, which differentiates it from sibling operations like muse_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?

The description gives clear usage context: call this when you want subsequent reads/sends to hit a specific chat rather than the main chat. It does not explicitly name alternative sibling tools or state exclusions, but the intended sequencing is clear from the phrase 'so later reads/sends target it.'

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the tool does not send anything and may optionally open a chat first, but omits authentication requirements, return format, pagination behavior, and any side effects of opening a chat.

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

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

Two short sentences with zero waste. The core purpose is front-loaded, and the optional-open behavior follows immediately.

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

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

For a simple two-parameter read tool with complete schema coverage and no output schema, the description is largely sufficient. It could still note authentication or return structure, but those gaps are minor given the tool's low complexity.

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

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

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description adds no syntax or semantic detail beyond what the schema already provides, making 3 the correct baseline.

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

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

States a specific verb+resource: return the messages of a chat, all roles, without sending anything. It distinguishes reading from sending, but does not explicitly differentiate from siblings like muse_read_last or muse_chats.

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

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

Implies usage by saying it returns messages without sending anything and can optionally open a chat first. However, it gives no explicit when-to-use guidance relative to siblings such as muse_open_chat, muse_read_last, or muse_chats.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the operation is non-mutating ('without sending anything') and scoped to the current thread, but it omits auth requirements, what happens if no thread is active, and the exact return format.

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

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

A single front-loaded sentence with no wasted words. The core action and its non-sending constraint are immediately clear.

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

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

For a zero-parameter, no-output-schema getter, the description covers the essential purpose and non-mutating behavior. It could mention the implicit prerequisite of an active thread or authentication, but otherwise it is sufficient.

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

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

The tool has zero parameters, so there is nothing for the description to clarify. The baseline for 0 params is 4, and the description does not introduce any contradictory or missing parameter information.

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

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

States a specific verb 'Return' and resource 'most recent assistant message from the current thread', with a clear scope qualifier 'without sending anything' that distinguishes it from send-oriented siblings like muse_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?

No explicit when-to-use guidance, no prerequisites, and no named alternatives. The phrase 'without sending anything' hints at read-only usage but does not say when to choose this over muse_read_chat or other read tools.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only, side-effect-free probe by saying 'Report whether,' which is useful, but it does not explicitly state that nothing is mutated, whether the check is cached, or how a false result should be handled.

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-written sentence with the three checks parallel and front-loaded. Every clause earns its place and 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?

With no output schema, the description usefully enumerates the three boolean results an agent can expect, which is the key missing piece for a status tool. It stops short of explaining how to act on negative results, but the core is complete.

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

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

The tool takes zero parameters, so there is no parameter documentation burden; the baseline of 4 applies. The description correctly reflects that no input is needed.

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

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

States a specific action (report) and enumerates the exact three conditions checked: browser running, login state, and chat composer readiness. This clearly distinguishes it from siblings like muse_login or muse_open_chat, which act rather than report.

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 – an agent would call this to check state before invoking muse_chat or muse_login – but the description never states when to use it or how it relates to alternatives such as muse_login. No exclusions or prerequisites are given.

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