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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds one useful behavioral trait — the lookup happens against the *currently selected* process, not an arbitrary one — but is silent on what happens when no process is selected or when the address doesn't map to any line.

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

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

One tight sentence with the action and scope front-loaded and no filler. Brevity is appropriate, though the same sentence count could have carried the missing session/context prerequisites.

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, and annotations cover the safety profile. What's missing is the session/context prerequisite and the meaning of session_id — meaningful gaps for a two-required-parameter tool with zero schema documentation.

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% for both required parameters, so the description must compensate and mostly doesn't. It implies 'address' is a virtual address, but 'session_id' is never mentioned and its relationship to the 'selected process' is left entirely to inference.

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 ('resolve') plus a precise resource ('virtual address to source lines') with the scope ('selected process') stated. An agent can tell this apart from siblings like rad_get_stack or rad_evaluate, though the description stops short of contrasting them 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?

No guidance on when to prefer this over rad_get_stack or rad_evaluate, and no stated prerequisites (e.g. that a session must be attached and a context selected). 'In the selected process' hints at a precondition but never names it as 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 the non-read-only, non-destructive, closed-world profile; the description adds genuinely new behavioral facts — the call blocks waiting for a debug stop and may pause the target. That pause warning is exactly the kind of side effect an agent needs before calling. It stops short of explaining how timeout or failed attach behaves.

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, action first, hazard second. Nothing is wasted and the key caveat 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?

An output schema exists, so return values need not be described. But for a blocking debugger attach with a required session handle and an undocumented timeout, the definition is thin — it omits the session prerequisite and what happens on timeout or failed attach.

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, but it only glosses 'pid' via 'existing local application PID'. session_id (a required string) and timeout (default 15, units unspecified) are never explained anywhere.

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 ('Attach to an existing local application PID'), which implicitly distinguishes it from rad_launch. It doesn't name a sibling explicitly, but the 'existing' qualifier makes the attach-vs-launch split inferable.

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: attaching to an already-running process. There is no explicit statement of when to prefer this over rad_launch, nor any mention of prerequisites such as needing a session from rad_create_session first, despite session_id being required.

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 destructiveHint=true, and the description usefully clarifies that the default is the non-destructive detach/resume path while termination only happens on an explicit flag — context the annotation alone does not convey. It still omits whether closing is reversible and what happens to session state afterward.

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

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

Two short sentences, front-loaded with the default behavior and the flag semantics; every clause carries information. The unexplained acronym "RAD" is the only mild bloat/inaccessibility.

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 described, and the description covers the key behavioral fork for a destructive close. It is nearly complete, lacking only how to source session_id and what state remains after closing.

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 semantics; it does explain terminate_debuggee (terminates attached processes, default false), which is the non-obvious parameter. However, session_id is left completely unexplained — no mention of where to obtain it or its format — so compensation is only partial.

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: closing the RAD session, and adds the default detach/resume behavior. It is clearly distinguishable from siblings like rad_launch or rad_attach, though it never names them 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?

The two sentences give an implicit decision rule for the terminate_debuggee flag (default detach vs. explicit termination), but there is no guidance on when to close a session at all, or what prerequisites/existing state are needed before calling.

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 state readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that a baseline is returned for rad_wait_for_stop, but it says nothing about whether the call blocks, what happens on an already-running process, or how the expected_run_gen/expected_stop_count guards behave — the most consequential behavior for this tool.

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, so nothing wastes space. The terseness, however, is closer to under-specification than compression — there is room for one more sentence on the guard parameters.

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 no explanation, but the two optional generation/stop-count parameters sit at 0% schema description coverage and are the crux of correctly calling this tool — the description leaves an agent unable to know what to pass or when.

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?

Only session_id semantically flows from the description ("attached processes"), leaving expected_run_gen and expected_stop_count unexplored.

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?

"Resume attached processes" gives a specific verb and resource, and it names rad_wait_for_stop as the downstream consumer, which helps place it among siblings like rad_pause, rad_step and rad_run_to_line. It stops short of explicitly distinguishing continue from those stepping 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?

The reference to rad_wait_for_stop implies a usage pattern (resume, then wait for the next stop), so the context is inferable. But it never says when to choose rad_continue over rad_step or rad_run_to_line, nor any preconditions such as the process needing to be in a paused state.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds that the backend is 'isolated, authenticated headless,' which hints at auth needs and isolation. However, it doesn't explain lifecycle (persistence until rad_close_session), behavior on startup_timeout expiry, or what authentication is required.

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

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

