Run raw Tcl commands in Vivado and refresh project state, ensuring subsequent automation steps use current context.
Use raw Tcl as an escape hatch, then refresh project context before further actions.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| timeout_seconds | No |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | ||
| summary | Yes | ||
| evidence | Yes | ||
| error_code | Yes | ||
| state_changed | Yes | ||
| recommended_actions | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does 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 does not warn that raw Tcl commands can modify project state, consume arbitrary time, or have side effects beyond what other tools handle. The only behavioral hint is the need to refresh project context, which suggests state may be stale but lacks detail on safety or reversibility.
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 sentence with no filler or redundant phrasing. It front-loads the main action and adds a practical instruction for the next step. It is concise, though the density of meaning is low due to its brevity.
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 this is a raw command execution tool with no annotations and undocumented parameters, the description is insufficient. It does not explain how the command integrates with the Vivado environment, what the output schema represents, or any safety considerations. The presence of an output schema is noted, but the description still leaves critical calling details unspecified.
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 by explaining the parameters. It fails to describe the 'command' parameter format (e.g., that it contains Tcl syntax) or the 'timeout_seconds' parameter and its default behavior. The only clue is 'raw Tcl', which does not document either parameter's semantics.
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 the tool runs raw Tcl, which is a specific action on a clear resource (Tcl commands in the context of the Vivado project). It is distinct from the sibling tools that operate on higher-level workflows like synthesis or bitstream generation. However, it uses the metaphorical phrase 'escape hatch' rather than an explicit verb like 'execute', which slightly weakens clarity.
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 'escape hatch' implies use when other tooling is insufficient, and the instruction to 'refresh project context before further actions' provides a concrete post-condition. However, it does not explicitly name alternatives or state when not to use this tool, leaving the usage boundary 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.