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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names the operation and the input source; it does not describe side effects, whether existing attachments are replaced, failure modes, or how the debugger session state changes. For an action that modifies debugger state, this is a significant gap.

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 concise sentence with no filler and the key semantic information is front-loaded. It is appropriately sized for a tool with one parameter.

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

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

For a simple one-parameter tool, the description is minimally viable: an agent knows what input to provide and where to obtain it. However, it omits contextual details such as requiring an active debugger connection, expected behavior, and any constraints on when attachment is valid.

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 does add useful meaning by identifying targetIds as the IDs returned by list_debug_targets, but it does not explain valid values, cardinality expectations beyond the schema's minItems, or how the IDs are used during attachment.

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 ('attach') and identifies the object ('target IDs returned by list_debug_targets'), making the tool's basic purpose clear. It implicitly distinguishes itself from detach_targets and other debugger sibling tools, though it does not explicitly state that the targets are attached to the active debugger session.

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 'returned by list_debug_targets' implies a clear source for the IDs and suggests basic sequencing after listing debug targets. However, it does not state prerequisites such as having a connected debugger, when to use this over other sibling tools, or what to do if attachment fails.

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?

N annotations are provided, so the description bears the behavioral disclosure burden. It does convey a useful behavior: the server must already exist and no debugger UI is registered. It does not disclose return values, error behavior, or whether any connection state is created, but the 'check' wording reasonably implies a non-mutating operation.

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 one concise sentence, properly front-loaded with the action and resource, and contains no repeated or unnecessary information. For a simple two-parameter tool, this is appropriately sized.

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 annotations and no output schema, the description needs to explain what a 'check' returns or reports, such as success/failure, status details, or error behavior. The current description tells the agent what to call but not what to expect back, leaving important context missing.

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

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

The schema only provides types and bounds for host and port, while the description adds the context that these identify an HTTP debug server. This adds some meaning beyond the schema, but it does not provide any parameter-specific detail beyond that, so the compensation for the 0% schema description coverage 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?

The description clearly identifies the action ('Check') and the resource ('existing 1C HTTP debug server'), and the modifier 'without registering a debugger UI' helps distinguish it from sibling tools like connect_debuger. However, 'check' is somewhat generic and could be more explicit about whether it means availability, connectivity, or configuration status.

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 'existing server without registering a debugger UI' implies the tool is for lightweight verification rather than full debugger attachment. It does not explicitly name alternatives or provide clear when-to-use/when-not-to-use guidance, so the agent must infer the intended scenario.

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

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

With no annotations, the description at least discloses the main side effects: it replaces any active MCP debug session and explicitly never stops 1C. However, it does not cover permission needs, failure behavior, or what happens to the replaced session beyond 'replaces'.

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 with no filler; the core register-for-alias action is front-loaded and the replacement/safety caveat is in the second sentence.

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 side-effecting, no-annotation tool with four parameters and no output schema, the high-level purpose and one caveat are insufficient. An agent still lacks knowledge of return values, failure modes, prerequisites, and sourceRoot's role.

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 maps to 'infoBaseAlias' via 'infobase alias'. host, port, and sourceRoot receive no added meaning, leaving required network/connection semantics 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 action ('register') on a specific resource ('this MCP as debugger UI for one infobase alias'), so an agent can tell it is the tool that establishes debugger registration. It does not explicitly name sibling alternatives, and 'debugger UI' is slightly idiom-dependent, so not 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?

No explicit guidance on when to call it or when to prefer a sibling such as disconnect_debugger, check_debug_server, or set_auto_attach. The replacing/not-stopping sentence is behavioral context, not usage direction.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It does disclose the precondition that the target must be stopped, which is useful context. But it fails to disclose that each action mutates the target's execution state, what happens when the target is actually running or the requested action is invalid (e.g., StepOut with no call frame), or whether these operations are side-effecting and irreversible.

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 zero wasted words: all four actions are front-loaded, and the precondition is appended economically. The listing of four actions is somewhat flat rather than prioritized, but for the content it contains, the structure is appropriately sized and scannable.

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 annotations and no output schema, the description must stand alone, and it leaves significant gaps: where targetId comes from, how to choose among Continue/Step/StepIn/StepOut, error behavior when the target is not stopped, and what the caller observes as a result. The essential action set and precondition are present, but an agent has too little to confidently invoke the tool correctly or recover from invalid 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?

Schema description coverage is 0%, so the description must compensate for the schema's silence — and it doesn't. The description merely echoes the enum action names without explaining what each actually does or when to choose one over another, and it never clarifies what targetId refers to (presumably a target from list_debug_targets or a breakpoint hit). An agent must infer both parameters' practical 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?