Two tight sentences, with the core action front-loaded and the exclusion immediately after. Every sentence earns its place, though the exclusion could name the sister tool for even sharper routing.

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 needn't be explained. But with 0% schema coverage on both parameters and no mention of them in the description, plus unclear session lifecycle, the definition is only partially complete for a tool whose purpose is to establish a working backend.

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% — the two parameters (name, startup_timeout) have only titles and defaults, no descriptions. The description does not mention either parameter, so it fails to compensate for the gap. With two undocumented params, an agent cannot tell what 'name' identifies or what 'startup_timeout' measures.

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 an isolated, authenticated headless RAD backend.' The second sentence, 'Does not start an application,' distinguishes it from rad_launch, though the tool name says 'session' while the description says 'backend,' a slight naming mismatch an agent must reconcile.

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?

'Does not start an application' implies rad_launch is the tool that does, but the alternative is never named explicitly and no prerequisites or when-not conditions are given. Usage is only implied, not stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the meaningful precondition that the process must be stopped and hints at cache/epoch evidence in the result, but it says nothing about what happens when the guards mismatch or what errors/messages can surface.

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 no filler. The phrase 'explicit cache/epoch evidence' is jargon-heavy but carries real 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?

An output schema exists, so return values need not be explained, and the description does signal what comes back. However, for a 4-parameter tool with zero schema coverage and two optional concurrency guards, leaving their purpose undocumented is a material 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 compensate and does not: it never mentions expected_run_gen or expected_stop_count, whose guard semantics are entirely opaque and could cause confusing failures if misused. Only 'expression' is indirectly conveyed by 'RAD read expression'.

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 ('Evaluate') and a specific resource ('RAD read expression') with a scope qualifier ('while stopped'), which distinguishes it from siblings like rad_get_state and rad_get_stack that also surface values. It does not name a sibling or contrast explicitly, so it falls just short of 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?

'while stopped' implies the precondition, which is useful, but the description never says what to do if the session is not stopped (e.g., call rad_wait_for_stop first) or when to prefer this over rad_get_state. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds the meaningful detail that at most 128 backend frames are returned, which constrains expectations, but says nothing about pagination behavior or ordering.

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

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

Two sentences, front-loaded with the core action and zero filler. Every clause carries information.

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

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

An output schema exists, so return values needn't be described. However, with three undocumented parameters and an unstated session/thread prerequisite, an agent lacks enough to call it correctly without inspecting the schema.

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

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

Schema description coverage is 0%, so the description must define 'count', 'start', and 'session_id'. It explains none of them; 'at most 128 backend frames' vaguely hints at a cap on 'count' but never clarifies 'start' as a pagination offset or that 'session_id' identifies the debugging session.

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

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

States a specific verb (read) and resource (native call stack with symbol names and source locations), plus a hard cap of 128 backend frames. It doesn't explicitly differentiate from siblings like rad_get_state or rad_evaluate, but 'call stack' is distinct enough to route an agent.

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?

'Selected thread' implies a prerequisite (a context must be selected, likely via rad_select_context) but this is never stated explicitly. No when-to-use/when-not guidance or alternatives are named, so usage is only implied.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the extra burden is low. The description adds that stack/module lists are 'full' and optional, hinting at cost, but does not say how expensive they are or when the extra data is warranted.

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 primary payload front-loaded and the optional extras second. Minor ambiguity in 'local names' costs a point but there is 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-value format need not be restated. However, with zero schema description coverage, the definition should still clarify which session_id to supply and what the optional flags do; neither gap is closed.

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 does so only partially: 'Optional full module/stack lists' loosely maps to include_modules/include_stack but never names them, and session_id — the required parameter — is entirely 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?

Specific verb 'Return' plus an explicit enumeration of the state fields (run_gen, stop_count, stop reason, processes, threads, local names). It is distinguishable from rad_get_stack and rad_list_processes by being a combined snapshot, though it never names those siblings to sharpen the boundary.

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 statement of when to call this instead of rad_get_stack, rad_list_processes or rad_evaluate, and no prerequisite context (e.g., that the session must be stopped). Usage is only inferable from the returned fields.

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 establish that this is not read-only, not destructive, and closed-world. The description adds useful behavior: args are passed as a list with no shell, and execution stops at entry by default. However, it omits session prerequisites, timeout behavior, working-directory handling, and what debug_subprocesses changes.

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, front-loaded sentences with no filler. It states the core action first and then supplies important execution semantics.

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

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

