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

Annotations already flag destructiveHint=true, openWorldHint=true and non-idempotence; the description contributes the useful 'persistent' property and the obligation to clean up, which is the key leak risk. It never explains what the 'options' object controls, what happens if a console is abandoned, or any session/resource limits, so it adds only modest context beyond annotations.

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

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

A single tight sentence that front-loads the action and its cost model ('persistent'), with no filler. It could have used the remaining space to characterize 'options' instead.

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?

An output schema exists, so the returned ID need not be explained, and the cleanup instruction is present. What is missing is any characterization of the only parameter and any warning about accumulating live consoles, which matters for an open-world, non-idempotent resource-creating 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?

One parameter ('options') with 0% schema description coverage and an untyped free-form object. The description says nothing about it, so the agent is left guessing whether it is needed at all or which keys are accepted. Schema coverage is low, so the description needed to compensate and does not.

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 ('Create a persistent msfconsole') plus the return value (its ID), which cleanly separates it from siblings like msf_console_list, msf_console_write and msf_console_read. It does not name msf_console_destroy explicitly, leaving the teardown step implied rather than linked.

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 lifecycle is clear: create, then destroy when finished, which implicitly routes the agent to msf_console_destroy. It stops short of saying when a persistent console is preferable to one-off alternatives such as msf_rpc or msf_module_execute, or when repeated creation is wasteful.

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

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

The description contributes real behavioral content beyond the annotations – the fact that jobs/sessions survive console destruction is a consequence an agent could not infer from destructiveHint alone. It stops short of stating irreversibility or whether the console's RPC 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?

Two short sentences, zero filler, with the operation front-loaded and the caveat immediately after. Nothing could be removed without losing 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 one-parameter destructive tool with an output schema and full annotation coverage, the description supplies what annotations cannot: the orphaned-jobs consequence. Adding the source of console_id (returned by msf_console_create) would close the remaining gap.

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

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

Annotations already declare destructiveHint=true, so the mutation risk is covered structurally. The description adds the genuinely useful behavioral caveat that background jobs outlive console destruction, but says nothing about where console_id comes from or its format, and schema coverage for the single parameter is 0%.

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 ('Destroy a console by ID'), which distinguishes it from lifecycle-adjacent siblings like msf_console_create and msf_console_write. It does not name alternatives explicitly, but the second sentence makes the scope of destruction clear enough to separate it from job/process kill tools.

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?

