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

The description goes beyond the annotations by warning about the default 'full' permission that edits files and runs shell commands without asking. It also discloses that the tool blocks until mcode settles and returns only the final result plus stats with session prefixes. These details are not present in the annotations (which only have destructiveHint=true) and provide critical behavioral context.

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

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

The description is somewhat long but well-structured: it leads with the core purpose, then explains the return format and continuation, and ends with a caution. It front-loads the most important information (new task) and avoids redundancy. The caution is useful but adds length; overall it is efficient for the complexity of the 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 complex tool with 8 parameters and no output schema, the description provides essential context: return format (session id and session-key prefixes), blocking behavior, timeout handling (run killed still returns session id), and permission implications. It also explains the transport modes and model parameter. It lacks some details about the output stats structure, but overall it covers the key aspects an agent needs to call and interpret the tool 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 all 8 parameters are already documented. The description does add a small amount of context (e.g., that mcode cannot see the conversation and that cwd is usually omitted), but these are also present in the schema's parameter descriptions. The description does not significantly enhance parameter meaning beyond what the schema provides, so a 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 uses a specific verb ('Start') and resource ('a NEW task in the local MiniMax Code agent'), and clearly differentiates from siblings by stating this starts a new task while continuing later is done with mcode_reply. It also distinguishes from other mcode tools (models, running, send, etc.) by focusing on task initiation.

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 explicitly states when to use this tool (start a new task) and implies when not to (for continuing a session, use mcode_reply). It also gives context about the separate CLI agent and its own context window, which helps the agent decide when this tool is appropriate. However, it doesn't explicitly list alternatives for other scenarios (e.g., checking running sessions).

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?

Beyond the readOnly and idempotent annotations, the description adds useful behavioral detail: no run-side effects, no lock, no waiting, exact JSON fields returned, omitted content, and precise caps. This is meaningful behavioral context that annotations alone would not 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?

The definition is dense but concise: it front-loads the purpose and safety properties, then gives the return shape and caps. Every sentence carries information, and there is no filler or repetition.

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 present, the description properly returns to the return shape (session, state, items, cursor, hasMore, truncatedTail), caps, and omissions. That is enough for an agent to decide when and how to invoke the 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 already high, but the description goes further by explaining the cursor can resume at current EOF, note that filtered tool lines still advance the cursor, and the whole-page 100,000-character cap. These details give an agent a more accurate mental model of pagination and limits.

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: 'Read a bounded snapshot of a MiniMax Code session's visible conversation from the native messages.jsonl'. It clearly differentiates itself from sibling tools by stating that it does not send anything into the run, does not take the session lock, and does not wait for mcode to finish.

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 clear context for when to use it: when an agent needs a non-blocking, read-only view of past conversation without interfering with the run. However, it does not name sibling tools explicitly or provide formal when-not-to-use 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it starts no task and may report zero models even when a default model is configured, which prevents misinterpretation of results.

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

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

The description is three tight sentences with no filler. The first sentence states the mechanism, the second states the purpose, and the third states a critical caveat. Every sentence earns its place and key information 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 simple list tool with one optional parameter, no output schema, and annotations covering safety, the description is complete. It tells the agent what command is run, how to use the result, that no task is started, and how to interpret an empty result from OAuth providers.

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 optional `search` parameter, so the schema already documents its meaning. The description does not add parameter-level detail, but it also does not need to; the baseline of 3 applies because the schema carries the param semantics.

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 action ('List what this MiniMax Code installation reports via `mcode provider list --json`') and clear resource (models). It also distinguishes itself from siblings by explicitly saying it is used to pick a `model` value for `mcode` / `mcode_reply`, and clarifies that it 'Starts no task.'

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: use this tool to select a `model` value for `mcode` / `mcode_reply`. It also provides a useful exclusion ('Starts no task') and a caveat about official OAuth providers listing zero models. It does not explicitly name sibling alternatives, but the intended use is well established.

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 signal mutating and destructive behavior, so the description only needs to add context beyond that. It does so by disclosing that sessions survive in MiniMax Code's store, survive server restarts, and are resumable even after timeouts or cancellation. This gives the agent meaningful behavioral expectations without contradicting 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?

The description packs the core action, persistence semantics, and sibling routing into two sentences without fluff. It front-loads the main purpose and only then adds the critical 'not executing' constraint and alternative-tool guidance. Every sentence earns its place.

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

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

