vivado-mcp

get_timing_report

Retrieve structured timing summary and critical path details from Vivado reports. Compare against a baseline to see context-matched timing differences; output as text or JSON.

Instructions

获取结构化时序报告。

执行 report_timing_summary 并解析为结构化摘要 + 关键路径详情。默认返回中文摘要；JSON 模式返回可保存的版本化证据。report_file 可离线读取 UTF-8 Vivado 原始报告，无需会话。基线比较只给上下文匹配的观察差值，不证明约束等价或完整签核；本工具不写文件。

Args: session_id: 目标会话 ID。 output_format: text（默认）或 json；json 模式错误也返回 JSON。 report_file: 可选原始时序报告路径，最多 16 MiB；不是 JSON 快照。 baseline_file: 可选之前保存的完整 JSON 返回值路径，最多 4 MiB。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_timing_report"
  }
}

Input Schema

Name	Required	Default
`session_id`	No	default
`report_file`	No
`baseline_file`	No
`output_format`	No	text

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.3.26Sep 23, 2026

addedInput schema / properties / baseline_file

Added value: +{
+  "default": "",
+  "title": "Baseline File",
+  "type": "string"
+}

addedInput schema / properties / output_format

Added value: +{
+  "default": "text",
+  "title": "Output Format",
+  "type": "string"
+}

addedInput schema / properties / report_file

Added value: +{
+  "default": "",
+  "title": "Report File",
+  "type": "string"
+}

First observedv0.3.25Aug 12, 2026

TDQS

A4.8/5.0

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 executes report_timing_summary, never writes files, supports offline parsing, returns JSON errors in JSON mode, and warns that baseline differences are not proof of constraint equivalence or full signoff.

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 compact and well-structured: purpose first, then behavioral caveats, then a clear Args block. Every sentence adds useful information with no filler or repetition.

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 complexity of optional modes and file inputs, the description covers all important operational aspects: session or offline file input, output format behavior, size limits, baseline limitations, and non-persistence. The existence of an output schema covers return value structure, so no further detail is needed.

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%, but the description compensates fully by explaining every parameter: session_id, output_format with text/json behavior, report_file as a raw text path up to 16 MiB (not a JSON snapshot), and baseline_file as a prior JSON return path up to 4 MiB. This adds meaning far beyond the 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 fetches and parses a structured timing report by executing report_timing_summary, with key path details. This specific verb+resource combination distinguishes it from sibling tools like get_io_report and get_cdc_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 gives clear contextual guidance: report_file enables offline use without a session, JSON mode produces savable evidence, and baseline comparisons are only observational. It does not explicitly name sibling alternatives or state when not to use this tool, but the usage conditions are clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.