For a seven-parameter launch tool with zero schema coverage, the description is too sparse. It does not explain the required debug session, timeout implications, working directory, or subprocess debugging, though the output schema does relieve pressure to describe return values.

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% across seven parameters, so the description must compensate. It explains only args (a list, no shell) and the default stop_at_entry behavior, leaving program, session_id, timeout, working_directory, and debug_subprocesses semantically 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 clear verb and resource: launch a local x64 executable with PDBs. It implicitly contrasts with rad_attach by using 'launch' rather than 'attach', but does not explicitly name an alternative or clarify the boundary.

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 no explicit guidance on when to use this versus rad_attach or other session-based tools. The only hint is 'Stops at entry by default', which describes behavior rather than selection criteria.

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

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

Annotations already declare readOnly=true, destructive=false, and openWorld=false, so the safety profile is covered. The description does add one useful nuance beyond the annotations — that it returns the real runtime configuration plus observed hit counts, not declared config — but says nothing about session requirements, error behavior, or ordering.

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

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

One front-loaded sentence with no filler; "actual" and "observed hit counts" both carry information. It is close to under-specified rather than over-long, but nothing in the sentence is wasted.

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

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

An output schema exists, so return-shape details are not required, and annotations cover safety. What is missing is scope: the description never states that the listing is per-session (the sole required argument), which is the main thing an agent must know to call it correctly.

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

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

Schema description coverage is 0%, so the description is the only place parameter meaning could be supplied, and it contributes nothing. session_id is required but never mentioned; the description does not say results are scoped to the given debugging session or what happens with an invalid/ended session.

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: "Read actual RAD breakpoint configuration and observed hit counts." It is clearly a read/list operation, distinguishable in spirit from rad_set_breakpoint and rad_remove_breakpoint, though it never names those siblings or states that it returns the full list.

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 it should call this to inspect breakpoints rather than mutate them. There is no explicit when-to-use statement, no mention of prerequisites (e.g. needing an active stopped session), and no routing away from rad_get_state or rad_set_breakpoint.

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, destructiveHint=false and openWorldHint=false; the description's 'local Windows' wording corroborates the closed-world scope but adds little. It says nothing about ordering, whether all processes are returned, or how the name_contains filter changes 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?

Two short sentences, front-loaded with the resource and return fields, followed by the one actionable constraint. 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?

Output schema and annotations carry the return shape and safety profile, so the description needn't cover those. However, for a tool with a filtering parameter, omitting any mention of filtering leaves an agent unaware of a capability it can use.

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 is one optional parameter (name_contains) with 0% schema description coverage, and the description never mentions that filtering is possible or how it matches. Because the schema provides no semantics, the description was the only place to explain this and it 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 set: list local Windows PIDs, executable names and parent PIDs, so the agent knows exactly what comes back. The phrase 'before attaching' distinguishes it from the mutation/attach siblings, though it never names rad_attach or rad_list_sessions 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?

'Select the exact application PID before attaching' gives a clear usage context and sequencing constraint. It does not state exclusions or name the alternative tools, so it stops 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The word 'active' adds real behavioral context beyond annotations — closed or terminated sessions are excluded from results — and 'this MCP service's' scopes the result set to server-owned sessions. It does not say what happens when no sessions exist or whether results are ordered/paginated.

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. The scope qualifier is placed before the noun it modifies, so an agent reads the key constraint 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. For a zero-parameter list tool the description is nearly sufficient; only the expected empty-result behavior and any tie-in to session-handle-consuming siblings like rad_attach are 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 tool takes zero parameters, so there is nothing for the schema or the description to disambiguate. Baseline 4 applies; no parameter guidance is needed or missing.

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 ... active debug sessions.' That is clearly distinct from rad_create_session and rad_close_session, and from rad_list_processes, which returns processes rather than sessions. It stops short of explicitly naming a sibling it might be confused with, so a 4 rather than 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 statement of when to call this versus alternatives (e.g. before rad_attach or rad_select_context to find a session handle), and no prerequisites or exclusions. Usage is only inferable from the verb 'List.'

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 this is not read-only, not destructive, and not open-world. The description adds useful context about symbol and memory coverage depending on the dump and matching PDBs, but does not explain what happens on failure or what state changes occur in the session.

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

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