'This does not stop its background jobs/sessions' implies an agent should reach for a different tool (msf_process_signal, msf_jobs) when the goal is to terminate work, but no sibling is named and no precondition (e.g. console must be idle or already created) is stated. Usage is inferred rather than directed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description's only added behavioral signal is that each console's busy state is included in the result, which is a small but real addition; nothing is said about ordering, scope, or how many consoles might be returned.

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 short sentence with the resource and the return detail front-loaded. Nothing is wasted and nothing needs reordering.

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 an output schema present (so return shape needn't be described), zero parameters, and read-only annotations, the description covers the essentials. The only thin spot is that it doesn't position the tool as the entry point in the console lifecycle alongside its five console siblings.

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 explain; baseline 4 applies. The description correctly does not invent filtering options that the schema does not support.

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 ("List") plus resource ("consoles") with an added detail about what is returned ("busy state"). It is clearly distinguishable from write/read/destroy siblings, but it never names the console family or explains the relationship to msf_console_read or msf_console_create.

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

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

No when-to-use guidance, no prerequisites, and no mention of the sibling tools that a listing naturally precedes (msf_console_read, msf_console_write, msf_console_destroy). The agent must infer that this is the discovery step before operating on a specific console.

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

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

The description explains the non-obvious destructive semantics that the annotations flag: reads drain the output buffer, which justifies destructiveHint=true and idempotentHint=false. It also clarifies that busy=false is not a completion guarantee, adding real behavioral context an agent could not infer from structured fields alone.

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 purpose and return fields front-loaded, followed by the operational caveat. No waste.

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 an output schema present and rich annotations, the description covers purpose, drain behavior, and the busy-status pitfall well. The only real omission is how to obtain console_id, which slightly undercuts completeness for a one-parameter tool.

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

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

Schema description coverage is 0% and the single required console_id parameter is never explained in the description — no format, no indication that it comes from msf_console_list. The description does not compensate for the coverage gap.

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: consuming/draining console output and returning data, prompt, and busy status. It is clearly distinct from siblings like msf_console_write or msf_console_create by the nature of the operation, though it never names an alternative 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?

It warns that busy=false is only a snapshot and not proof a command or job finished, which implies a polling workflow, but it never states when to call this versus msf_console_write or how to sequence it. Usage is 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 destructiveHint=true, openWorldHint=true, non-idempotent. The description adds genuinely non-obvious behavior: console state persistence (selected module, options, workspace) across calls and the default newline append. It doesn't warn that arbitrary commands can be destructive, but annotations carry that.

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, then the state caveat, then the newline default. Nothing wasted, though the gap between the stateful-console note and the tool's own write-only nature could flow more tightly.

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?

Output schema exists, so return values needn't be described. But with destructive, open-world, non-idempotent behavior and 0% schema coverage, the description leaves console_id's origin/semantics and any command-length or rate constraints unaddressed.

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 0%, so the description should compensate. It explains append_newline's default behavior, but console_id is never explained (presumably from msf_console_create/list) and command's relationship to console context is only implied. Partial compensation for the coverage gap.

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: submit arbitrary console commands including multiline scripts. Clearly distinguishes itself from msf_console_read by saying 'This tool only submits input; read output separately', which is exactly the sibling boundary an agent needs.

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 output retrieval to a separate tool and explains that multiline scripts are acceptable. No explicit when-not conditions or mention of msf_console_create/destroy prerequisites, but the read/write split is clearly drawn.

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

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

The annotations already declare this as a read-only and open-world operation. The description adds useful context that it lists a local directory with pagination, but does not describe permission requirements, error behavior, or any other operational traits beyond what is already structured.

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 front-loaded sentence with no redundant or filler content. It communicates the core action, pagination behavior, and intended use efficiently.

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 directory-listing tool with an output schema and read-only annotations, the description is mostly complete. The remaining gaps are mainly around explicit parameter and error semantics rather than overall call comprehension.

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 0%, so the description must carry more weight. It broadly indicates that 'path' is a local directory and that pagination is supported, which maps loosely to limit/offset, but it does not explain parameter semantics in detail.

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

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

The description states a specific verb and resource: listing a local directory, with pagination and a practical purpose of locating scripts and artifacts. It is clear enough to distinguish from file read/write siblings, though it does not explicitly name those alternatives.

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

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

The phrase 'to locate scripts and output artifacts' implies a usage context, and 'pagination' suggests larger directory scans. However, it gives no explicit when-to-use guidance, prerequisites, or alternatives such as msf_file_read for reading an individual file.

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 and open-world safety, and the description adds real value beyond them: output is lossless base64 chunks, pagination is driven by next_offset, and it runs with the MCP host's OS permissions. It doesn't cover EOF or error behavior, but with an output schema present that burden is light.

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 lines, front-loaded with the core action, then usage, then the security caveat. 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 paginated read tool with an output schema and annotations, the description covers action, chunking, continuation, and permission scope. Minor gaps (EOF signalling, path absoluteness) exist but don't block correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It implies offset is a continuation cursor ('continue using next_offset') but never explains max_bytes (chunk size) or the units/limits of either parameter, leaving two of three parameters under-specified.

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 local file') plus the encoding and chunking model, which clearly separates it from siblings like msf_file_list and msf_file_write. It never names a sibling explicitly, so it stops short of the top mark.

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

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

'Use for generated binaries, loot, reports, resource scripts, or modules' gives concrete when-to-use context, and 'continue using next_offset' implies the follow-up call pattern. No explicit when-not or alternative-tool routing is given.

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, openWorldHint=true, and idempotentHint=false. The description adds concrete behavioral context: parent directories and missing files are created, truncate wipes an existing file, chunked writes at offsets are supported, and paths are local to the MCP host. It does not mention overwrite behavior without truncate or concurrency/ordering hazards, but it is informative 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?

The description is front-loaded with the core write action, then adds only high-value operational details: directory/file creation, truncate semantics, chunking, and host-local path interpretation. Every sentence contributes to correct invocation, 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?

Given rich annotations and an output schema, the description covers the critical behavior an agent needs: writing at offsets, chunk sequencing, truncate semantics, file/directory creation, and local path scope. It could say more about overwriting existing bytes without truncate, but the definition is otherwise complete for this destructive file-write 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 0%, so the description must carry the parameter explanations, which it largely does. It clarifies data can be text or the {$binary: base64} object form, offset is a byte offset used with next_offset for chunking, truncate clears the file first, and path is interpreted on the local MCP host.

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

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

The description states a specific verb and resource: writing text or base64 binary data at a byte offset in a local file. It implicitly separates itself from msf_file_read and msf_file_list, and 'local file' plus 'Paths are local to the MCP host' distinguishes it from msf_console_write and msf_process_write, though no sibling is named 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?

It gives useful chunking guidance ('truncate=true ... use only on the first chunk when replacing a file') and explains that successive chunks go at next_offset. However, it does not explicitly say when to choose this tool over msf_file_read, msf_process_write, or msf_console_write beyond the implicit local-host path distinction.

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 and openWorldHint=true, so safety is covered structurally, and an output schema exists. The description adds the useful hint that jobs can be further inspected or stopped via msf_rpc, but says nothing about whether finished jobs are included, whether the listing is scoped to the current session, or how large the result may be.

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 action front-loaded and the follow-up routing second. No filler, no restatement of the tool name beyond the verb+resource needed.

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 zero parameters, an output schema, and read-only annotations, the definition is nearly self-sufficient. The only real gap is the absence of any statement about what a "job" means in this context and how it relates to sibling concepts like sessions and processes.

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. The mention of a "job ID" correctly indicates an identifier is needed for the follow-up msf_rpc calls rather than for this tool, which avoids confusion.

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 running jobs." The scope word "running" is a meaningful qualifier. It does not explicitly distinguish itself from similar siblings such as msf_process_list, 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?

The second sentence explicitly routes the agent to alternatives: use msf_rpc with job.info for details or job.stop to terminate a job by ID. That is concrete when-to-use-another-tool guidance. It stops short of exclusions (e.g., how jobs differ from processes/sessions) and of any stated prerequisites.

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

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

Beyond the annotations (destructive=true, openWorld=true, non-idempotent), the description adds critical traits: execution may keep running after the call returns (async job semantics), how to poll for results, and that binary output is returned as a $binary base64 object. These are behaviors an agent could not infer 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?

Three sentences, front-loaded with the action and return shape, followed by prerequisites and post-execution behavior. 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?

An output schema exists, yet the description still usefully characterizes the return (job/UUID, base64 binary) and the async polling model, which are the highest-risk unknowns for a destructive tool. The main remaining gap is any characterization of the three undocumented parameters.

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 0% and none of the three required parameters (module_type, module_name, options) are described. The description partially compensates by pointing the agent to module.info and module.options to derive valid option values, but module_type/module_name formats and expected values remain unexplained.

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 ('Execute an installed module') plus scope ('with its datastore options') and names the return contract ('job/UUID or output'). This clearly separates it from siblings like msf_module_info, msf_module_search, and msf_jobs.

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 prerequisite ('Inspect module.info and module.options first') and post-call workflow ('Poll job.list, module.running_stats, or module.results using msf_rpc'). It does not explicitly state when not to use it or which sibling handles alternative execution paths, so it falls 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=true and openWorldHint=true, so the safety profile is covered. The description adds the useful note that option schemas come from msf_rpc rather than from this tool, but it provides no additional context about output content, authentication, or error 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 two short sentences with zero waste and the core purpose front-loaded. Its brevity is appropriate structurally, though it leaves substantive gaps elsewhere.

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?

An output schema exists, so return-value details need not be in the description. However, for a tool with two required, entirely undocumented parameters, the description is too thin: it gives no module_type values, module_name format, or invocation 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?

Both required parameters, module_type and module_name, have 0% schema description coverage and no enums. The description does not explain valid module_type values or the expected module_name format, so it fails to compensate for the missing schema 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 uses a specific verb-resource pair: 'Return module metadata.' It also distinguishes the tool from msf_rpc for option schemas, though it does not explicitly differentiate itself from msf_module_search or msf_module_execute.

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 one useful routing hint: use msf_rpc module.options for the option schema. However, it does not state when an agent should choose msf_module_info over sibling tools such as msf_module_search or msf_module_execute.

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 and openWorldHint=true, so the safety profile is covered. The description adds the syntax flavor (keyword filters), which is genuinely useful, but says nothing about result shape, limits, or whether the query engine is substring vs. Lucene-style matching.

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

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

A single sentence with the verb and a worked example, no filler. It is efficient, though quite terse for a tool whose only argument has an unusual DSL.

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?

Output schema exists, so return values need no explanation, and a one-parameter read-only search tool needs little more. The remaining gap is DSL documentation for the query, which is the sole risk for incorrect invocation.

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

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

Schema coverage is 0%, so the description carries the burden for the single `query` parameter. It does give a concrete example ('type:auxiliary name:http'), which is better than nothing, but it doesn't enumerate valid keywords or operators or note that 'name:' matches on path fragments.

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 ('Search Metasploit modules') and names the syntax mode, which clearly separates it from msf_module_info (details) and msf_module_execute (run). It doesn't explicitly name a sibling, but the resource scope is 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?

Usage is only implied: an agent can infer this is the discovery step before msf_module_info or msf_module_execute, but the description never says so or states exclusions. No alternative search tool is named.

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

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

The description adds substantial context beyond the destructive annotation: it explains descendant tracking via ancestry and an inherited ownership marker, PTY release, output deletion, shutdown-time cleanup, and the fact that it does not stop an external RPC daemon. These details materially inform the agent about scope and side effects.

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 action and destructive effects are front-loaded, and the extra sentences about ownership tracking, output retrieval, shutdown cleanup, and RPC daemon exclusion are relevant. It is slightly longer than strictly necessary but not 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?

An output schema exists, so return values need not be explained. For a destructive one-parameter tool, the description covers scope, side effects, preconditions, and an important exclusion; the main remaining gap is how to source or format the process_id.

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 0%, and the description only says 'this process' without explaining the process_id format or where to obtain it (e.g., from msf_process_list or msf_process_start). The single required parameter is named clearly, but the description does not compensate for the missing schema documentation.

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

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

The description states a specific verb and resource: stop a process, stop owned descendants, release its PTY, and delete output. It is clearly distinct from read/write/list siblings, though it does not explicitly name which alternative to use for simple signal delivery.

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 one concrete precondition, 'Retrieve output first', but does not explain when to choose this tool over msf_process_signal or when not to use it. Usage is implied by the destructive close behavior rather than explicitly compared against sibling 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful scope ('owned by this bridge') and notes that exit status is included, but says nothing about pagination, volume limits, or whether exited processes are retained.

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

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

A single front-loaded sentence with zero waste. The scoping constraint appears immediately after the verb, so the agent gets the key qualifier first.

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 an output schema present, return shape needn't be explained, and annotations carry the safety profile. The description's remaining job is scope, which it states, though a note on whether completed versus only live processes are listed would make it fully 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 the baseline is 4. There is nothing for the description to clarify beyond confirming the no-argument nature, which the scope phrase implicitly does.

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 resource ('processes owned by this bridge') and adds the returned attribute ('exit status'), so an agent knows exactly what the tool does. It does not explicitly differentiate itself from siblings like msf_jobs or msf_sessions, which is the only gap.

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 scoping phrase 'owned by this bridge' implies when this tool applies, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is inferable rather than directed.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavior: reads are non-consuming, data is base64 bytes while text is display-only UTF-8, pipe mode separates stdout/stderr, PTY merges them, and timeout/cancellation never implicitly replays or stops the process. This is rich behavioral context that an agent needs to interpret results correctly.

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 tightly front-loaded: the core read semantics appear first, followed by concise notes on data/text representation, continuation, stream modes, and eof. Every sentence adds useful information without waste.

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?

An output schema exists, so the description need not explain return values, and it covers most non-obvious behavioral traits. The main gap is the unexplained max_bytes parameter, which leaves some invocation details incomplete.

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 0%, so the description must carry parameter meaning. It clarifies offset via 'byte offset' and next_offset, and indirectly explains stdout/stderr for the stream parameter, but max_bytes and process_id are not explained at all.

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

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

The description gives a specific verb and resource: read lossless spooled output at a byte offset without consuming it. This clearly distinguishes it from sibling write/close tools such as msf_process_write and msf_process_close.

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 operational guidance: use next_offset to continue reading, and eof means the process exited and the stream has been read. It also explains pipe versus PTY stream behavior. It does not explicitly name alternatives or exclusion cases, so it falls 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 destructiveHint=true, openWorldHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds useful behavioral context that the foreground terminal program is notified, but it does not explain failure behavior or what happens to the foreground process during the resize.

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 filler. It is appropriately sized for a concise action description, even if it omits necessary detail elsewhere.

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?

The core action and notification side effect are clear, and an output schema plus annotations reduce the need to describe return values or safety. However, with three required parameters at 0% schema description coverage and no usage guidance, the definition is not fully complete for a destructive PTY 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 0%, so the schema gives only names and min/max constraints for process_id, rows, and columns. The description does not identify what process_id refers to or explain how rows and columns map to terminal dimensions, adding little 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 ('Resize') and resource ('persistent PTY'), and adds the side effect of notifying the foreground program. It is distinguishable from sibling process read/write/signal tools, though it does not explicitly name alternatives.

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

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

The description offers no explicit when-to-use, prerequisites, or when-not-to-use guidance. It only implies that the tool applies when a PTY's dimensions need changing, leaving the agent to infer that from the verb.

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=false, and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context that SIGINT interrupts native console/IRB work and may exit a standalone tool, going beyond what annotations provide.

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 front-loaded with the core action and uses the following sentences efficiently to list valid signals and one important caveat. It is appropriately sized, with no obvious 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?

An output schema exists and annotations cover the destructive/non-idempotent profile, lowering the description's burden. However, for a destructive signaling tool, it should clarify whether process_id targets a process group or an individual process and what permissions or scope assumptions apply.

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 0%, so the description must compensate. It substantially documents signal_name by listing accepted POSIX signals, but process_id is left unexplained and the phrase 'process group' is not reconciled with the process_id parameter.

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

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

The description states a specific verb and resource: 'Signal the process group' and enumerates interrupt/terminate/kill/stop/continue outcomes. It is clearly distinct from sibling process tools such as msf_process_write or msf_process_close, though it does not explicitly name an alternative.

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 signal list and the SIGINT caveat, but there is no explicit guidance on when to choose this tool over siblings like msf_process_close or msf_process_write. No when-not-to-use conditions or alternatives are stated.

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

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

Annotations already flag destructive/openWorld/non-idempotent, so the description's added value is async behavior ('Returns immediately with process_id'), the lifecycle handoff to the process_* tools, and the isolation note about not sharing daemon sessions/jobs. It does not state the privilege context the child executable inherits or failure behavior, which would matter for arbitrary local execution.

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 core verb and the no-shell constraint, then the highest-value usage distinction. Line breaks split sentences mid-clause and the closing 'cwd and env are optional' is a weak trailing afterthought, but overall it is dense 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?

An output schema exists, so return values need only the 'returns process_id' note, which it provides. However, for a six-parameter tool with zero schema descriptions, the description leaves rows/columns unexplained and does not say whether env replaces or merges with the inherited environment — both 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?

With 0% schema description coverage the description must carry all six parameters. It meaningfully defines argv (literal argv, no shell), terminal (with scenario examples), and touches cwd/env only as 'optional', while rows and columns — the PTY dimensions — get no mention at all despite being tied to the terminal=true path.

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 local executable with literal argv, without a shell') and immediately clarifies scope relative to siblings: it is not a console/RPC session ('These processes do not share the RPC daemon's in-memory sessions or jobs'). An agent can distinguish this from msf_console_create and msf_rpc 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 concrete, actionable routing with parameter values — ['msfconsole','-q'] with terminal=true for interactive PTY/IRB, ['msfvenom','--help'] with terminal=false for exact binary output — and notes other utilities work the same way. It never explicitly names msf_console_create as the alternative when a shared daemon session is wanted, which is the one obvious omission.

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 destructive, non-readonly, open-world, and non-idempotent, while the description adds important behavior: no automatic newline, direct control characters in PTY mode, EOF via close_stdin in pipe mode, and the PTY limitation on closing stdin. It does not cover permissions or errors, but it substantially supplements the annotations without contradicting them.

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 opening sentence front-loads the core action and constraint, and every later sentence adds mode-specific operational detail. There is no redundant restatement of the schema or annotations.

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

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