The description names four specific debugger-control verbs (Continue, step over, step in, step out) and a clear resource (a stopped target), so an agent can tell this is the execution-resumption/stepping tool. It implicitly distinguishes itself from siblings like suspend_target (the inverse operation) and connect_debugger/attach_targets (connection setup). It falls short of a 5 only because it never explicitly contrasts itself with any sibling.

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

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

The phrase 'in a stopped target' implies the key precondition — use this only when the target is suspended — which is meaningful usage guidance. However, the description gives no explicit when-not-to-use conditions, no alternative tool mentions (e.g., suspend_target for pausing, poll_debug_events to check state), and no guidance on choosing between the four actions.

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

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

With no annotations provided, the description carries the burden of disclosing behavior. It does add one key behavioral guarantee: the operation does not terminate the 1C processes. However, it does not mention side effects such as whether the debugger connection is removed, whether targets remain visible, or what happens to existing breakpoints, leaving some behavioral ambiguity.

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, compact sentence with no filler. It front-loads the core action and immediately adds the key caveat about not terminating processes, making every word earn its place.

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

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

For a simple one-parameter tool, the description gives enough to understand the intended action, but it omits important context such as prerequisites (targets must be attached), expected result or return behavior, and how this differs from disconnect_debugger. Since there is no output schema or annotations, these gaps make the description only minimally 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?

Schema description coverage is 0%, and the description does not explain the 'targetIds' parameter beyond the schema's basic type and constraints. The parameter name is self-explanatory, but no additional guidance is given about where the IDs come from or how they relate to other debugger tools, so the description fails to compensate for the low 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?

The description states a specific verb ('Detach'), identifies the resource ('targets'), and adds a meaningful constraint ('without terminating their 1C processes'). This clearly distinguishes the action from related operations like attach_targets or suspend_target, making the tool's purpose immediately understandable.

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 implies when to use the tool: when targets should be detached while their processes are kept alive. However, it does not explicitly mention alternatives or state when not to use it—for example, when a full disconnect or suspension is more appropriate—so guidance is only implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It clearly discloses the most important behavioral trait: this tool only detaches the UI and does not terminate processes/debuggers. It is somewhat terse and does not describe reconnect behavior or what happens to existing debug sessions, but the core side-effect profile is transparent.

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

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

A single sentence with no filler. The action is front-loaded, and the critical non-destructive qualifier is placed at the end for emphasis. Every word contributes meaning.

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

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

For a parameterless tool with no output schema, this description is largely sufficient: it names the action, the target, and the key side effect. It could be slightly more complete by clarifying what happens to attached targets or how to reconnect, but given the tool's simplicity, the description is adequate.

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

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

The tool has zero parameters, and the schema already reflects that with an empty properties object. The baseline for 0 parameters is 4; there is no parameter-level information the description needs to add.

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 ('detach'), names a clear resource ('the MCP debugger UI'), and states the key non-effect ('without stopping 1C or dbgs'). This distinguishes it from sibling tools like detach_targets, which likely detach debug targets rather than the UI.

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 'without stopping 1C or dbgs' implies the intended use case: disconnecting the debugger UI while preserving the underlying processes/sessions. However, it does not explicitly state when to prefer this tool over siblings such as detach_targets or connect_debugger, nor does it mention exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does warn that 'Expressions may have side effects,' which is a crucial behavioral trait. However, it does not describe what happens on success or failure, whether the target remains stopped, or whether evaluation can change debugger state beyond the side-effects warning.

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, well-structured sentence that front-loads the action and includes a critical side-effect warning. Every word earns its place with no redundancy or 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?

The tool has three parameters, no output schema, and no annotations, yet the description fails to mention the return value, the meaning of stackLevel, or any error-handling behavior. For a debugging tool that can have side effects, this leaves significant gaps for an agent attempting to invoke 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 must compensate, but it only indirectly references 'expression' and 'target.' It adds no meaning for the required targetId or the optional stackLevel parameter, leaving agents to infer their purpose from the schema alone.

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 ('Evaluate') and names the resource ('1C expression') plus the required condition ('in a stopped target'). This clearly identifies the tool's function and distinguishes it from sibling debugger tools such as get_local_variables and continue_or_step, which perform different operations.

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 a stopped target' implies the tool should only be used when the debugging target is suspended, giving some usage context. However, it does not explicitly state when not to use this tool, nor does it name alternatives for evaluating expressions in other states or for read-only inspection (e.g., get_local_variables).

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It states the action is a read operation, but does not say what happens if the target is not stopped, whether an invalid targetId produces an error or empty result, or whether auth/state requirements exist. This is a moderate gap given the lack of 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 a single, front-loaded sentence with no redundant words. It immediately states the verb, the resource, and the required state of the target, which is appropriately concise for such a simple tool.

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

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