Two tightly written sentences with the core purpose and key limitation front-loaded. No wasted words.

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 described, and annotations cover the safety profile. However, with zero schema coverage on three parameters and no mention of timeout or path, the description is incomplete for 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%, and the description only hints that session_id must refer to an empty session. It does not explain the path parameter (presumably the dump file path) or the timeout parameter, leaving key invocation details 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 (load) and resource (local native crash dump) and clarifies it must be in an empty session, which distinguishes it from siblings like rad_attach or rad_launch. It does not name siblings explicitly, but the purpose 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?

The phrase 'in an empty session' implies a precondition and hints at when to use this over other session-opening tools, but there is no explicit guidance on alternatives or exclusions. An agent must infer that rad_create_session is needed first.

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 establish this is a mutating (readOnlyHint=false) but non-destructive, non-open-world operation. The description adds genuinely useful behavior: it blocks and returns only after the stop event occurs, which is not visible in the annotations. However, it never says what happens if the wait exceeds the default 10s timeout or whether the pause is resumable.

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. It is efficient, though arguably underspecified rather than concise given the unresolved timeout and session semantics.

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

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

An output schema exists, so return values need not be described. Still, for a blocking, session-scoped debugger operation with 0% parameter documentation, the agent lacks necessary facts: timeout behavior, required session state, and the distinction from rad_wait_for_stop.

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 full responsibility for the two parameters, and it names neither. The word 'wait' hints at the blocking semantics of timeout but gives no default, units, or behavior on expiry, and session_id's role is entirely unstated.

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 (pause) and resource (running processes) plus the follow-on effect (waiting for the resulting stop), which is more informative than the tool name alone. It does not distinguish itself from the adjacent rad_wait_for_stop or rad_continue, so an agent must infer the boundary from names.

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, when-not-to-use, or alternative guidance. Nothing tells the agent how this differs from rad_wait_for_stop (which also waits for a stop) or when to prefer rad_continue/rad_step, nor what session state is required beforehand.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is partly covered. The description adds the meaningful constraint that only session-scoped IDs are valid, but says nothing about behavior when the ID is unknown, stale, or belongs to another session, nor whether removal is idempotent.

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

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

Two short sentences, front-loaded with the action and followed immediately by the key constraint. Every clause earns its place and there is 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 no explanation, and the tool is structurally simple. Still, for a mutation with 0% schema coverage the description should mention the failure mode for invalid IDs or point to rad_list_breakpoints for discovering valid IDs — both 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?

Schema coverage is 0% with two required string parameters, so the description carries real weight. 'Breakpoint ID returned by this session' does constrain breakpoint_id's provenance, partially tying it to session_id's scope, but session_id itself is never explained and no format or validation detail is given.

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 ('Remove a breakpoint ID'), which cleanly separates it from rad_set_breakpoint and rad_list_breakpoints. The qualifier 'returned by this session' adds scope but is slightly ambiguous about which operation returns it (presumably rad_set_breakpoint).

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 exclusion 'Does not accept arbitrary config IDs' is a useful when-not-use signal, implying the ID must originate from this session's own tooling. However, it never names the producing sibling (rad_set_breakpoint) or states prerequisites, leaving the positive usage path implicit.

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 establish readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds that execution resumes from the current stop and halts at a line, stop, or exit, but it omits details such as timeout behavior, side effects in the debuggee, and the active-session precondition.

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 wasted wording. It is appropriately concise for the action being described.

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 four undocumented parameters, 0% schema coverage, and a debugger action that can resume target execution, one sentence is not complete enough. The output schema and annotations reduce some burden, but key calling details remain 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 parameter meaning. "Source line" loosely implies file and line, but session_id and timeout are entirely unexplained, and no format, units, or defaults are provided.

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 debugger action: run from the current stop to a source line, another stop, or exit. The verb and target are clear, though it does not explicitly distinguish this from sibling tools such as rad_continue or rad_step.

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 "from the current stop," suggesting the tool applies when execution is paused. However, it gives no explicit when-to-use vs when-not-to-use guidance or named 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 it is not read-only but non-destructive and closed-world. The description adds useful sequencing context and the source of frame indices, but does not explain what selecting context changes, whether it persists, or how expected_stop_count affects behavior.

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

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

Two direct sentences with no wasted text. The prerequisite statement is front-loaded and easy for an agent to act on.

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

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

Output schema exists and annotations cover safety, but the input schema has no parameter descriptions. The description explains the core selection intent and one prerequisite, yet it is not complete enough for all four parameters, particularly expected_stop_count.

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 must carry parameter meaning. It hints at thread_id and frame_index and says frame indices come from rad_get_stack, but session_id and especially expected_stop_count are left 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: select a thread and/or stack frame. It also distinguishes the tool's role by tying it to evaluating locals, which differentiates it from siblings like rad_get_stack and rad_evaluate.

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?