With an output schema present and annotations covering safety, the description supplies the mode-specific stdin behavior an agent needs to call the tool correctly. The main remaining gap is process_id semantics and lack of sibling routing guidance, so it is complete but not exhaustive.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains data's text/binary form and no-newline behavior and explains close_stdin's EOF role in pipe mode, but it never describes process_id, leaving one of three parameters undocumented.

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

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

The description states a specific verb and target: write text or {$binary: base64} to stdin, and specifies that no newline is added. It does not explicitly contrast with sibling writers such as msf_console_write or msf_file_write, so it is clear but lacks full sibling differentiation.

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 actionable usage context: commands need an explicit newline, control characters can be sent directly in PTY mode, close_stdin=true sends EOF in pipe mode, and PTY stdin cannot be closed separately. It does not name alternatives or state when not to use this tool versus console/file writers.

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 openWorldHint=true, yet the description adds real blast-radius detail: 'can mutate state, execute modules, manage sessions, or stop the daemon.' It also discloses non-obvious operational behavior — timeout 'without retrying a failed action' and the null/false/true auth-token detection logic — that no annotation conveys.

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 examples, then encoding and parameter notes — a sensible information order with no filler sentences. The example list is dense but each entry demonstrates a distinct calling shape, so it earns its space.

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 an open-world passthrough with four parameters and an output schema, the description covers the risky dimensions an agent needs: destructive scope, auth handling, timeout/no-retry, binary and map encoding, and how non-string map keys come back. Only the absence of method-discovery guidance (pointing at msf_rpc_methods) and error behavior leaves a modest gap.

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

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