The tool is simple: one required parameter, no nested objects, and no output schema. The description covers what the tool reads and the condition required to use it. It could be more complete by explaining failure behavior or the return format, but for a straightforward getter among many debugger tools, it is largely sufficient.

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

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

Schema description coverage is 0%, so the description must compensate, but it only mentions 'a stopped target' without explaining that targetId identifies the debug target whose stack is read. The schema itself provides only minLength, so the agent receives minimal semantic guidance about the parameter beyond its name and type string. This is insufficient for a tool with no other parameter 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 uses a specific verb (Read) and a clear resource (the call stack), and scopes it further to 'a stopped target.' This clearly distinguishes the tool from siblings like get_local_variables or evaluate_expression, which target different debugger data.

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 'of a stopped target' is an implicit but strong usage condition: the tool is only meaningful when the target is stopped, not running. It does not explicitly name alternatives or exclusions, but this context is enough for simple routing among the sibling debugger tools.

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

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

No annotations are provided, so the description carries the full burden. 'Read' indicates a non-mutating operation and 'stopped target' gives a precondition. However, it does not disclose behavior for invalid stack levels, missing debug connection, or whether the operation can fail without 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?

A single, tightly worded sentence with no filler. The verb and resource are front-loaded, and every part of the sentence adds meaning.

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

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

With no output schema and no annotations, the description leaves gaps: it does not state the need for an active debugger connection, that a valid stack frame must exist, or what the returned local variables look like. It is a minimal one-liner for a two-parameter tool in a complex debugging context.

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 does not explain the targetId parameter or clarify stackLevel semantics (e.g., that 0 corresponds to the top frame). Only the phrase 'stack level' loosely hints at one of the two parameters, so the description fails to compensate for the minimal 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?

The description names a specific verb and resource: 'Read local variables at a stack level of a stopped target.' This distinguishes it from sibling tools like get_call_stack and evaluate_expression by the resource being returned, 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 'of a stopped target' implies a precondition and when the tool is useful, so usage context is partially conveyed. However, it does not explicitly state when to use this tool over alternatives, nor does it mention connection or suspension prerequisites beyond the target being stopped.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. 'List' implies a read-only operation, but the description does not explicitly state that it does not modify state, whether it requires an active debug server, or what happens when no targets exist. This is minimally adequate but not richly transparent.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes information about what is listed, and the structure is immediately scannable.

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

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

For a zero-parameter list tool with no output schema, the description is largely complete: it names the resource categories and implies the return of a list. It could add a note about prerequisites such as a running debug server, but that is a minor gap given the tool's simplicity.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter information missing. The description adds no parameter-level detail, but none is needed; baseline 4 is appropriate for a zero-parameter tool.

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

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

The description uses a specific verb ('List') and a concrete resource ('current client, server, background-job and other RDBG targets'). It clearly differentiates this from sibling tools such as attach_targets, detach_targets, and poll_debug_events by identifying it as the listing/read tool.

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 guidance on when to call this tool versus alternatives such as attach_targets or check_debug_server. There is no mention of prerequisites, ordering, or exclusions, so an agent must infer usage solely from the tool name and sibling 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?

With no annotations present, the description must carry the full behavioral burden, but it only lists event categories. It does not disclose whether polling is blocking or non-blocking, whether events are consumed/cleared, whether a debug session must be active, or how errors/timeouts are handled.

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

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

A single, front-loaded sentence that wastes no words: it names the action and the exact event types. It is appropriately sized for a parameterless tool.

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

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

For a zero-parameter tool the description is minimally viable, and the listed event types give useful output expectations. However, avoid the lack of annotations and an output schema, it does not explain return format, polling semantics, or call prerequisites, so an agent may still misjudge when to call it and what to expect.

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 input schema has zero parameters, so the baseline is 4 and the description does not need to explain parameter semantics. The absence of parameters is already visible in the schema, and the description correctly avoids adding irrelevant parameter text.

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 ('Poll') and a concrete resource ('target start/quit, breakpoint and step events'), which clearly tells an agent what the tool does. This event-polling role is unique among the sibling tools, so it can be distinguished from debugging actions like continue_or_step or set_breakpoints without opening any 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?

The polling verb implies that this tool is used to repeatedly retrieve debug events after a session is attached, but the description gives no explicit when-to-use guidance nor alternatives. It does not state prerequisites such as requiring an active debugger connection or that it complements action tools like continue_or_step.

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?

