vivado-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.25
Disambiguation3/5
Most tools have distinct purposes, but there are notable overlaps: run_tcl and safe_tcl are essentially the same with different escaping, get_critical_warnings and get_run_progress both inspect logs for warnings, and parse_xpr vs get_project_info both provide project information (offline vs live). These ambiguities could cause agent misselection despite helpful descriptions.
Naming Consistency4/5
The majority of tools follow a clean verb_noun pattern (get_*, run_*, parse_*, set_*). However, there are meaningful deviations: xdc_lint (noun-first), xdc_auto_fix, verilog_compile_check, safe_tcl, and verify_io_placement_tool break the pattern, making the naming slightly inconsistent.
Tool Count2/5
30 tools is excessive for a single server, exceeding the 25+ threshold. Several tools are redundant (safe_tcl vs run_tcl) or overly niche (set_wave_zoom, set_wave_analog, get_next_suggestion), making the surface feel bloated and harder for an agent to navigate.
Completeness4/5
The tool set covers the primary FPGA flow: synthesis, implementation, bitstream, programming, reporting, XDC checks, and offline parsers. However, there is no dedicated tool for project creation or source file management—agents must rely on the generic run_tcl for these, which is a minor but noticeable gap.
Average 4.4/5 across 30 of 30 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'close the session' without disclosing side effects (e.g., terminating running processes, losing unsaved data) or the tool's safety profile. This is a bare statement with no added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of fluff, but the brevity borders on under-specification. It is not structured to front-load practical information, and the Args section already appears in the schema, adding redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and minimal description, the tool lacks completeness for an agent to understand the full context of stopping a session. The output schema exists, but the description does not clarify the return behavior or the impact on related sessions. Given the simple purpose, some context is still necessary, especially regarding killing active operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It repeats the parameter name 'session_id' and describes it as the session identifier to close, which adds little beyond the schema's title 'Session Id'. The default value 'default' is not explained, and there is no elaboration on accepted formats or behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes a specified Vivado session, using a specific verb ('关闭') and a distinct resource ('会话' = session). This differentiates it from sibling tools like start_session or list_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of preconditions or typical use cases. The description only states what it does, not when to use it, leaving the agent without selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that only active sessions are returned and includes status, but does not explicitly state that the operation is read-only or has no side effects. The implication is fairly clear for a list operation, but some behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It efficiently conveys the tool's core function without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no nested objects, output schema exists), the description is sufficient for an agent to understand what it does. It lacks some context about status values, but the output schema likely covers that, so the description is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so the baseline of 4 applies. The description doesn't need to add parameter information, and indeed it doesn't, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all active Vivado sessions and their status.' This is a specific verb (list) and resource (active Vivado sessions), and it distinguishes from siblings like start_session and stop_session, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention exclusions or suggest related tools, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose that it executes report_timing_summary and parses the result, which gives some insight into its behavior. However, it does not mention potential side effects, session requirements, or whether it is a read-only operation, limiting full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized: a one-sentence summary followed by brief internal details and return characteristics. Every sentence adds value and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, an output schema, and a straightforward purpose. The description covers the purpose, internal execution, and output features (human-readable, Chinese, PASS/FAIL). It lacks explicit usage guidance and parameter elaboration, but is otherwise adequate for a report-generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter, session_id, is described as '目标会话 ID' (target session ID), which merely restates the parameter name. It does not explain how to obtain the session ID, the meaning of the default value, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a structured timing report, specifically executing report_timing_summary and parsing it into a summary with critical path details. It differentiates itself from siblings like get_utilization_report and get_io_report by focusing on timing analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming the underlying command (report_timing_summary) and the PASS/FAIL status, but it does not explicitly state when to use this tool versus alternatives like get_critical_warnings or other report tools. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses that it samples various data, includes conditional logic (CW/ERROR only if impl_run exists), and outputs markdown. It implies read-only behavior by mentioning '跑完 impl 之后' but does not explicitly state it won't trigger 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then typical use, bullet-pointed content list, output format, and args. It is slightly verbose but every sentence provides useful information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is an output schema, so return value details are covered by schema. The description covers input args, output format, and usage scenarios. It misses prerequisites like project/session existence, but overall it is sufficiently complete for a tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains impl_run as the run used to query runme.log counts with default impl_1, but session_id is only described as '目标会话 ID' which adds little meaning. The description does not fully document how session_id is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generate a project summary for git commit body, listing specific content (timing/resource/CW/status). It distinguishes itself from sibling tools like get_timing_report and get_utilization_report by being a composite summary generator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions a typical use case: after RTL changes and implementation, to fill commit body with key numbers. It does not explicitly exclude other scenarios or mention alternatives, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it runs a specific TCL command, extracts rows from multiple tables, and adds [CRITICAL]/[WARN] highlighting based on thresholds. It also explains the effect of the detail flag. This goes beyond a simple 'get report' statement, though it doesn't cover error conditions or side effects, which are minimal for a read-only report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear summary sentence. It uses bullet points for typical uses and a dedicated Args section, making it scannable. Some redundancy with the schema exists in the Args block, but it avoids unnecessary jargon or bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is sufficiently complete. It covers the main use cases, the detail flag behavior, and the highlighting logic. Among many sibling report tools, it clearly differentiates itself by focusing on resource utilization and typical scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides a thorough explanation of the 'detail' parameter (appending BRAM detail section, effects on output format, default false). However, 'session_id' is only described as '目标会话 ID' (target session ID), which adds minimal meaning beyond the schema's name and default. Only one of the two parameters gains meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb '获取' (get) and a clear resource scope: LUT/FF/BRAM/DSP/IO utilization. It distinguishes itself from sibling report tools like get_timing_report and get_io_report by focusing on resource utilization and explicitly mentions it executes 'report_utilization -return_string'. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The '典型用途' (typical uses) section provides concrete scenarios: post-synthesis resource checks, timing congestion diagnosis, and BRAM detail inspection. This gives clear context for when to use the tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains it retrieves CONFIG.* properties via Tcl API and supports filtering, but does not explicitly state it is read-only/non-destructive, nor mention behavior on invalid IP names or missing sessions. The description adds some value but lacks safety and error context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear two-sentence overview followed by an Args list. All information is relevant and front-loaded; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 params and no annotations, but the description covers purpose, method, and parameter semantics. Output schema exists so return values are not needed. Minor gaps: no mention of session validity or error behavior, but overall adequate for a read-only inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates with an Args section that explains ip_name with an example, filter_keyword with examples and case-insensitivity, and session_id as target session ID. This provides meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries all configuration parameters (including GUI-hidden ones) for an IP instance, using a specific verb (查询/inspect) and resource (IP config params). This distinguishes it from siblings like run_synthesis or get_io_report, which focus on other objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting IP configuration but does not explicitly state when to prefer this over alternatives or mention conditions like requiring an active session. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses that the tool executes report_io and parses the result, and it describes the output structure. However, with no annotations, it does not explicitly state that the operation is read-only, whether an active session is required, or how errors are handled, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a brief opening line, bullet points for output contents, and an Args section. Every sentence adds value and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return value structure is defined externally. The description adds the execution behavior (runs report_io) and highlights the key report contents. It lacks explicit session prerequisite information, but for a single-parameter report tool, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the type and default for session_id; the description adds the semantic meaning '目标会话 ID' (target session ID). This compensates for the zero schema description coverage and gives the agent enough information to supply a valid session.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '获取结构化 IO 引脚报告（JSON）', clearly identifying the action (get) and resource (IO pin report) plus the JSON format. The bullet points listing pin, site, direction, IO standard, and Bank further distinguish it from sibling report tools like get_timing_report or get_utilization_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by detailing exactly what data it returns (per-port pin info and summary statistics). An agent can infer to use this tool when IO pin details are needed, but there is no explicit alternative comparison or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly lists what information will be returned, but does not state whether the tool is read-only, whether it requires an open session, or any potential side effects. Given the 'get' prefix and the nature of the tool, the absence of these details is a minor gap, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the purpose, gives a use-case justification, and follows with a concise bullet list of included information. Every sentence adds value, and the format is easy to scan without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple single-parameter shape and the presence of an output schema, the description does not need to detail return values. It sufficiently explains what categories are covered and when to use it. It could mention prerequisites like needing an active session, but that is handled by sibling tools (start_session, list_sessions), so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description and 0% schema coverage. The description compensates by explicitly defining the sole parameter: 'session_id: 目标会话 ID', which adds clear meaning. While minimal, it fully covers the parameter's purpose, exceeding the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('获取') and clearly identifies the resource ('当前 Vivado 项目的综合信息'), enumerating exact content categories (project name, part, top-level, files, IP, run status). This distinguishes it from sibling tools that target specific reports (e.g., get_timing_report, get_utilization_report), making it the go-to overview tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a clear usage context: 'AI 接手陌生项目时的起点' (starting point when AI takes over an unfamiliar project) and emphasizes '一次查询完成摸底' (one query for reconnaissance). It does not provide explicit when-not-to-use guidance, but the context is strong enough to imply this is the first query to run before diving into more specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains a nontrivial behavior: a built-in pre-check detects CRITICAL WARNING and blocks generation unless force=True is set. This goes beyond just saying 'generate' and warns the agent about a condition that could affect the outcome. It could add more about return values or side effects, but the output schema likely covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief summary sentence, a note about the safety check, and a clearly formatted Args list. It is not overly long and each part serves a purpose. The only minor redundancy is repeating defaults that already appear in the schema, but this makes the description self-contained and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bitstream generation with a safety mechanism) and that an output schema exists, the description provides adequate context. It places the tool in the implementation flow, explains the safety behavior, and covers all parameters. It does not explain what the generated bitstream is used for or what the return value contains, but the output schema is expected to handle return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does this by listing all five parameters (impl_run, jobs, timeout_minutes, force, session_id) with brief explanations and defaults. The meaning of 'force' is clarified as skipping the CRITICAL WARNING safety check, which is valuable semantic context. However, 'session_id' is only described as 'target session ID', which is somewhat vague and could benefit from more explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '生成比特流文件' (generate bitstream file) and specifies when it runs ('在实现完成后执行', after implementation completes). This distinguishes it from sibling tools like run_synthesis and program_device, which operate at different stages. The verb + resource is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear timing guidance: the tool should be executed after implementation is complete. It also explains the default safety check that blocks generation on CRITICAL WARNING and how to override it with force=True. However, it does not explicitly mention alternatives or exclusions (e.g., not to use before implementation), but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that it avoids blocking Tcl wait_on_run due to GUI freeze, polls STATUS/PROGRESS every 2 seconds when waiting, and returns a job_id immediately when wait=False. Missing details include return value for wait=True, error handling, and preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, a focused explanation of wait behavior and rationale, and a clear Args list. Every sentence adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so missing return descriptions are not penalized. However, preconditions (e.g., synthesis must be completed first) and postconditions (what 'diagnose' entails) are not addressed. The timeout behavior is only mentioned as a parameter, not what occurs on timeout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining all 5 parameters in the Args section (run_name, jobs, timeout_minutes, session_id, wait) with their defaults and meaning. It does not provide constraints or examples, but the explanations are clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '启动实现（布局布线）' (start implementation/place-and-route), using a specific verb and resource. It distinguishes itself from siblings like run_synthesis and generate_bitstream by naming the implementation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use wait=True vs wait=False and directs the user to query with get_run_progress after async submission. However, it does not explicitly state that synthesis should be run first or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the volatile nature of .bit programming and outlines the internal sequence (open_hw_manager → connect → program). It also provides a comprehensive flash recipe, shedding light on what the tool does not do. However, it does not mention potential side effects like interrupting a running design or requiring a live hardware server.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and scope, but the extensive flash recipe adds significant bulk. While the recipe is useful, it is tangential to the tool's own parameters and could be summarized or referenced. The core description is efficient, but the overall length reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides rich context for a hardware programming tool: it clarifies the volatile/flash distinction, gives a full alternative procedure, and defines all parameters. It does not mention prerequisites like hardware server availability or error handling, but the presence of an output schema reduces the need to explain return values. Overall, it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains every parameter: bitstream_path as the .bit file, target as a filter defaulting to the first device, hw_server_url as the server address, and session_id as target session ID. This exceeds the bare schema, though target filter syntax and session ID requirements could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with '编程 FPGA 设备' (program FPGA device), clearly stating the verb and resource. It further specifies that it wraps the multi-step open_hw_manager → connect → program operation and explicitly notes it only burns .bit files to FPGA, distinguishing it from flash programming and sibling tools like generate_bitstream.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: use this tool for volatile .bit programming, and for persistent boot use the provided SPI flash recipe via run_tcl. It even includes step-by-step TCL commands as an alternative, making the distinction clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well by disclosing the escaping mechanism (tcl_quote), placeholder syntax, and default session/timeout values. It misses any mention of error handling or side effects, but the safety-critical behavioral context is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with opening summary, use cases, examples, and parameter list. It is slightly verbose with repeated emphasis on escaping, but every element contributes to clarity and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of annotations, the description covers primary use cases, parameter semantics, and security behavior. It does not address error handling or explicitly contrast with run_tcl, but the presence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining each parameter: template placeholders, args escaping behavior, session_id default, and timeout default. Concrete examples illustrate usage, adding significant meaning beyond raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes parameterized Tcl command templates with automatic escaping using Tcl list rules, giving specific verb+resource. The examples further clarify its purpose and implicitly differentiate it from raw Tcl execution tools like run_tcl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly lists applicable scenarios (commands with file paths, port names, string values containing special characters) and highlights prevention of injection and parse errors. However, it does not explicitly say when NOT to use it or compare it directly with sibling tools like run_tcl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the tool auto-reads XDC files, supports both -dict and traditional syntax, compares with report_io, and classifies mismatches as CRITICAL (GT) or WARNING (GPIO). This provides clear behavioral insight beyond what structured fields offer, though it does not explicitly state read-only or side effects (likely none for a verification tool).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose statement, detailed behavior, severity rules, then parameter list. It is front-loaded with the main action and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (reads XDC, compares with report_io, outputs severity). The description covers what it does and its severity logic. It does not mention prerequisites (e.g., whether report_io must already be generated) or return structure, but since an output schema exists (context indicates), the description needn't detail return values. Overall, it's sufficiently complete for an agent to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (session_id) with no description in the schema (0% coverage), so the description must compensate. It provides a concise but adequate meaning: '目标会话 ID' (target session ID). For a single optional param with a default, this is sufficient, though it could have added more context about how session_id affects which XDC/report is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '验证 IO 引脚分配' (verify IO pin assignment) and specifies it compares XDC constraints with actual layout. It distinguishes itself from siblings like xdc_lint (syntax checking) and get_io_report (report retrieval) by focusing on the comparison and error detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to verify IO pin consistency between XDC and actual placement) and gives context (reads PACKAGE_PIN constraints, compares with report_io). However, it does not explicitly state when not to use it or name alternative tools, but the purpose is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool performs static analysis without requiring Vivado, lists the exact error codes checked, and describes the auto-discovery behavior when xdc_paths is omitted. This gives a clear picture of the tool's behavior and non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but well-structured, with a clear intro, a useful bullet list of detectable errors, and an Args section. Each line contributes value, for example the error list helps the agent understand capabilities. It is slightly longer than strictly necessary but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two optional parameters and an output schema, so the description does not need to explain return values. It provides complete context: the tool's purpose, when to use it, the parameters' behavior, and the expected error types. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types with no descriptions (0% coverage). The description's Args section fully compensates by explaining xdc_paths and session_id in detail, including the default auto-grab behavior and when session_id is used. This provides complete parameter semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a static checker for XDC constraint files, listing the specific error patterns it detects. This distinguishes it from synthesis, implementation, and other sibling tools. The mention of being pure Python and not relying on Vivado synthesis further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends running this tool before synthesis to catch common errors and avoid the 30+ second synthesis wait, providing a clear usage context. It does not explicitly name alternative tools or exclusion cases, but the timing and benefit are well communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses specific checks performed (route_design completion, critical warning count, timing closure) and maps them to the three outcomes. It also explains the implication of critical warnings. Since no annotations are provided, the description fully carries the transparency burden, and it does so thoroughly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a title, rationale, bulleted checks, outcomes, and args. Every section contributes useful information, though the Args section repeats schema defaults, creating mild redundancy. Overall, it is appropriately sized and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple nature, the presence of an output schema, and the description's coverage of when to use, what is checked, and what outputs mean, it is fully complete. The description would be sufficient even without the output schema, and with it, all necessary context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only parameter names and defaults with no descriptions. The description adds one-line explanations for impl_run (implementation run name) and session_id (target session ID), which are slightly more informative than the parameter names alone. However, it does not explain valid values or how they affect the check, so it only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this is a pre-flight check that evaluates whether a project can safely generate a bitstream, returning READY/BLOCK/WARN. It distinguishes itself from sibling tools like generate_bitstream and program_device by being a pre-check. The slight inconsistency between PASS and READY does not undermine the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool before generate_bitstream or program_device, preventing issues after board burn. This provides clear contextual guidance. The 'before...' formulation effectively indicates when to use it, and alternatives are implied by the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool directly reads XML files and does not require a Vivado session, implying a non-destructive read operation. It also explains the default behavior of the show_all parameter. However, it does not explicitly mention whether any writes or modifications occur, though the read-only nature is strongly implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a high-level summary, followed by use cases, and then parameter details. Each sentence adds value without redundancy. The front-loaded purpose makes it easy to scan, and the parameter bullets are clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema, the description adequately covers the input semantics, use cases, and the show_all flag. It does not need to describe return values because the output schema already provides that. The description is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's parameter explanations are essential. It defines file_a as the baseline/normal configuration and file_b as the to-be-checked/abnormal configuration, adding directional meaning that the schema lacks. It also clarifies show_all's default false behavior, fully compensating for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: comparing IP configuration differences between two XCI files. It uses a specific verb ('对比') and resource ('两个 XCI 文件的 IP 配置'), and distinguishes itself from sibling tools like inspect_ip_params by focusing on comparison rather than single-file inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use scenarios: version comparison, board migration validation, and debugging IP parameter differences. It also notes that no Vivado session is required, helping the agent decide when to use this tool. However, it does not explicitly name alternative tools for cases where this tool is not suitable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes what the tool lists (upgrade-needed, locked, up-to-date IPs) and explains the IS_LOCKED attribute, giving useful technical context. It also mentions upgrade suggestions as part of the output. It does not explicitly state it is read-only, but the wording implies inspection and not mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the main purpose front-loaded and bullet points listing the tool's outputs. The background about Vivado prompts earns its place as useful context. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter, no annotations) and the presence of an output schema, the description provides ample context: what the tool does, when to use it, what it returns, and parameter meaning. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description coverage for the single parameter, but the description includes 'Args: session_id: 目标会话 ID。' which clearly explains the parameter's purpose. This fully compensates for the lack of schema description, adding meaning beyond the schema's minimal type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the version status of all IPs in the project, listing those that need upgrade, are locked, or are up to date. This specific verb+resource+scope distinguishes it from siblings like compare_xci and inspect_ip_params, which focus on other aspects of IP/project inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: when opening an old project and Vivado prompts that IPs need upgrade. It does not explicitly list exclusions or alternative tools, but the context makes it evident when to use this tool over others, satisfying the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly indicates an advisory role through '推断' and '建议', and fully discloses its decision logic. However, it does not explicitly state that it performs no side effects or how it handles invalid session IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear purpose sentence, a usage context, a bulleted decision list, and an Args section. Every sentence is informative, and the rules are compact and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the entire decision logic, the parameter, and usage scenarios. Since an output schema exists, return value details are unnecessary. The tool is fully self-described 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for session_id, but the description explicitly documents it as '目标会话 ID' (target session ID). This fully compensates for the 0% schema description coverage and adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states '根据当前项目状态推断下一步应该做什么' (infer next actions based on current project state), which is a specific verb and resource. It further differentiates from siblings by listing a decision tree that recommends distinct tools like open_project, run_synthesis, and generate_bitstream, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states it is '适合新手、刚打开老项目、或者不知道从哪下手的场景' (suitable for beginners, old projects, or unsure where to start), providing clear context. The decision rules also name alternative tools for each scenario, but it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 does well by disclosing that it reads runme.log and reports the last log update time to judge whether Vivado is active. It also enumerates the types of information returned. While it doesn't explicitly state 'read-only', the 'get' prefix and progress-monitoring intent make that implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a bulleted list of what the tool returns, and a clear 'Args' section. Every sentence provides useful information without redundancy. It is appropriately detailed for a tool with three parameters and no annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relatively simple purpose and the presence of an output schema, the description is complete. It explains the use case, what data is shown, and parameter meanings. It also provides enough context to differentiate it from sibling tools like get_critical_warnings, even though it does not name alternatives explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does: run_name is described with examples and default ('synth_1'/'impl_1'), tail_lines is defined as how many log lines to read, and session_id is identified as the target session ID. All three parameters are meaningfully documented beyond their schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查看 run 的运行进度' (view run progress) and elaborates with a specific use case ('适合长任务等待时看走到哪一步'). It lists concrete outputs (status, progress percentage, phases, log tail, update time), distinguishing it as a monitoring/read tool rather than a synthesis/implementation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: during long-running tasks (10-30 minutes) when you want to check progress without opening the GUI. It does not explicitly contrast with alternatives like get_critical_warnings, but the context is clear enough for an AI agent to select this tool for progress checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses key behavioral traits: completely offline, no board connection or Vivado launch required, and that .ltx files are JSON format for Vivado 2019.1. It does not explicitly mention error handling or side effects, but for a read-only parse tool, the offline and format details are sufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear, front-loaded summary of the tool's purpose. Each additional sentence adds context (use case, alternative, file format, arguments), but the middle sentence about 'set_property TRIGGER_COMPARE_VALUE' is somewhat verbose and could be tightened. Overall it's appropriately sized with no irrelevant filler, but it leans slightly wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, and an existing output schema), the description is remarkably complete. It covers the tool's purpose, when to use it, the alternative, the parameter semantics, and the file format. The output schema handles return-value details, so the description need not explain those. This is a well-rounded, self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with only a raw string type for file_path. The description compensates by stating '.ltx 文件的绝对路径' (absolute path of the .ltx file), adding meaning beyond the schema: the file extension and absolute path requirement. This directly addresses the parameter's meaning and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: offline parsing of ILA debug probe files (.ltx). It specifies the exact resource (ILA debug probe file), the verb (离线解析/parse), and the context (no board/Vivado needed). This distinguishes it from sibling tools like parse_xpr and parse_bit_header, which target different file types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool: before board-connected ILA capture, to get an offline inventory of probes. It names the alternative (get_hw_probes) and states why this tool is better in that scenario: get_hw_probes requires a board and a live hardware session, while this tool is fully offline. This provides clear usage guidance and comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the blocking concern, the 2-second polling interval, progress reporting, and the immediate return of job_id for async mode. However, it does not mention side effects such as whether an existing run is overwritten, permissions required, or failure behavior beyond the vague 'diagnose' term.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial summary, a behavioral note, and a clear Args list. It's somewhat longer than minimal but every sentence adds value, particularly the explanation of the event-loop issue and parameter semantics. It earns its length without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow (sync/async), all parameters, and references get_run_progress for follow-up. An output schema exists, so return values need not be detailed. Gaps include the precise meaning of 'diagnose' and preconditions like active session, but overall it is sufficiently complete for a synthesis launch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully by explaining all five parameters (run_name, jobs, timeout_minutes, session_id, wait) with their meanings and defaults. This is exactly what the schema lacks, making the description the primary source of parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: '启动综合' (start synthesis). It also distinguishes itself by explaining both synchronous (wait=True) and asynchronous (wait=False) behavior, which differentiates it from sibling tools like run_implementation and get_run_progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when/when-not usage: wait=True waits for completion and diagnoses, while wait=False immediately returns job_id and directs the user to use get_run_progress for status. It also explains why it doesn't call Tcl wait_on_run (to avoid blocking the Vivado event loop), giving clear rationale for the recommended polling approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so richly: it discloses process spawning, TCP server injection via -source, port 9999 probing, session reuse behavior, and the warning that omitting port will attach to the same GUI rather than create a new one. This is exactly the kind of non-obvious behavioral context agents need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a mode list and an Args block, and every major section adds value. It is lengthy and dense, especially the port semantics (including the 'B 方案' reference), which makes it slightly heavier than ideal for quick consumption, but it remains organized and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 5 parameters, no annotations, and no per-parameter schema descriptions, yet the description covers modes, session lifecycle, port probing, custom path, and timeout. An output schema exists, so return-value details are unnecessary. The description is complete enough for correct tool invocation without any external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: the Args block explains session_id, mode, port, vivado_path, and timeout, and adds critical port semantics including port=0 for allocating a fresh instance. This fully replaces what would normally be in parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '启动一个新的 Vivado 会话' (start a new Vivado session), stating a clear verb and resource. It distinguishes itself from siblings like stop_session and list_sessions by focusing on the launch/creation aspect, and further clarifies the three operating modes (gui, tcl, attach).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit for choosing modes: 'tcl' for headless CI/batch, 'attach' for connecting to an existing GUI, and 'gui' as the default. Port semantics for multi-instance vs reuse are also spelled out in detail. It lacks explicit 'do not use' exclusions, but the alternatives are clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It reveals key behavioral traits: it is pure Python, runs fully offline, and does not start Vivado, avoiding known crashes. It also lists the exact data it extracts (part, top, source files, XDC, runs). However, it does not explicitly state it is read-only or what happens with malformed .xpr files, leaving a small gap in completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and information-dense: it starts with purpose, then usage context, then extracted data, and ends with parameter details. Every sentence adds value, and it avoids redundancy or filler. Despite its length, it remains focused and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (multiple output categories) and the presence of an output schema, the description covers all needed context: what the tool does, when to use it, how it differs from alternatives, and the parameter semantics. The output schema handles return structure, so the description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly documents the only parameter: 'file_path: .xpr 工程文件的绝对路径', which adds the crucial requirement of an absolute path beyond the schema's bare 'File Path'. This fully compensates for the lack of schema description and leaves no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('离线解析 Vivado 工程文件(.xpr)') and resource (.xpr files), and explicitly distinguishes from sibling get_project_info by noting that this tool is fully offline while the alternative requires start_session and open_project. This makes the purpose unambiguous and differentiates from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases ('秒级摸底陌生工程 / CI 门禁') and contrasts with get_project_info, providing clear guidance on when to use this tool (offline, no Vivado) versus alternatives (session-based tools). It also mentions avoiding 120s GUI cold start and TclStackFree crash, which are specific reasons for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers the tool's behavior: dry-run preview mode, backup creation per file, .bak only keeping the latest version before write-back (with sed -i.bak semantics), insertion logic for IOSTANDARD after PACKAGE_PIN, and skipping CLOCK_NO_PERIOD when the board is unknown. It also states which issue types are intentionally not handled, making side effects and boundaries explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a main purpose, operational notes, explicit inclusion/exclusion lists, and a parameter breakdown. It is concise for the complexity involved, with every sentence contributing to understanding or safe usage. The use of bullets and clear headings (e.g., '只修', '绝对不碰') aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating files, multiple parameters, safety implications) and lack of annotations, the description is exceptionally complete. It explains side effects (backup, overwrite), edge cases (unknown board), and provides a safe workflow. The presence of an output schema means return-value details are not required, and the description covers all other necessary contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains every parameter: xdc_paths (list, defaults to session project), board (supported values and fallback to LVCMOS33), dry_run (preview vs write-back), and session_id (used only when xdc_paths is omitted). It adds default values and cross-parameter dependencies, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it automatically fixes self-safely fixable issues in XDC files, specifically MISSING_IOSTANDARD and CLOCK_NO_PERIOD. It distinguishes itself from sibling tools by explicitly limiting its scope to these two issue types and stating it never touches conflict-related problems (PIN_CONFLICT, DUPLICATE_PORT, etc.), which require manual intervention.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it only fixes the two listed issue types and absolutely avoids conflict categories. It also gives a clear workflow: use dry_run=True to preview, then dry_run=False to apply. However, it does not explicitly name sibling tools as alternatives (e.g., xdc_lint for broader linting), so it misses the 'alternatives' part of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It is exceptionally transparent: it reveals silent snapshot writes ('.vmcp/' or fallback), the exclusion of sim mode from snapshotting, log tailing behavior (tail_n), and the fallback scan for non-standard error keywords like TclStackFree/segfault/FATAL. It even discloses the limitation of runme.log for simulation runs and points to the actual xsim log location.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, the description is densely structured with numbered modes and bolded key terms, front-loading the core purpose and then systematically detailing each mode and parameter. Every sentence adds operational value—no filler. The format uses Markdown headers and lists to improve scannability for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive for a complex diagnostic tool: it covers the main flow, edge cases (errors=0 but STATUS contains ERROR), mode-specific behavior (sim vs impl), snapshotting and comparison, and parameter details. An output schema exists, and the description also clarifies return content (Chinese diagnostic report with labels and repair suggestions). Even without review of the output schema, the description provides sufficient context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It richly explains run_name (including mode routing), compare_with_last (diff report), and tail_n (range and per-sub-log behavior). However, session_id is only described as '目标会话 ID' (target session ID), which adds little beyond the parameter name itself, leaving a minor gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: '提取并分类 CRITICAL WARNING / ERROR / 非标错误' (extract and classify critical warnings/errors/non-standard errors) and positions itself as a '统一失败诊断入口' (unified failure diagnosis entry). It clearly distinguishes itself from sibling monitoring/diagnostic tools like get_run_progress and get_timing_report by focusing on warning/error classification with actionable repair advice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance by describing three automatic diagnostic modes based on run_name (synth_*/impl_* vs sim_*). It explains when the tool is needed, e.g., '解决 messageDb 显示干净但 run 实际崩了' (solves the blind spot where messageDb looks clean but the run actually crashed), and clarifies that sim_* goes to a different log location. It also mentions compare_with_last behavior, giving clear context on when to use the diff functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 is exceptionally transparent: it explains that timeout only stops MCP waiting, not command execution; it documents many silent XSim pitfalls (e.g., add_wave_group requiring -into, escaped-id rejection, get_scopes multi-path failure, size filters being ineffective); and it warns about set_property RADIX case-sensitivity and other silent traps. This goes far beyond a typical description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very long, but it is well-structured with clear sections (general examples, XSim pitfalls, set_property/radix traps) and front-loaded with the core purpose. It is information-dense and every section provides practical value, though it is verbose enough to be a token burden for an LLM; slight trimming would make it more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity, zero schema coverage, and no annotations, the description is remarkably complete. It covers when to use alternatives, parameter semantics, timeout behavior, known bugs, silent failure modes, and concrete workarounds. The presence of an output schema means return values need not be described in detail, and the description exceeds what is necessary for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: command is explained as Tcl text with multiline support and many examples; session_id is labeled as target session with default 'default'; timeout is explained with default 120 and detailed semantics about how timeout behaves (MCP stops waiting but command continues in Vivado). This gives the agent far more parameter understanding than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '执行任意 Vivado Tcl 命令' (execute any Vivado Tcl command), and explicitly lists supported domains with concrete examples. It distinguishes itself from siblings by naming safe_tcl as an alternative for paths with special characters and referring long-running tasks to dedicated tools like run_synthesis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it is the most generic tool for any Vivado Tcl command. It gives clear exclusions: use safe_tcl for special-character paths, and use run_synthesis/run_implementation/generate_bitstream for long tasks. It also explains timeout semantics with behavioral consequences, helping the agent decide when to set a larger timeout or use a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that the tool is '只读文件头(不读 payload)' (read-only header, does not read payload), indicating no side effects. It also details the normalization behavior (removing 'xc' prefix and speed grade, restoring 'xc' but not speed grade), which is a key behavioral trait affecting output interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and front-loaded: it opens with the core purpose, then details the extracted fields, use cases, a key caveat, and finally the argument. Every sentence adds value without redundancy; it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be repeated, but the description still explains the extracted fields and the part-normalization caveat, giving the user enough context to interpret results. It also covers usage scenarios and limitations, making it complete for a read-only header parser.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only specifies 'file_path' as a string with no description (0% coverage). The description compensates fully by stating 'Args: file_path: .bit 文件的绝对路径' (absolute path of the .bit file), adding a crucial requirement beyond the schema's type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '离线解析 .bit 比特流文件头部' (offline parse .bit bitstream file header), with a specific verb and resource. It also enumerates the extracted fields (design name, target part, build date, SHA256), distinguishing it from siblings like parse_xpr and parse_ltx by file type and offline nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: '用于烧录前防错板(part 比对)、交付/返修对账' (for pre-programming board error prevention via part comparison, and delivery/repair reconciliation). It also notes that 'Vivado 无任何 Tcl 命令读离线 .bit' (Vivado has no Tcl command to read offline .bit), implying this is the only option, and provides a practical limitation about part-level comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It reveals multiple silent pitfalls: bare 'ANALOG' isn't rendered, get_waves doesn't match full paths, set_wave_prop silently succeeds on empty objects, min/max must be paired, and no Tcl readback is possible. These are crucial behaviors beyond what schema or annotations could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, the description is well-structured with bullet points and warnings. Every sentence adds local knowledge or constraints that cannot be derived from schema. It front-loads the core purpose and separates pitfalls, ordering, and parameters logically. No redundant or vague sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter tool with high complexity and no annotations, the description covers all necessary context: ordering constraints, parameter semantics, silent failure modes, and verification limitations. The presence of an output schema means return values don't need elaboration, but the description still addresses verification by saying 'render please confirm visually'. It is fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates completely. Each parameter is given meaningful semantics: signals can be short/full paths and must be added; min/max must be explicitly supplied in pairs; interp is whitelisted; height corresponds to CellHeight in wcfg; session_id targets a session. This exceeds schema's bare type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets signals to Analog waveform display in Vivado, with a specific verb and resource. It distinguishes itself from siblings like set_wave_zoom by focusing on analog properties rather than zoom. The added context about resolved signal names and rendering makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the hard ordering constraint ('must be called after set_wave_zoom') and explains why, along with prerequisite signals must be added. It also notes when automatic amplitude calculation is not supported. This gives clear when-to-use context, plus a reference to a sibling tool, though it doesn't name alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it modifies the wcfg XML and triggers a reload, it does not auto-save (avoiding unsolicited disk writes), it returns an error when wcfg is unsaved, and it discards unsaved live wave properties due to close -force. These side effects are explicitly warned, going beyond generic descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the primary purpose, followed by rationale, warnings, and parameter details. Each section earns its place: the protocol explanation is necessary for correct usage, and the Args block is clear. Despite the length, it remains well-structured and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step XML editing and reload protocol, multiple side effects, prerequisites), the description is remarkably complete. It covers error conditions, ordering with sibling tools, unsaved file handling, and parameter semantics. The presence of an output schema means return values need not be described, so no essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description takes full responsibility for parameter documentation. It explains start_ns and end_ns (with the constraint start < end), wcfg (explicit path or auto-resolution), and session_id. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the waveform time zoom window. It explains the mechanism (modify wcfg XML then close -force + open reload), and distinguishes itself from sibling set_wave_analog by focusing on zoom rather than analog properties. The verb '设置' plus the specific resource '波形时间缩放窗口' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, including the prerequisite that the wcfg must be saved (error if not, requiring save_wave_config), and the ordering constraint to call set_wave_zoom before set_wave_analog. It also explains the pitfalls of the reload sequence (missing -force or opening an already-open wcfg). This is detailed operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool returns SKIP with installation guidance when iverilog/verilator are missing, returns SKIP for VHDL files with alternative guidance, and notes that iverilog -t null produces no artifacts. It also documents both tool modes and timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded, starting with purpose and typical use, then covering installation, modes, and parameters. Every section serves a purpose and no content is filler; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of an output schema, and the fact that this description lacks annotations, it is remarkably complete. It covers input requirements, tool selection, timeout, unsupported files, and failure modes, leaving no critical ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully compensates by explaining every parameter: files accepts .v/.sv and rejects .vhd/.vhdl with a SKIP, tool supports auto/iverilog/verilator with default auto, and timeout is subprocess timeout defaulting to 30. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs Verilog syntax and connectivity checks using iverilog/verilator, and positions it as a fast alternative to Vivado synthesis. This is a specific verb+resource combination that distinguishes it from synthesis-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly indicates when to use the tool (after writing/modifying RTL, for quick verification before synthesis) and when not to use it (for .vhd/.vhdl files, where it returns SKIP and recommends check_syntax). It also explains behavior when tools are not installed, providing clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vivado-mcp MCP server](https://glama.ai/mcp/servers/mapleleavessssssss-wq/vivado-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mapleleavessssssss-wq/vivado-mcp)

Score Badge

Copy to your README.md:

[![vivado-mcp MCP server](https://glama.ai/mcp/servers/mapleleavessssssss-wq/vivado-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mapleleavessssssss-wq/vivado-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mapleleavessssssss-wq/vivado-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server