Schema description coverage is 0%, so the description must carry the load, and it largely does: positional params excluding the auth token, $binary and $map encodings, timeout semantics in seconds with no retry, and authenticated null-vs-false meaning. The only gap is that authenticated=true (force token) is never spelled out explicitly, leaving one of three states inferred.

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 precise verb and resource ('Call ANY Metasploit RPC method with positional arguments, excluding its auth token'), which is far more specific than the tool name alone and clarifies the auth-token handling. The example method names (core.version, module.info, session.list) make the escape-hatch nature concrete. It doesn't explicitly distinguish itself from overlapping siblings like msf_module_execute or msf_sessions, which keeps it from 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 through a list of representative methods and one exclusion ('Use console tools for functionality without an RPC method'), plus the caveat that methods/arguments depend on the installed version. However, there is no explicit routing to msf_rpc_methods for discovery or guidance on when to prefer the dedicated siblings (msf_module_execute, msf_jobs, msf_sessions) over the raw RPC 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 readOnlyHint and openWorldHint, yet the description adds real substance: data provenance (bundled catalog pinned to an upstream commit), the difference between catalog and live source, the caveat that plugins and versions can diverge, and the guarantee that unlisted methods are not blocked for msf_rpc. That is exactly the context annotations cannot express.

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

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