There are no annotations, so the description carries the burden. It discloses that resolution depends on exported 1C XML metadata, which is a useful prerequisite, and the verb 'resolve' suggests a read-only lookup. It does not mention side effects, failure modes, or the shape of the returned identifiers.

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 entire definition is one efficient, front-loaded sentence with no filler or repetition. Every phrase contributes the core purpose.

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?

Without an output schema or annotations, the description should clarify return format, parameter roles, and prerequisites. It mentions exported metadata but leaves sourceRoot and the identifier structure unspecified, so the definition is not fully actionable for an agent.

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% and the description does not define either parameter beyond implying sourcePath is a BSL path. sourceRoot is entirely unexplained, leaving an agent uncertain whether it is optional, how it relates to exported metadata, or what format it should take.

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 operation (resolve), input (BSL path), and output domain (RDBG object/property identifiers), and the sibling list shows no other tool performs this translation. Some domain jargon is unexplained, 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?

The description implies when the tool is useful—when an agent has a BSL source path and needs debugger identifiers—but it never states this explicitly or distinguishes it from sibling debugger operations. No alternatives or when-not-to-use cases are mentioned.

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

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only says 'Configure' without explaining side effects, persistence, whether prior settings are overwritten, or any dependency on a running debugger. The list of typical values is useful but does not reveal the operation's 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 a single concise sentence that front-loads the action and resource, followed by a value list. It is efficient with no filler words, though the enumerated list adds a little length without being verbose.

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 that there are no annotations, no output schema, and 0% schema description coverage, the description is not complete enough for safe invocation. It omits important context such as whether the setting replaces existing values, how to disable auto-attach, and what the call returns. The typical values help but do not fill the behavioral and contextual gaps.

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 offers a list of typical values (Client, ManagedClient, Server, etc.), which gives real guidance on expected string content. However, it doesn't clarify whether these are exhaustive, case-sensitive, or how to clear/reset the auto-attach list, leaving some ambiguity.

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: 'Configure RDBG auto-attach target types.' It clearly conveys what the tool does. However, it doesn't explicitly differentiate it from sibling tools like attach_targets, though the scoped resource makes it fairly distinguishable.

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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or compare with siblings such as attach_targets or list_debug_targets. The usage context is only implied by the tool's name and brief description.

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

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

No annotations are provided, so the description must carry the behavior burden. It discloses that breakpoints are set as active and that sourceRoot's XML metadata resolves RDBG IDs, but it does not explain side effects like whether existing breakpoints are replaced, whether a debugger connection is required, or what happens on failure.

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: the first states the action and scope, the second adds the key mechanism. Every word earns its place; no padding or repetition.

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

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

With no annotations and no output schema, the description carries the full burden of explaining prerequisites, return behavior, and failure modes, but it covers none of those. For a debugger mutation tool with three parameters, the description is too sparse for an an agent to call it confidently.

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, but it only clarifies the role of sourceRoot. It does not explain what sourcePath should be or that `lines` are the target breakpoint line numbers, leaving two of three parameters underdocumented.

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?

Uses a specific verb ('Set') and resource ('active breakpoints for one local BSL module'), making the tool's core action unmistakable. It also distinguishes itself from the sibling debugger tools, none of which set breakpoints.

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 'one local BSL module' implies a scope, and the later RDBG-resoultion sentence gives context, but there is no explicit guidance about when to prefer this tool over alternatives or when not to use it. The intended usage is inferable from the tool name and sibling context, not fully 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?

With no annotations, the description carries the behavioral disclosure burden. It clearly states the requested action, the required target state ('running'), and the timing of the stop ('on the next BSL instruction'), which provides useful non-obvious behavior. It does not mention return values or failure behavior, but the core effect is transparent.

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

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

The entire description is one focused sentence with no filler. The verb and key constraint are front-loaded, and every word earns its place.

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

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

This is a simple single-parameter control tool with no output schema and no annotations, so the description is mostly sufficient. However, it omits context about expected target state transitions, error conditions, and how the result is conveyed, which an agent might need to interpret the tool's effect reliably.

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

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

The schema provides no description and coverage is 0%, so the description must compensate. It ties the action to 'a running target,' making targetId's role inferable, but it never explicitly says that targetId identifies the target to suspend. The single self-descriptive parameter makes this adequate but not exemplary.

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 ('suspend'/'request... to stop') with a clear resource ('running target') and a precise condition ('on the next BSL instruction'). This distinguishes it from sibling execution-control tools like continue_or_step and detach_targets.

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 implies the tool is for pausing a running target during debugging, but it does not explicitly say when to use it over siblings or mention alternatives. There is no direct guidance on prerequisites such as an attached debugger.

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