Allows AI assistants to interact with AMD/Xilinx Vivado FPGA development tools, enabling session management, project management, design flow (synthesis, implementation, bitstream), reports and analysis, design queries, and simulation control.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Vivado MCP Server Open my project and run synthesis"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants like Claude to directly interact with AMD/Xilinx Vivado FPGA development tools.
Session Management: Start/stop persistent Vivado TCL sessions (avoids 30s startup per command)
Project Management: Open/close Vivado projects (.xpr files)
Design Flow: Run synthesis, implementation, and bitstream generation
Reports & Analysis: Get timing summaries, utilization reports, and design analysis
Design Queries: Explore hierarchy, ports, nets, and cells
Simulation: Control Vivado's integrated simulator (xsim)
Raw TCL: Execute arbitrary Vivado TCL commands for advanced operations
Related MCP server: vivado-mcp
Python 3.10+
AMD/Xilinx Vivado installed (tested with 2023.2+)
Vivado must be in your PATH, or specify the full path when starting a session
git clone https://github.com/coreyhahn/vivado_mcp.git
cd vivado_mcp
pip install -e .Add to your Claude Code MCP configuration (~/.claude/claude_desktop_config.json or project-level .mcp.json):
{
"mcpServers": {
"vivado": {
"command": "vivado-mcp"
}
}
}Or if you want to specify the Python interpreter:
{
"mcpServers": {
"vivado": {
"command": "python",
"args": ["-m", "vivado_mcp"]
}
}
}Once configured, Claude can interact with Vivado through natural language. Example workflow:
Start Vivado session: "Start a Vivado session"
Open project: "Open my project at /path/to/project.xpr"
Run synthesis: "Synthesize the design"
Check timing: "What's the timing summary? Is timing met?"
Check utilization: "Show me the resource utilization"
Close session: "Stop the Vivado session"
start_session - Start a persistent Vivado TCL session
stop_session - Stop the Vivado session
session_status - Get session statistics
open_project - Open a Vivado project (.xpr)
close_project - Close the current project
get_project_info - Get project information (part, directory, etc.)
run_synthesis - Run synthesis
run_implementation - Run place and route
generate_bitstream - Generate bitstream
get_timing_summary - Get timing summary (WNS, TNS, WHS, THS)
get_timing_paths - Get detailed timing paths for failing/critical paths
get_utilization - Get resource utilization (LUTs, FFs, BRAMs, DSPs)
get_clocks - Get clock information
get_messages - Get synthesis/implementation messages
get_design_hierarchy - Get module/instance hierarchy
get_ports - Get top-level ports
get_nets - Search for nets
get_cells - Search for cells/instances
launch_simulation - Launch behavioral/post-synth/post-impl simulation
run_simulation - Run simulation for specified time
restart_simulation - Restart from time 0
close_simulation - Close the simulator
get_simulation_time - Get current simulation time
get_signal_value - Get a signal's current value
get_signal_values - Get multiple signal values by pattern
add_signals_to_wave - Add signals to waveform viewer
set_simulation_top - Set the testbench module
get_simulation_objects - List signals in a scope
get_scopes - List hierarchy scopes
step_simulation - Step simulation
add_breakpoint - Add signal breakpoint
remove_breakpoints - Remove all breakpoints
run_tcl - Execute raw TCL commands
generate_full_report - Generate full reports to file
read_report_section - Read portions of large reports
request_feature - Request new features
list_feature_requests - List submitted requests
┌─────────────────┐ MCP Protocol ┌─────────────────┐
│ Claude Code │◄────(JSON-RPC)────────►│ Vivado MCP │
│ (AI Client) │ over stdio │ Server │
└─────────────────┘ └────────┬────────┘
│
│ pexpect
│ (TCL commands)
▼
┌─────────────────┐
│ Vivado Process │
│ (TCL mode) │
└─────────────────┘The server maintains a persistent Vivado process in TCL mode. Commands are sent via pexpect and output is captured by waiting for the Vivado prompt. This avoids the ~30 second startup overhead that would occur if Vivado were launched for each command.
This MCP server was created entirely through conversation with Claude. Here's how you can create similar MCP servers:
Tell Claude what you want to build:
"I want to create an MCP server that lets you control Vivado FPGA tools. You should be able to start Vivado, open projects, run synthesis, check timing, etc."
Explain the key technical challenges:
"Vivado takes 30 seconds to start, so we need a persistent session. Vivado has a TCL interface we can use. We need to parse Vivado's text output into structured data."
Start with basic tools and add more:
Session management (start/stop)
Project management
Design flow commands
Reports and queries
Simulation control
Singleton Session: Only one Vivado process runs at a time
_session: Optional[VivadoSession] = None
def get_session() -> VivadoSession:
global _session
if _session is None:
_session = VivadoSession()
return _sessionpexpect for Process Management: Keeps Vivado alive between commands
self.child = pexpect.spawn(
f'{self.vivado_path} -mode tcl -nojournal -nolog',
encoding='utf-8',
timeout=self.timeout
)
self.child.expect('Vivado%', timeout=10) # Wait for promptOutput Parsing: Convert text reports to structured JSON
def parse_timing_summary(output: str) -> dict:
wns_match = re.search(r"WNS\(ns\)\s*:\s*([-\d.]+)", output)
if wns_match:
result["wns"] = float(wns_match.group(1))Response Truncation: Handle large outputs gracefully
def truncate_response(content: str, max_chars: int) -> dict:
if len(content) > max_chars:
return {"content": content[:max_chars], "truncated": True}Every MCP server needs:
from mcp.server import Server
from mcp.server.stdio import stdio_server
from mcp.types import Tool, TextContent
server = Server("your-server-name")
@server.list_tools()
async def list_tools() -> list[Tool]:
return [Tool(name="...", description="...", inputSchema={...})]
@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
# Handle tool calls
return [TextContent(type="text", text=json.dumps(result))]
async def main():
async with stdio_server() as (read_stream, write_stream):
await server.run(read_stream, write_stream,
server.create_initialization_options())Use this prompt template with Claude:
I want to create an MCP server for [YOUR TOOL].
Background:
- [Tool] is a [description] that [what it does]
- It has a [CLI/API/etc] interface that accepts [commands/requests]
- Key operations I want to support: [list operations]
Technical considerations:
- [Startup time, persistent state, output formats, etc.]
Please help me create an MCP server with:
1. Session/connection management
2. Core operations as tools
3. Proper error handling
4. Structured JSON responses
5. Comprehensive code comments
Start with the basic structure and we'll iterate from there.Contributions welcome! Please feel free to submit issues and pull requests.
MIT License - see LICENSE file for details.
Created with Claude (Anthropic)
Uses the Model Context Protocol specification
Integrates with AMD/Xilinx Vivado
Add a simulation breakpoint on a signal condition
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | Signal to monitor | |
| condition | No | Trigger condition (default: change) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic action and does not mention effects like whether breakpoints are persistent, if simulation must be running, or any 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?
Description is a single sentence, concise and to the point. However, it could include more context 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?
For a simple tool with 2 parameters and no output schema, the description is minimally adequate. It lacks context about simulation state requirements or interaction with other breakpoints.
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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions.
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 clearly states verb 'Add' and resource 'simulation breakpoint' with specific condition 'signal condition'. It distinguishes from sibling tools like 'remove_breakpoints' and other simulation actions.
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 use or alternatives, but the name and description make the tool's purpose clear. Implied usage for setting breakpoints during simulation debugging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add signals to the waveform viewer
| Name | Required | Description | Default |
|---|---|---|---|
| signals | Yes | List of signal paths to add (e.g., ['/tb/dut/clk', '/tb/dut/rst']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It only states 'Add signals' without explaining what happens if signals already exist, whether the waveform viewer is cleared, or if there are side effects. The behavioral detail is insufficient.
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, efficient sentence that front-loads the action and target. No extraneous words or information, earning full points for conciseness.
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 tool with one parameter and no output schema, the description covers the basic purpose. However, it lacks details on return behavior, error conditions, or interaction with other signals in the viewer, so it is merely 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 input schema fully documents the 'signals' parameter with an example, achieving 100% coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
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 states the verb 'Add' and the resource 'signals' with the target 'waveform viewer', making the tool's purpose specific and unambiguous. It is easily distinguished from sibling tools like 'get_signal_value' or 'remove_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 description offers no guidance on when to use this tool versus alternatives, such as if signals should be added before simulation starts or if duplicates are handled. No context on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if Vivado session is responsive and recover if needed. Use this if commands are timing out or behaving unexpectedly.
| Name | Required | Description | Default |
|---|---|---|---|
| auto_recover | No | Restart session if unhealthy (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the potential side effect of restarting the session via auto_recover, but lacks detail on the exact recovery process and failure 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 sentences, front-loaded with purpose, no unnecessary words. Every sentence is informative.
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 health-check tool with one parameter and no output schema, the description adequately covers purpose, usage, and side effects. Missing return value details are acceptable given no output 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 100% for the single parameter, and the description adds minimal value beyond that (only mentions recovery generically). Baseline 3 is appropriate.
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 states the tool checks Vivado session responsiveness and can recover it, which distinguishes it from sibling tools like 'get_host_status' and 'session_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?
Provides clear guidance to use the tool when commands are timing out or behaving unexpectedly, but does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the current project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosure. It only states 'close' without revealing side effects (e.g., unsaved data, reversibility, required permissions), which is insufficient for a potentially destructive action.
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 extremely concise, consisting of a single sentence that directly states the tool's function. However, it lacks any additional valuable context, but for a simple action conciseness is appropriate.
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 the simplicity (no parameters, no output schema), the description is incomplete. It omits important context such as prerequisites, effects on the project, and whether it is safe or destructive.
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 are no parameters, so the schema coverage is 100%. The baseline is 4, and the description adds no parameter info, which is acceptable given zero parameters.
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 states the action (close) and resource (current project), distinguishing it from siblings like open_project and close_simulation. However, it adds no extra scope or nuance beyond the tool's name.
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 provides no guidance on when to use this tool versus alternatives like close_simulation or stop_session, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the current simulation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose important behavioral details like whether the simulation must be running, if state is saved, or side effects on other simulations.
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 sentence, front-loaded, no wasted words; highly efficient.
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 adequate but lacks information about when the action is valid or what happens 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?
With no parameters and 100% schema coverage, the description adds clarifying context by specifying the resource ('current simulation') beyond the empty 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 uses the specific verb 'close' and resource 'current simulation', clearly distinguishing it from siblings like 'restart_simulation' or 'launch_simulation'.
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 provides no guidance on when to use this tool versus alternatives such as 'stop_session' or 'restart_simulation', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate bitstream for the implemented design
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It fails to mention side effects, duration, required permissions, state changes, or any important behavioral traits beyond the action itself.
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, front-loaded with the key verb and object. It is concise but could benefit from slight expansion without losing 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 the tool's significance (final step in design flow), the description is incomplete. It lacks details about output format, return status, or what happens after generation. No output schema exists to compensate.
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, and the schema description coverage is 100% (trivially). With no parameters, the baseline is 4, and the description adds no further param details, which is acceptable.
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 states the action ('generate') and the output ('bitstream for the implemented design'), which distinguishes it from siblings like run_synthesis or close_project. However, it does not clarify what a bitstream is or the context of this step in the design flow.
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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., design must be implemented first), potential constraints, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a full Vivado report to a file. Use when inline reports are truncated or you need the complete output.
| Name | Required | Description | Default |
|---|---|---|---|
| report_type | Yes | Type of report to generate | |
| options | No | Report-specific options (e.g., {'hierarchical': true} for utilization) | |
| output_file | No | Optional custom output path. Default: /tmp/vivado_mcp/<type>_<id>.txt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. Mentions default output path and file generation, but lacks details on file overwrite behavior, permissions, prerequisite session state (e.g., must have run synthesis/implementation).
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 concise sentences, front-loaded with purpose and usage. No verbose or redundant content.
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?
Despite low complexity, description lacks full context: no mention of file overwriting, expected output format, or whether the tool requires a live project. No output schema to compensate.
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 100%, so baseline is 3. Description does not add extra meaning beyond schema's param descriptions; e.g., for 'options' it just says 'report-specific options' without examples.
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?
Clearly states verb 'generate' and resource 'full Vivado report to a file'. Distinguishes from siblings like 'get_timing_summary' which provide inline rather than file output.
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?
Explicitly says when to use ('use when inline reports are truncated or you need complete output'), providing clear context and hinting at alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for cells (instances) in the design
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Wildcard pattern to match cell names (default: '*') | |
| limit | No | Maximum number of results (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'search for cells' without indicating whether the operation is read-only, if it requires specific permissions, or how it handles large result sets. The behavioral context is inadequate for a tool with no annotation support.
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 with no redundant or unnecessary words. It efficiently conveys 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?
Given the lack of annotations and output schema, the description is too minimal. It does not explain what a 'cell' represents in this design context, the expected output format, or any side effects. The tool's simplicity (2 params) partially mitigates this, but more detail would help.
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 100% with both parameters clearly described. The tool description adds no additional semantic information beyond what the schema provides, so the baseline score of 3 is appropriate.
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 clearly states the tool searches for cells (instances) in the design, using a specific verb and resource. It differentiates from sibling tools like get_nets, get_ports, etc., which target different design elements.
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 usage for searching cells by pattern but does not explicitly state when to use versus alternatives, nor does it mention any prerequisites or limitations. With no other cell search tool among siblings, it is the obvious choice, but guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get clock information and constraints
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but lacks details on prerequisites (e.g., open project), side effects, or return behavior. For a tool with no annotations, this is minimally adequate but could be improved.
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. It could benefit from slight expansion, but it is not 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?
The tool has no output schema, so the description should explain what is returned. It only says 'information and constraints' without specifying format or structure. This is insufficient for an AI agent to anticipate the tool's output.
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 are zero parameters, so the baseline is 4. The description adds no parameter information, but none is needed.
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 'Get clock information and constraints' clearly states the tool's action (get) and resource (clocks), and it distinguishes from sibling tools like get_cells and get_nets.
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 use this tool over alternatives, such as other get_* tools or when constraints are of interest. This is a significant omission given 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.
Get the design hierarchy (modules and instances)
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | Maximum hierarchy depth to return (default: 3) | |
| instance_pattern | No | Wildcard pattern to filter instances (e.g., '*cpu*', 'core/alu/*') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden but only states the purpose. It does not disclose whether the operation is read-only, any side effects, or performance implications (e.g., depth limits).
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 that is concise and to the point, with no redundant 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?
Given the lack of output schema and the tool's complexity, the description does not explain what the returned hierarchy looks like (e.g., tree structure, top-level module). It is incomplete for a tool with multiple optional parameters.
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 already describes both parameters (max_depth and instance_pattern) with 100% coverage. The description adds no additional meaning beyond the 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 clearly states the tool retrieves design hierarchy (modules and instances), using specific verb+resource. It is distinct from sibling tools like get_cells, get_scopes, etc.
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 is provided on when to use this tool versus alternatives such as get_scopes or get_cells. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of this Vivado MCP server host including hostname, free memory, and session state. If free memory is below 64GB, use vivado-snoke instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It mentions output fields but does not disclose side effects (likely none), authentication needs, or rate limits. For a simple read-only tool, this is adequate but lacks deeper behavioral context.
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, no redundancy. Key information is front-loaded: purpose first, then usage condition. Every sentence 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?
For a zero-parameter tool with no output schema, the description is fairly complete. It states return fields and a usage caveat. A minor gap: 'session state' is not explained, and output format is not described.
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 with 100% coverage. The description adds meaning by explaining what the tool returns (hostname, free memory, session state), which complements the empty 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 clearly states the tool retrieves host status including specific fields (hostname, free memory, session state). The verb 'Get' and resource 'host status' are precise, and it distinguishes from sibling tools like 'session_status' which likely focuses on session health rather than host hardware.
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?
Provides explicit guidance on when to use an alternative tool: 'If free memory is below 64GB, use vivado-snoke instead.' This directly helps the agent avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get synthesis/implementation messages (errors, warnings)
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | Filter by severity: 'all' (default), 'error', 'critical', 'warning' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries minimal behavioral disclosure. It states the tool gets messages but does not mention whether it is read-only, requires prior synthesis/implementation, or any side effects. The agent lacks information about prerequisites or system impact.
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. Every word serves a purpose, achieving maximal conciseness.
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 the simple one-parameter schema, no output schema, and no annotations, the description is adequate but lacking. It does not explain return format, pagination, or behavior when no messages exist. For a minimal tool, it is passable but not comprehensive.
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 100% (the single 'severity' parameter is fully described in the schema). The tool description adds no extra parameter meaning beyond what the schema already provides, so baseline of 3 is appropriate.
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 states the verb 'Get' and the resource 'synthesis/implementation messages', specifying the content type (errors, warnings). It implicitly distinguishes from sibling tool 'get_simulation_messages' by emphasizing synthesis/implementation rather than simulation.
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 provided on when to use this tool versus alternatives like get_simulation_messages. No prerequisites or conditions are mentioned, leaving the agent to infer usage from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for nets in the design
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Wildcard pattern to match net names (default: '*') | |
| limit | No | Maximum number of results (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It does not mention read-only nature, side effects, performance implications, or whether the search is case-sensitive. This is a significant gap for understanding tool impact.
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 extremely concise with no wasted words. However, it is perhaps too minimal; a slightly more informative description could improve clarity without losing conciseness.
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 the tool's simplicity (2 optional parameters, no output schema), the description is minimally adequate. It does not explain return values or context like 'nets' meaning in the design. Slight room for improvement.
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 100%, so the schema already defines parameters. The description adds no additional meaning beyond the schema (e.g., pattern syntax, limit behavior). Baseline 3 is appropriate.
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 'Search for nets in the design' clearly states the action (search) and the resource (nets). It distinguishes from sibling tools like get_cells, get_clocks, etc., which target different design objects. However, it lacks specificity about the search mechanism (e.g., wildcard support) which the schema provides.
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 use this tool vs alternatives is provided. The context of sibling tools implies this is for nets, but there is no mention of when not to use it or comparison to other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top-level ports of the design
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention that the operation is read-only (likely), return format, or any side effects. The description lacks necessary behavioral context beyond the basic action.
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 waste. It could potentially include more context about what constitutes a 'top-level port', but given the simplicity, it is appropriately brief.
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?
No output schema exists, yet the description does not explain the return value format (e.g., list of port names/objects). The description is incomplete for an agent needing to interpret results, especially with siblings that likely return complex structures.
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 schema coverage is 100%. Per rubric, 0 params yields a baseline of 4. The description adds no parameter information, which is acceptable since none exist.
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 states 'Get top-level ports of the design', using a specific verb ('Get') and resource ('top-level ports'). It effectively distinguishes from siblings like 'get_cells', 'get_nets', etc., which focus on different design elements.
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 use this tool vs alternatives is provided. Usage is implied by the tool name and description ('when you need top-level ports'), but no when-not-to-use or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently open project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'Get' implies a read-only operation, the description does not explicitly confirm safety, absence of side effects, or any prerequisites for the currently open project. Minimal behavioral disclosure.
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 superfluous words. It is front-loaded with the verb and resource. While concise, it could benefit from additional detail without becoming 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 the absence of an output schema and annotations, the description must be self-sufficient. It fails to explain the output structure or semantics, making it incomplete for an AI agent to infer the tool's behavior.
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 are no parameters, so the description is the sole source of semantic meaning. It fails to specify what kind of information is returned (e.g., project name, path, settings), leaving ambiguity. Baseline for 0 parameters is 4, but the vagueness reduces it to 2.
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 'Get' and identifies the resource as 'information about the currently open project'. It clearly indicates a read operation and distinguishes from sibling tools that either open/close projects or retrieve specific details like cells or clocks.
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 use this tool versus alternatives such as get_cells, get_clocks, or get_design_hierarchy. The description does not explain the scope of 'information' or how to decide between this and other get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available scopes (hierarchy) in the simulation
| Name | Required | Description | Default |
|---|---|---|---|
| parent | No | Parent scope to list children of (default: root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the action without disclosing behavioral traits such as authentication requirements, what happens if parent is invalid, or if the list is recursive.
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 that is concise and front-loaded with the key action. It avoids verbosity, but could optionally include more detail without becoming bloated.
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 the lack of output schema, the description does not explain what the returned list contains (e.g., names, paths, metadata). The tool's role relative to sibling tools is unclear, and the simulation context is only implied.
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 description coverage is high (100% with parameter 'parent' described). The tool description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
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 states the tool lists available scopes, using specific verb 'List' and resource 'scopes (hierarchy)'. However, it does not distinguish from sibling tool 'get_design_hierarchy' which may also list hierarchy but in design context.
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 is provided on when to use this tool versus alternatives like 'get_design_hierarchy' or in which scenarios. The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current value of a signal in simulation
| Name | Required | Description | Default |
|---|---|---|---|
| signal | Yes | Full hierarchical signal path (e.g., '/tb/dut/clk', '/tb/dut/data_out') | |
| radix | No | Display radix (default: hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It does not mention that the operation is read-only, does not specify error conditions or side effects, and lacks any behavioral detail beyond the basic action.
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, efficient sentence that communicates the core purpose. However, it could include additional essential details without becoming verbose; it is slightly under-specified but still concise.
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?
No output schema is provided, yet the description does not describe what is returned (e.g., value format, type). It also lacks context on simulation state requirements, error handling, or performance implications, leaving the agent with insufficient information 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?
The input schema already documents both parameters with descriptions (100% coverage). The tool description adds no additional meaning beyond what is in the schema, just restates the purpose. Baseline 3 is appropriate.
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 states the verb 'Get', the resource 'current value of a signal', and the context 'in simulation'. It effectively distinguishes from sibling tools like 'get_signal_values' (plural) and other getters.
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 provides no guidance on when to use this tool versus alternatives, no prerequisites (e.g., simulation must be running), and no context on when not to use it. It relies solely on the tool name for inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current values of multiple signals matching a pattern
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Signal pattern with wildcards (e.g., '/tb/dut/*', '/tb/dut/data*') | |
| radix | No | Display radix (default: hex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It merely states the action without mentioning side effects, permissions, performance implications, or return format.
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 conveys the core purpose with no unnecessary words. Highly efficient.
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 the absence of output schema and annotations, the description is insufficient. It does not explain how pattern matching works, what the return format is, or how to handle multiple matches, which are crucial for correct usage.
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 100%, so baseline is 3. The description adds no additional semantics beyond the existing schema descriptions for 'pattern' and 'radix'.
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 states the verb 'get', the resource 'signal values', and the scope 'multiple signals matching a pattern'. This effectively distinguishes it from the sibling tool 'get_signal_value' which retrieves a single signal.
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 use this tool versus alternatives like 'get_signal_value' or other getter tools. The description lacks context on typical use cases or preconditions for pattern matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get simulation log messages (errors, warnings, info)
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | Filter by severity (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only restates the purpose. Lacks details on behaviors such as scope (current simulation only), pagination, or rate limits.
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, concise and front-loaded with the key action and resource. 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?
Given the simplicity (one enum param, no output schema), the description is minimally adequate. However, it lacks usage guidance and behavioral context, leaving gaps 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 100% with a single parameter having clear enum and description. The description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.
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?
Clearly states the verb 'Get' and resource 'simulation log messages', and specifies the types (errors, warnings, info). However, it does not distinguish from the sibling 'get_messages'.
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 use this tool versus alternatives like 'get_messages'. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List simulation objects (signals, variables) in a scope
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Hierarchical scope (e.g., '/tb', '/tb/dut'). Default is root. | |
| filter | No | Filter by object type (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description correctly implies a read-only behavior by using 'List'. However, it does not disclose any additional traits like performance, permissions, or side effects. It is adequate but minimal.
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 states the purpose without any redundant information. It is front-loaded and efficient.
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 list tool, the description covers the core functionality. A minor gap is the lack of return format specification, as no output schema exists. However, the tool is straightforward and the description is sufficient for basic 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 coverage is 100%, so the schema already documents both parameters well. The description adds the phrase 'in a scope', which aligns with the scope parameter but does not provide new semantic meaning beyond the 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 clearly states the verb 'List', the resource 'simulation objects (signals, variables)', and the context 'in a scope'. This directly differentiates from sibling tools like get_scopes (which lists scopes) and get_nets (which lists nets).
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 provides no guidance on when to use this tool versus alternatives like get_scopes, get_nets, get_ports, or get_clocks. There is no mention of prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current simulation time
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic functionality without disclosing any behavioral traits such as time units, session requirements, or 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?
The description is a single, clear sentence with no wasted words. It is appropriately front-loaded and concise.
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?
While the tool is simple, the description lacks details such as time units or session context. Given the absence of output schema and annotations, it is minimally adequate but not 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?
The tool has no parameters, and the schema coverage is 100%. According to guidelines, 0 parameters warrant a baseline score of 4.
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 'Get the current simulation time' clearly states the verb 'Get' and the resource 'current simulation time'. It is distinct from sibling tools like 'get_simulation_messages' or 'get_simulation_objects'.
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 use this tool versus alternatives. The description is minimal and does not provide any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get timing paths for failing or critical paths. Returns structured summary (slack, source, dest, clocks) by default. Use generate_full_report for verbose path details.
| Name | Required | Description | Default |
|---|---|---|---|
| num_paths | No | Number of paths to report (default: 10) | |
| slack_threshold | No | Only show paths with slack less than this (default: 0 for failing paths) | |
| path_type | No | Type: 'setup' (default) or 'hold' | |
| from_pin | No | Filter paths starting from this pin/cell pattern (Vivado -from option) | |
| to_pin | No | Filter paths ending at this pin/cell pattern (Vivado -to option) | |
| through | No | Filter paths going through this pin/cell pattern (Vivado -through option) | |
| clock | No | Filter paths by clock domain name | |
| detail_level | No | Detail level: 'summary' (default, structured only), 'standard' (+ truncated raw), 'full' (+ complete raw) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates default behavior and detail levels, but does not disclose potential side effects, authorization needs, or performance constraints. The verb 'get' implies read-only, but not explicitly stated.
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 core purpose and immediate distinction from sibling. No unnecessary 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?
Given 8 parameters and no output schema, the description provides the key differentiation and default return format, but lacks guidance on typical usage patterns or expectations for complex filtering parameters. Adequate but leaves 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 coverage is 100% with clear parameter descriptions. The description adds minimal additional semantics beyond summarizing default behavior. Baseline 3 is appropriate as schema already documents parameters well.
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 states it gets timing paths for failing or critical paths, specifies the return format (slack, source, dest, clocks), and distinguishes from sibling generate_full_report for verbose details.
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?
Explicitly suggests using generate_full_report for verbose path details, providing an alternative. However, it does not explicitly state when not to use this tool or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get timing summary (WNS, TNS, WHS, THS). Returns parsed metrics only by default. Use generate_full_report for raw output.
| Name | Required | Description | Default |
|---|---|---|---|
| report_type | No | Type: 'summary' (default), 'setup', 'hold', or 'all' | |
| detail_level | No | Detail level: 'summary' (default, parsed metrics only), 'standard' (+ truncated raw), 'full' (+ complete raw) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses default behavior (parsed metrics only) but does not elaborate on other behavioral traits such as auth needs, side effects, or return details beyond the default. With no annotations, the description adds some transparency but not full coverage.
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 efficient sentences: first states purpose with specific metrics, second provides immediate alternative guidance. Zero 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?
No output schema, so description should hint at return format. Mentions 'parsed metrics' but no structure details. Parameter effects beyond default are not elaborated, relying on schema. However, the tool is simple and sibling context 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?
Schema coverage is 100% with both parameters thoroughly described. The description adds marginal value by referencing default behavior but does not provide additional parameter insight beyond what the schema already offers.
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 states the tool gets a timing summary, listing specific metrics (WNS, TNS, WHS, THS). It distinguishes from sibling 'generate_full_report' by noting default behavior (parsed metrics only).
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?
Explicitly mentions when to use the alternative 'generate_full_report' for raw output. Does not specify context for other siblings like 'get_timing_paths', but given the sibling count, the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get resource utilization (LUT, FF, BRAM, DSP, IO). Returns parsed metrics only by default. Use generate_full_report for hierarchical details.
| Name | Required | Description | Default |
|---|---|---|---|
| hierarchical | No | Include hierarchical breakdown (default: false) | |
| detail_level | No | Detail level: 'summary' (default, parsed only), 'standard' (+ truncated raw), 'full' (+ complete raw) | |
| module_filter | No | Wildcard pattern to filter modules in hierarchical report | |
| threshold_percent | No | Only show resources above this utilization percentage (0-100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the default output type ('parsed metrics only') but does not mention read-only status, potential side effects, or return format details. This is adequate but not comprehensive.
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 wasted words. The first sentence states the core purpose with specific resource types, the second provides usage differentiation. Perfectly front-loaded and concise.
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 the tool has 4 parameters with good schema descriptions but no output schema or annotations, the description could better clarify the return format. However, it explains default behavior and alternative for deeper detail, making it fairly complete for a retrieval tool.
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 covers all parameters with descriptions (100% coverage). The description adds no extra parameter information beyond what the schema provides. Under the rules, baseline is 3 when schema coverage is high.
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 specifies the exact resources (LUT, FF, BRAM, DSP, IO) and states the default behavior (parsed metrics only). It also distinguishes from the sibling tool generate_full_report, making the purpose clear and specific.
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 explicitly mentions an alternative tool for hierarchical details ('Use generate_full_report for hierarchical details'), providing clear guidance on when not to use this tool. However, it doesn't elaborate on when exactly to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch behavioral simulation (xsim). Opens the simulator and loads the design.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Simulation mode (default: behavioral) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states it opens the simulator and loads the design but omits side effects, permissions required, or the state changes (e.g., starting a simulation session). The description is insufficient for an agent to understand the full impact of invoking 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?
Two sentences with no unnecessary words. The description is front-loaded with the key action and resource. 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?
Given the tool has one parameter and no output schema, the description fails to explain the broader context, such as that launching a simulation creates a session used by other tools (e.g., add_signals_to_wave, step_simulation). It does not specify what 'loads the design' means or whether it affects existing sessions.
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 100%, so baseline is 3. The description adds no value to the 'mode' parameter beyond the schema; it only mentions 'behavioral simulation' while the schema lists other modes. This can mislead the agent into thinking only behavioral mode is available, detracting from clarity.
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 states the verb 'launch' and resource 'simulation (xsim)', indicating it opens the simulator and loads the design. However, it only mentions 'behavioral simulation' despite the schema supporting multiple modes, which could cause confusion but still distinguishes from siblings like 'run_simulation' or 'close_simulation'.
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 use this tool versus alternatives such as 'run_simulation' or 'open_project'. It does not mention prerequisites like having an open project or a loaded design, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all feature requests that have been submitted
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only listing operation, but no annotations are provided. It does not disclose ordering, filtering capabilities, or potential limitations.
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?
Single, direct sentence with no redundant information. Front-loaded and efficient.
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 list tool with no parameters and no output schema, the description is adequate but lacks details like sort order or return format.
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 has no parameters, so description adds no additional meaning beyond structure. Baseline set to 4 for zero-parameter tools.
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 clearly states the action 'list' and the resource 'feature requests'. It distinguishes from sibling 'request_feature' which is for submission.
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 use this tool versus alternatives like request_feature. No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a Vivado project (.xpr file)
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | Path to .xpr project file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavior like overwriting existing session, required permissions, or error handling for invalid paths.
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?
Single sentence efficiently conveys the tool's action. Could include more detail 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?
Adequate for a simple open operation, but lacks return value info and no output schema. Could mention that it sets the current project 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 has 100% coverage with description. The tool description adds no extra meaning beyond what the schema already provides.
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 clearly states verb 'Open' and resource 'Vivado project (.xpr file)', distinguishing it from siblings like close_project or launch_simulation.
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 when-to-use guidance, but the purpose is obvious. No alternative tools mentioned, but context implies it's necessary before most synthesis/implementation actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a section of a previously generated report file
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | No | Report ID returned by generate_full_report | |
| file_path | No | Alternative: direct file path to read | |
| start_line | No | Line number to start reading from (1-indexed, default: 1) | |
| num_lines | No | Number of lines to read (default: 100) | |
| search_pattern | No | Regex pattern to find a section (returns lines around first match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'read', which implies non-destructive behavior, but lacks details on permissions, side effects, or return format. Since no annotations are provided, the description should disclose more about what happens during execution, such as file access requirements.
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 extremely concise—one sentence with no extra words. While efficient, it sacrifices completeness for brevity. It front-loads the purpose but leaves out critical context.
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 the tool has 5 parameters, no required fields, and no output schema, the description should explain how the parameters work together (e.g., report_id vs file_path, search_pattern usage). It does not mention what the tool returns or how to interpret the output, leaving the agent guessing.
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 100%, so the description does not need to elaborate on parameters beyond what is already in the schema. The description does not add new meaning to the parameters; it simply states the overall purpose.
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 states the tool reads a section of a report file and specifies it is for previously generated reports, which aligns with the tool name. However, it could more explicitly differentiate from sibling tools like 'generate_full_report' by emphasizing that this tool only reads existing reports.
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 use this tool versus alternatives. The context that it reads 'previously generated' reports is implied but not explicitly stated as a prerequisite. No mention of when not to use it or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove all breakpoints
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It only states the action but does not reveal whether the removal is permanent, whether confirmation is needed, or if it affects other state like simulation or debugging sessions. This is insufficient for a mutation 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?
The description is a single, concise sentence that is front-loaded with the key action. However, it is so brief that it may sacrifice completeness. Still, for a simple tool with no parameters, it is appropriately compact.
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 no annotations, no output schema, and no parameters, the description is extremely minimal. It fails to provide essential context for a mutation tool, such as whether breakpoints are session-specific, if the action is reversible, or what the return value is. This leaves an agent with insufficient information to use the tool safely.
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, and the description adds meaning by clearly stating the action on 'all breakpoints'. Since there are no parameters to document, a baseline score of 4 is appropriate, and the description does not need to add more.
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 'Remove all breakpoints' uses a specific verb (remove) and resource (breakpoints), clearly indicating the tool's function. It is distinct from the sibling 'add_breakpoint', making its purpose 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?
No guidance is provided on when to use this tool versus alternatives. It does not state that it removes all breakpoints without selection, nor does it mention prerequisites or potential side effects. An agent would lack context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a new feature or capability for the Vivado MCP server. Use this when you encounter a limitation or wish you had a tool that doesn't exist.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short title for the feature request | |
| description | Yes | Detailed description of what you need and why | |
| use_case | No | The specific use case or task you were trying to accomplish | |
| priority | No | How important is this feature? (default: medium) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('request a new feature') but does not disclose behavioral traits such as whether the request is saved, who receives it, or if any side effects occur. The description is adequate but lacks depth for a tool with no annotation coverage.
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 composed of two short sentences, entirely free of fluff. The purpose is front-loaded, and every sentence serves a clear function: stating the tool's action and explaining when to use it.
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 the low complexity of this tool, the absence of an output schema, and the rich parameter descriptions in the schema, the description is sufficiently complete. It explains what the tool does and when to use it, which is all that is needed for an agent 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 100%, so the input schema already describes all four parameters. The tool description does not add any additional meaning or context beyond what is in the schema. According to the rubric, the baseline is 3 when coverage is high, and no further value is added.
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 states the tool's purpose: 'Request a new feature or capability for the Vivado MCP server.' It uses a specific verb ('request') and resource ('feature'), and it differentiates from sibling tools like list_feature_requests, which handles listing existing requests.
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 explicitly says when to use the tool: 'when you encounter a limitation or wish you had a tool that doesn't exist.' This provides clear context, though it does not mention when not to use it or discuss alternatives like list_feature_requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart the simulation from time 0
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the restart action but does not clarify side effects like whether breakpoints or waveforms are cleared.
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 concise sentence, front-loaded with the action and resource. 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?
For a parameterless tool with no output schema, the description adequately conveys the core functionality. Could be slightly more complete by mentioning what state is reset.
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?
With no parameters and 100% schema coverage, the description adds no extra param meaning. Baseline 4 is appropriate as the schema already fully documents the empty param list.
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 states the verb 'Restart' and the resource 'simulation', specifying it restarts from time 0. This distinguishes it from sibling tools like close_simulation (ends) or step_simulation (single 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?
No explicit when-to-use or when-not-to-use guidance is provided. The purpose is self-explanatory, but alternatives or prerequisites are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run implementation (place and route) on the current project
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | No | Number of parallel jobs (default: 4) | |
| timeout | No | Timeout in seconds (default: 3600 = 60 minutes). Increase for large designs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, whether results are overwritten, required project state, or any other behavioral traits. For a mutation tool, this is insufficient.
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 very concise with no waste. However, it may be too minimal for a tool that likely has important behavioral nuances. It earns its place but lacks helpful detail.
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 the lack of annotations, output schema, and minimal description, the tool definition does not provide adequate context. Missing information includes expected return values, progress indication, and impact on the project state.
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 100%, so the schema already documents both parameters with defaults. The description adds no extra meaning beyond the schema, resulting in a baseline score of 3.
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 states the verb 'run' and the resource 'implementation (place and route)' on the current project. It distinguishes from sibling tools like run_synthesis and run_simulation, which are different phases.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as requiring synthesis to be run first. There is no indication of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the simulation for a specified time
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | Time to run (e.g., '100ns', '1us', '10ms', 'all') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the action but omits critical details: whether the run is blocking, what happens if simulation is already running, duration limits, or side effects on state. This is insufficient for safe invocation.
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 conveys the essential action without unnecessary words. It is well-structured and easy to parse.
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?
Despite low complexity (one parameter), the description lacks completeness. It omits return values, behavior after completion, and integration with other simulation lifecycle tools. Without output schema, more context is needed.
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 100% and the parameter 'time' is well-described with examples. The description adds little beyond the schema, merely restating the purpose. Baseline score of 3 is appropriate.
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 states it runs a simulation for a specified time, which is a distinct action from sibling tools like launch_simulation or step_simulation. However, it does not explicitly differentiate itself from these alternatives, missing a chance to highlight uniqueness.
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 is provided on when to use this tool versus alternatives such as launch_simulation, step_simulation, or restart_simulation. The agent receives no context about prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run synthesis on the current project
| Name | Required | Description | Default |
|---|---|---|---|
| jobs | No | Number of parallel jobs (default: 4) | |
| timeout | No | Timeout in seconds (default: 1800 = 30 minutes). Increase for large designs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It provides no information about side effects, typical runtime, failure conditions, or safety profile. The agent cannot infer whether this is a safe read, destructive write, or long-running process.
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 extremely concise at one sentence. However, it may be too brief, sacrificing necessary completeness. While it earns its place by stating the core action, it does not provide enough value for a tool with 2 parameters and no output schema.
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 no output schema and minimal description. Critical context is missing: whether synthesis produces output files, how to check results, what errors can occur, or that it may take significant time. The description is insufficient for an agent to use this tool 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?
Although the description adds no parameter information, the input schema already fully describes both parameters (jobs and timeout) with defaults and usage hints. Parameter schema coverage is 100%, so the baseline 3 is appropriate.
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 'Run synthesis on the current project' is essentially a tautology of the tool name. It adds minimal context (the implicit 'current project'), but fails to specify what synthesis accomplishes or how it differs from sibling tools like 'run_implementation'.
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 usage guidelines are provided. The description does not indicate when to use this tool (e.g., after opening a project, before implementation), nor does it mention any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw TCL command in Vivado. Use for advanced operations not covered by other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | TCL command to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'raw' execution implying directness but lacks details on risks, side effects, error handling, or permissions needed. Adequate but not thorough.
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 concise sentences with no superfluous information; each sentence 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?
For a simple tool with one parameter and no output schema, the description is minimal but sufficient. Lacks details on return value, error handling, or examples, which could be beneficial for advanced operations.
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 one parameter 'command' with schema description 'TCL command to execute'; schema coverage is 100% so description adds no extra meaning. Baseline score of 3 is appropriate.
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 clearly states it executes a raw TCL command in Vivado and explicitly positions it for advanced operations not covered by other tools, distinguishing it from siblings.
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?
Provides guidance to use for advanced operations not covered by other tools, implying when to use, though it does not explicitly list when not to use or suggest alternatives for common cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status and statistics of the current Vivado session
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get') but does not disclose behavioral traits such as authentication needs, side effects, or what exactly 'status and statistics' include. The description is too vague to fully inform the agent.
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 extraneous information. Every word contributes to the purpose, and it is efficiently 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?
Given no output schema, no annotations, and zero parameters, the description is minimal. It is adequate for a simple status tool but lacks detail on the response format or how it differs from closely related sibling tools like 'check_session_health' or 'get_host_status'. The agent may need additional context to select this tool 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?
The tool has zero parameters and schema coverage is 100% (empty schema). The description does not need to add parameter details, and 'status and statistics' provides minimal context. With no parameters, the baseline score of 4 is appropriate as the description adds some meaning beyond an empty 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 uses a specific verb ('Get') and resource ('status and statistics of the current Vivado session'), making the tool's purpose clear. It is not a tautology and distinguishes from sibling tools like 'check_session_health' by implying broader scope, though not 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 use this tool versus alternatives (e.g., 'check_session_health', 'get_host_status'). The description lacks when-to-use, when-not-to-use, or any contextual directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the top module for simulation
| Name | Required | Description | Default |
|---|---|---|---|
| top_module | Yes | Name of the testbench module | |
| fileset | No | Simulation fileset (default: sim_1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states action without disclosing side effects (e.g., permanent change vs. session-only, validation of module name, error handling).
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?
Single sentence with no redundant words. Front-loaded and efficient.
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?
Tool is simple with only two parameters; schema covers them. However, missing context about its effect on the project state and typical usage flow makes it incomplete 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?
Input schema already provides 100% coverage with descriptions for both parameters. The description adds no additional meaning beyond what is in the schema, so baseline score of 3 is appropriate.
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 clearly states the tool sets the top module for simulation, distinguishing it from other simulation tools like launch_simulation. However, it could more explicitly differentiate from related actions like setting 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?
No context on when to use this tool versus alternatives. No mention of prerequisites (e.g., project must be open) or that this typically precedes launching simulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a persistent Vivado TCL session. Must be called before other commands.
| Name | Required | Description | Default |
|---|---|---|---|
| vivado_path | No | Path to Vivado executable (default: 'vivado' from PATH) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the burden. It states the core behavior but doesn't disclose details like whether it returns a session handle, any side effects, or prerequisites beyond path. Minimal but not misleading.
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 wasted words. The essential information is 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?
With one optional parameter, no output schema, and a simple purpose, the description is adequate but incomplete. It doesn't explain what the tool returns or if it can be called multiple times. More context would benefit the 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 has 100% description coverage for the single parameter (vivado_path). The description adds no extra meaning beyond the schema's own description. Baseline of 3 is appropriate.
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 clearly states the verb 'Start' and the resource 'persistent Vivado TCL session'. It also provides the essential context that it must be called before other commands, which distinguishes it from sibling tools that depend on an active 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?
Explicitly says 'Must be called before other commands', which gives clear guidance on when to use this tool. Could be improved by noting when not to use it (e.g., if a session already exists), but the statement is functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step the simulation by a delta cycle or time step
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of steps (default: 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It lacks details on side effects, permissions, or whether the tool blocks or returns immediately. Does not explain the difference between delta cycle and time step.
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?
Single sentence, no wasted words, clearly front-loaded with the action and resource.
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 tool with one optional parameter and no output schema, the description is adequate but minimal. It does not explain the return value or behavior details like the difference between delta cycle and time step, leaving some ambiguity.
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 has 100% description coverage for the single parameter 'count'. The description adds no additional meaning beyond the schema, but also doesn't mislead. Baseline of 3 is appropriate.
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 the verb 'step' and resource 'simulation', which is clear and distinguishes it from siblings like 'run_simulation' and 'restart_simulation'. Mention of 'delta cycle or time step' adds specificity.
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 use this tool versus alternatives. Does not mention prerequisites or when not to use. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the Vivado TCL session and free resources
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry all behavioral info. It mentions 'free resources' but lacks details on side effects, idempotency, or prerequisites.
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 wasted words. It efficiently conveys the tool's 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?
For a simple tool with no parameters and no output schema, the description adequately explains the action and outcome (free resources). Could optionally mention that it stops a previously started session.
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?
No parameters exist, so the description needs no parameter documentation. Baseline 4 applies as the schema coverage is 100%.
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 states the action 'Stop' and the resource 'Vivado TCL session', and adds 'free resources' to clarify the effect. It distinguishes from siblings like start_session and check_session_health.
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 use, when not to use, or alternatives. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_breakpointadd_signals_to_wavecheck_session_healthclose_projectclose_simulationgenerate_bitstreamgenerate_full_reportget_cellsget_clocksget_design_hierarchyget_host_statusget_messagesget_netsget_portsget_project_infoget_scopesget_signal_valueget_signal_valuesget_simulation_messagesget_simulation_objectsget_simulation_timeget_timing_pathsget_timing_summaryget_utilizationlaunch_simulationlist_feature_requestsopen_projectread_report_sectionremove_breakpointsrequest_featurerestart_simulationrun_implementationrun_simulationrun_synthesisrun_tclsession_statusset_simulation_topstart_sessionstep_simulationstop_sessionMost tools have clearly distinct purposes, but there is some overlap between get_simulation_objects and get_scopes (both list simulation objects), and between get_signal_value and get_signal_values (single vs pattern). Overall, an agent can distinguish most tools.
All tool names consistently use verb_noun in snake_case (e.g., add_breakpoint, generate_bitstream, run_synthesis). No mixed conventions or inconsistent patterns.
40 tools is high but appropriate for a comprehensive FPGA design tool covering synthesis, implementation, simulation, reporting, and session management. Slightly above typical MCP server count, but each tool serves a specific purpose.
The tool surface covers the main Vivado workflows: project management, synthesis, implementation, bitstream generation, simulation, and reporting. Minor gaps exist (e.g., updating constraints, IP management), but core operations are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/coreyhahn/vivado_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