Purpose is front-loaded in the first sentence, mode-selection and caveats follow, and the closing line is a necessary guard against over-reliance on the catalog. Five short sentences, none 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 read-only lookup tool with an output schema (so return values need no explanation), the description covers modes, provenance, and limits of the data. The only gap an agent could stumble on is how query filters results and how limit/offset paginate, which the schema leaves undocumented.

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 0%, so the description carries the burden. It explains framework_root well (pass the installed Framework root to scan source instead of the catalog), but limit, offset, and query get no treatment at all beyond their conventional names, leaving query's matching semantics undefined.

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 three concrete resources ('RPC method names, Ruby argument signatures, and authentication requirements'), and explicitly frames the tool as discovery rather than execution. The closing line about the catalog never restricting msf_rpc calls makes the boundary against the sibling msf_rpc 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?

It clearly states the two invocation modes and their defaults: leave framework_root unset to use the pinned catalog, or pass an installed Framework root to scan source instead. It also warns this is 'source discovery, not a live capability probe' so plugins/versions may differ. It stops short of telling the agent when in a workflow to call this versus msf_rpc, but the context is strong.

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 and openWorldHint=true, so the safety profile is covered. The description adds the useful note that session interaction lives in msf_rpc, but says nothing extra about output shape, staleness, or session states — acceptable given the output schema exists.

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 clauses, zero waste, with the operation front-loaded and the routing hint second. Nothing could be removed without losing 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 params, an output schema, and readOnly annotations, this description is sufficient to call the tool correctly. The only mild gap is not clarifying that sessions include shells and Meterpreter channels.

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?

