Creates an isolated, authenticated headless RAD backend session for debugging setup without starting an application, so you can prepare a safe session before launch or attach.
Create an isolated, authenticated headless RAD backend. Does not start an application.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | native-debug | |
| startup_timeout | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does 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.