Clearly says to use it before evaluating locals and that frame indices come from rad_get_stack. The prerequisite is explicit, though it does not spell out when not to use it or name alternatives beyond the implied sequence.

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 establish that this is a non-read-only, non-destructive, non-open-world mutation. The description adds a meaningful caveat that setting a breakpoint does not guarantee symbol resolution, which is useful context beyond annotations. However, it does not describe duplicate handling, failure behavior, session state requirements, or side effects, so it remains only adequate.

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 no wasted text. The core action is front-loaded, and the resolution caveat is a valuable second sentence that 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?

The output schema covers return values and annotations cover the safety profile, but the description is incomplete for a six-parameter mutation tool with 0% schema description coverage. It leaves session_id and kind semantics unexplained and provides no usage guidance for selecting this tool over 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?

Schema description coverage is 0%, so the description must carry the burden. It partially maps the three breakpoint modes to file+line, function, and address, but it omits session_id entirely and does not explain the required kind parameter, optionality, or valid field combinations. This is insufficient compensation for six parameters with no schema prose.

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

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

The description names a specific verb and resource: "Configure one breakpoint." It also enumerates the three targeting modes (file+line, function name, address string), which distinguishes it from breakpoint-listing and removal siblings. It does not explicitly contrast with alternatives like rad_remove_breakpoint or rad_run_to_line, 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 description gives no explicit when-to-use guidance, prerequisites, or alternative tools. The note that configuration does not prove symbol resolution is a useful caveat, but it does not tell the agent when to choose this tool over siblings such as rad_run_to_line or rad_list_breakpoints.

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 a non-readonly, non-destructive, closed-world mutation, so the safety profile is covered. The description usefully adds the outcome set (new stop / exit / timeout) and the stopped-and-selected precondition, but says nothing about how stepping interacts with breakpoints or what happens on timeout.

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 front-loaded sentences with no filler; the precondition and outcome come before anything else. Slightly under-sized for the parameter complexity, but that is a completeness issue, not a verbosity one.

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 5-parameter tool with 0% schema description coverage, the description leaves an agent unable to choose the correct 'kind' value or populate the run-gen/stop-count guards. An output schema covers the return payload, but the input side is essentially 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 coverage is 0% for 5 parameters, so the description must carry the load, and it largely does not: the 'kind' enum values (into/over/out vs into_instruction/over_instruction) are only hinted at by 'source/instruction level', and 'timeout', 'expected_run_gen' and 'expected_stop_count' (apparently optimistic-concurrency guards) are never explained.

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 (step) against a specific resource (the selected stopped thread) and names the granularity (source/instruction level). It is distinguishable from rad_continue / rad_run_to_line, though it does not name those siblings explicitly.

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

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

Usage is implied by the precondition 'selected stopped thread', but the description never says when to step versus continue, pause, or run-to-line, and lists no exclusions or alternatives among the many 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 cover the safety profile (readOnly, non-destructive), and the description adds genuinely useful behavioral context: the wait is bounded by a timeout and 'Timeout does not cancel execution', which is crucial for an agent to avoid assuming the target was aborted. It omits what a stop result contains, but an 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?

Three terse sentences, front-loaded with the core action and the important non-cancellation caveat. The final sentence about the baseline is efficient in size but opaque in meaning, so it earns only partial credit.

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, and the non-cancellation caveat is a strong addition. But the timeout figure contradicts the schema default and the baseline/after_run_gen semantics are unexplained, leaving an agent uncertain about the parameters that distinguish this call.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate and largely fails: it mentions a timeout but gives a value (60s) inconsistent with the schema default of 10, and the baseline sentence only vaguely gestures at after_run_gen/after_stop_count without explaining their meaning. session_id is entirely unaddressed.

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 states a specific verb and resource: 'Wait ... for a NEW stop/exit', making the debugger-blocking behavior clear and distinguishable from siblings like rad_continue or rad_get_state. However, the hard-coded '60 seconds' conflicts with the schema's timeout default of 10, slightly muddying the stated scope.

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 'NEW stop/exit' and 'execution baseline' implies it is used after resuming execution (rad_continue) to await the next break or exit, but the description never states this explicitly nor names alternatives like polling rad_get_state. Usage is inferable from context 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.