For a tool with 9 parameters, no output schema, and several sibling tools, the description covers the essential selection logic and persistence behavior well. It does not explain return values or how the response arrives, but the absence of an output schema lowers that burden. It could slightly expand on side effects or output expectations, but overall it is largely complete for invoking the tool 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 baseline is 3. The description itself adds little parameter-level detail, but that is acceptable because the schema already explains all 9 parameters, including enums and semantics for transport, permission, mode, and timeout. The description's main contribution is tool-selection context rather than parameter explanation.

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 clear verb and resource: 'Send a new turn to an existing mcode session that is not executing right now.' It also explicitly differentiates from siblings, naming both mcode_send for running turns and `mcode` for restarting sessions. This makes the tool's purpose unambiguous.

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

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

The description gives explicit when-to-use context: use when a session is not executing, including timed-out or cancelled sessions, and use mcode_send instead for a turn still running under 'acp'. It also advises resuming rather than restarting with `mcode`, providing a clear decision rule relative to 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?

Annotations already declare readOnlyHint and idempotentHint, so safety profile is covered. The description adds meaningful behavioral context: this is a live snapshot filter limited to acp-transport runs and reachable by mcode_send, plus which fields are included.

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 purpose and scope, followed by the key exclusion and routing to sibling. No redundant wording.

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

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

For a parameterless, read-only listing tool, the description fully enables correct selection and invocation. It states the relevant filter, the returned fields, and the sibling for past data, with output schema not needed.

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?

Tool has zero parameters and schema covers all of them, so the description has no parameter burden. Baseline 4 applies since no parameter ambiguity exists.

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?

Description uses specific verb 'List' with clear resource 'mcode turns executing at this moment' and explicitly bounds scope to 'the ones mcode_send can reach' and 'Only acp-transport runs appear'. This distinguishes it from siblings like mcode_sessions 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?

Explicitly tells when to use: current executing turns, and names the alternative 'For past sessions use mcode_sessions'. The 'Only acp-transport runs appear' exclusion clarifies a key selection condition.

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?

Beyond the annotations' destructiveHint=true, the description discloses meaningful behavior: steer cancels the current turn and submits the message as a new prompt, follow_up is rejected because MiniMax Code ACP has no documented mid-turn queue, and sessions that already finished require a different tool. This gives the agent a clear mental model of side effects and constraints without contradicting 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?

The description is compact and front-loaded, starting with the core action before moving into constraints, unsupported behavior, and related-tool pointers. Every sentence carries necessary information and there is no filler or repetition of schema details.

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 the three parameters, no output schema, and destructive annotations, the description covers the key operational context: when the tool is valid, what happens with each command mode, and how to discover sessions. It does not describe the return value, but for a message-delivery/cancel tool this is a minor gap rather than a blocking one.

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 already covers all three parameters with 100% description coverage, so the baseline is 3. The description adds value by clarifying that message is required for steer and ignored by abort, and that session refers to a running turn listed by mcode_running. This goes slightly beyond the schema without repeating its details.

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 clearly states the tool's action: 'Deliver a message into an mcode turn that is executing right now.' It also distinguishes itself from the sibling mcode_reply by noting that finished sessions should use mcode_reply, not mcode_send. This makes the purpose immediately 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?

The description gives explicit when-to-use context: only for runs started with transport 'acp' and only while the turn is executing. It also names the alternative for finished sessions (mcode_reply) and directs users to mcode_running for reachable sessions. This is strong, actionable guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds sorting, inclusion of running/finished/timed-out sessions, and enumerates the returned fields, which is useful behavioral context beyond 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?

Three compact sentences; the key scope and ordering come first, the returned fields second, and usage guidance last. Every clause adds information with no repetition of annotations or schema.

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 read-only listing tool, it fully states scope, ordering, return-row content, and how the result should be used. It even handles the only likely ambiguity by routing executing turns to mcode_running, so nothing an agent needs 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?

The tool has zero parameters and schema coverage is 100% for the empty schema, so there is no parameter description burden. The baseline for zero-parameter tools 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 ('List') and identifies the exact resource ('mcode sessions started through this server'), including ordering ('newest first') and scope. It also distinguishes itself from the sibling mcode_running, so an agent can select it confidently.

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 instructs when to use it: to recover a session id for mcode_reply. It also names the alternative tool (mcode_running) for currently executing turns, so the main exclusion case is clearly covered.

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