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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=true) by disclosing that cancellation is cooperative, that pending tasks cancel immediately while running tasks only set a flag, and that tight-loop scripts polling may never observe it. This directly reframes what the destructive hint means in practice and warns the caller of a real failure mode.

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 line, and the bulleted cooperative-cancellation semantics are tight and each convey a distinct, load-bearing fact. No padding or repetition of the 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?

With an output schema present, return values need not be explained, yet the description still notes a JSON result string. The non-obvious cooperative semantics and the mcp_cancelled() polling contract are exactly the context an agent needs to call this correctly and warn users about uninterruptible scripts.

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, and it does: task_id is identified as the value returned by execute_idapython, and instance_id/port are described as optional overrides of a default target. It stops short of giving formats or clarifying precedence when both instance_id and port are supplied.

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 ('Request cancellation of a script execution task') and immediately names the sibling that produces the task_id (execute_idapython), so the agent can place it in the workflow without opening the schema. It is clearly distinct from check_task_status and execute_idapython.

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

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

Usage is implied rather than stated: the description ties task_id back to execute_idapython, which signals when you would call this. However, it never explicitly contrasts with check_task_status or states whether cancellation can be requested for already-completed tasks, so the when/when-not guidance is left to inference.

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, destructiveHint=false, and openWorldHint=false, so the safety and side-effect profile is fully covered. The description adds only that the result is a JSON string containing connection status and instance data, which is modest additional 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?

Two short, front-loaded sentences with no padding, and the core purpose leads. The 'Returns: str: JSON-formatted string' block is mildly redundant given an output schema exists, but it costs little.

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 safety, so the description is nearly sufficient for a zero-parameter probe. What it omits is the relationship to list_ida_instances, which is the one thing an agent actually needs to route between these two overlapping tools.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The input schema is empty and consistent with the description.

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

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

States a specific verb+resource: checking whether IDA Pro instances are running and accessible. However, it does not differentiate from the sibling list_ida_instances, and the phrase 'connection status and all instances' actively overlaps with that sibling's apparent job, leaving an agent unsure which tool answers the 'what instances exist' question.

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 list_ida_instances despite the clear functional overlap in the return payload. An agent must infer that this is a connectivity preflight before calling execute_idapython or get_ida_database_info.

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 safety profile is covered. The description adds genuinely useful context beyond that — the task runs in IDA Pro, the status reflects a timeout-exceeded execution, and a completed task carries its result — though it gives no polling cadence or expiry guidance.

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 and usage are front-loaded in the first two sentences, with Args/Returns sections following in a scannable layout. The Returns line slightly restates what the output schema already provides, which is the only wasted content.

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 polling tool with three params, the description covers the trigger condition, every parameter's origin and optionality, and the completion semantics. Return shape details are already handled by the existing output schema, so nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, and it does: task_id is identified as the value returned by execute_idapython, and instance_id/port are explained as optional target selectors that fall back to defaults. It stops short of describing what a non-default instance_id or port implies for routing.

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 ('Check the status of a long-running script execution task') and immediately names the sibling that produces the input (execute_idapython), so an agent can distinguish it from cancel_ida_task or check_ida_connection without opening a 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?

Explicitly states the triggering condition: use when execute_idapython returns a task_id with status 'running' or 'pending' because the timeout was exceeded. This is a precise when-to-use rule tied to a named sibling rather than an inferred one.

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

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

Annotations only declare destructive/not-idempotent/not-read-only; the description goes far beyond, disclosing that code runs in IDA's main thread with full API access, that blocking dialogs freeze the entire task queue, and how timeout/cancellation behave. These are exactly the behavioral traits an agent needs before firing arbitrary code into a host process.

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

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

Front-loads the core action and caveats before the Args/Returns/Examples blocks, and the examples are genuinely illustrative (default instance, by name, by port). It is on the long side and the Args/Returns text restates schema-level detail, but no sentence is 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 a dangerous arbitrary-code tool with a nested params object, the description covers execution context, threading implications, timeout/task_id lifecycle, cancellation helper, output shape (result/stdout/stderr/instance/task_id), and worked examples. Nothing an agent needs in order to invoke it safely is absent.

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 Args section enumerates all six fields (code, script_path, capture_output, instance_id, port, timeout) with their roles, and gives concrete example call forms for instance_id and port. Much of this overlaps the schema's own descriptions, so it adds examples rather than new semantics, but it does compensate for the reported low schema description coverage.

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 Python code or script file in IDA Pro context') and immediately distinguishes itself from siblings by naming check_task_status and cancel_ida_task as its follow-up companions. An agent can tell what this tool does and roughly where it sits in the workflow without opening the schema.

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

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

Gives clear operational context: long-running scripts poll up to `timeout`, timeouts yield a task_id to be resolved via check_task_status, and long scripts should poll `mcp_cancelled()` for cooperative cancellation via cancel_ida_task. It also warns against interactive dialogs. What's missing is an explicit statement of when this tool is preferable to any alternative (none exists among siblings), so it stops just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description only adds that the result is a JSON-formatted string of database information, which is modest added context beyond 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?

Front-loaded one-line purpose followed by compact Args/Returns blocks with no filler. The Args/Returns scaffolding is boilerplate but harmless and short.

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 return shape need not be spelled out, and the single optional parameter is explained. What remains missing is any hint of what 'database information' contains or how it relates to sibling lookup tools, leaving the agent to infer the tool's niche.

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 itself says nothing about instance_id beyond its type. The description compensates by explaining it is optional and that a default instance is used when omitted, which is the key semantic an agent needs.

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 verb and resource ('Get information about an IDA database'), which is enough to know the general intent. However, 'information' is vague and the description does nothing to distinguish this from siblings like list_ida_instances or check_ida_connection, so the agent must guess which metadata call to make.

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 only usage note is that instance_id is optional and falls back to a default. There is no guidance on when to call this versus list_ida_instances or check_ida_connection, and no prerequisites or exclusions 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds contextual details by specifying that it returns a JSON list with ports and database info, including an example response. This goes beyond the annotations by clarifying the output structure and the MCP-plugin filter, but it does not discuss auth or rate limits.

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

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

Front-loads the purpose in the first sentence, then provides a compact return description and example. The example is useful though slightly verbose; overall it is well-structured and earns its place.

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

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

Given the empty input schema, rich annotations, and an output schema, the description is nearly complete. It states the scope, return format, and an example. The main gap is the lack of when-to-use guidance against sibling tools, but for a simple lister this is minor.

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

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

There are zero parameters, so the baseline score is 4 per the rubric. The schema and description need not document parameter meaning.

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

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

States a specific verb (list), resource (running IDA instances), and filter (with MCP plugin enabled). It clearly distinguishes a discovery operation from sibling tools like check_ida_connection or get_ida_database_info, which act on a single instance.

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

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

Provides no explicit when-to-use or when-not-to-use guidance. It does not say when to prefer this over check_ida_connection or that it should be used before attempting to connect. The usage is only implied by the verb 'list'.

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