Zero parameters, so the baseline is 4; there is no parameter semantics to add. The description correctly adds no param noise.

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 ('List sessions') that an agent can immediately distinguish from the sibling CRUD-style tools. It doesn't spell out what a session is (Meterpreter/shell) but the operation itself is 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?

Explicitly routes interaction work to msf_rpc session.* methods, telling the agent when NOT to use this tool. It lacks an explicit 'use this when you want an overview of active sessions' framing, but the boundary 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 already declare readOnlyHint=true and openWorldHint=true, so safety and network exposure are covered. The description adds that the call performs authentication and returns version metadata, but leaves unclear whether auth state is cached for later calls or whether credentials come from server config — and 'authenticate' sits in mild tension with readOnlyHint without being explained.

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

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

A single front-loaded sentence with no filler, appropriate for a no-argument status call. It is arguably over-terse: the 'Authenticate' half is the most consequential behavior and receives no elaboration.

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?

An output schema exists, so return values need no explanation, and the empty input schema is trivially complete. What is missing is the operational context an agent needs: whether calling this establishes auth for subsequent msf_* calls, and whether it is a mandatory first 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It could still note that credentials come from configuration rather than arguments, which would have made the empty schema less surprising.

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 two concrete operations (authenticate, retrieve Metasploit/API version info) with a specific resource, so an agent knows exactly what it returns. It does not distinguish itself from siblings such as msf_rpc_methods or msf_rpc, which also probe server-side capability, so it stops short of a 5.

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

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

There is no explicit when-to-use statement, no mention that this should be called before other msf_* tools, and no named alternative. The word 'Authenticate' only hints at a setup role; an agent must infer ordering and prerequisites on its own.

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