Checks the isolated managed Revit 2020 worker without launching Revit, reporting its PID, loaded model, and active view so you can verify automation readiness.
Check the isolated managed Revit 2020 instance without launching Revit. Reports the worker PID, model and view. Never connects to an existing manually opened Revit instance.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it declares two negative behaviors (does not launch Revit, will not attach to a manually opened instance) that are exactly the side-effect risks an agent would worry about. It also names the return fields. It stops short of describing failure behavior when no managed instance is running, which is the main remaining unknown.
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 core action and scope, followed by the concrete reported fields and the key exclusion. 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?
For a zero-param, no-output-schema status tool, the description covers what it reads, what it returns (worker PID, model, view), and what it will not touch. Only the behavior when no managed instance exists is left unstated.
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 are no semantics to explain; the description correctly adds no param noise. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb (check) and a precisely scoped resource (the isolated managed Revit 2020 instance), then names the fields reported. This is more precise than the bare tool name implies, though it doesn't explicitly contrast with get_revit_operation_result, which an agent might confuse with a status check.
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 "without launching Revit" and "Never connects to an existing manually opened Revit instance" – the agent can infer this is a safe probe of the managed instance rather than an action on the user's own session. There is no explicit statement of when to prefer this over the sibling get_revit_operation_result, so the agent must infer the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.