起動時にサーバーは MCP クライアントの環境を継承し、which openroad と同じ方法で PATH を補完します: 現在の PATH、次にログインシェルの PATH、次に一般的なインストール場所 (/opt/homebrew/bin、conda、ローカルの OpenROAD ビルド) です。ORFS_FLOW_PATH はデフォルトで ~/OpenROAD-flow-scripts/flow になり、ORFS が openroad バイナリの隣にある場合も検出されます。

サポートされている MCP クライアント

以下は、ほとんどのクライアントで使用される標準の基本設定です。

{
  "command": "npx",
  "args": ["-y", "openroad-mcp"]
}

正確な設定スニペットとファイルの場所については、以下の特定のクライアントを参照してください。

claude mcp add --transport stdio openroad-mcp -- npx -y openroad-mcp

または、標準設定を .mcp.json / .claude/settings.json に追加します。

GUI 起動のクライアントが openroad を見つけられない場合は、オーバーライドを渡してください。パスをハードコードしないように command -v を使用します:

claude mcp add \
  --env PATH="$(dirname "$(command -v openroad)"):${PATH}" \
  --env ORFS_FLOW_PATH="${HOME}/OpenROAD-flow-scripts/flow" \
  --transport stdio openroad-mcp \
  -- npx -y openroad-mcp

CLI がサーバー名を別の KEY=value ペアとして扱わないように、--transport を --env とサーバー名の間に配置します。

標準設定を以下に追加します:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

標準設定を .cursor/mcp.json に追加します。

.vscode/mcp.json に追加します。"type": "stdio" が必要です:

{
  "servers": {
    "openroad-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "openroad-mcp"]
    }
  }
}

標準設定を ~/.codeium/windsurf/mcp_config.json に追加します。

標準設定を cline_mcp_settings.json (Cline) または .roo/mcp.json (Roo Code) に追加します。

それぞれの config.json の modelContextProtocolServers に追加します:

{
  "transport": {
    "type": "stdio",
    "command": "npx",
    "args": ["-y", "openroad-mcp"]
  }
}

~/.config/zed/settings.json に追加します:

{
  "context_servers": {
    "openroad-mcp": {
      "command": {
        "path": "npx",
        "args": ["-y", "openroad-mcp"]
      }
    }
  }
}

サーバーは MCP Registry および Docker 経由で利用できます:

docker run --rm -i ghcr.io/the-openroad-project/openroad-mcp:latest

その他の標準的な STDIO クライアントもすべてサポートされています。お使いのツールの MCP セットアップガイドを参照してください。

利用可能なツール

設定が完了すると、AIアシスタントは以下のツールにアクセスできます。詳細なパラメータ、スキーマ、戻り値の形式については、API リファレンス を参照してください。

interactive_openroad_query
interactive_openroad_exec
create_interactive_session
list_interactive_sessions
terminate_interactive_session
inspect_interactive_session
get_session_history
get_session_metrics
list_report_images
read_report_image

トラブルシューティング

サーバーが起動しない: Node.js 22+ がインストールされていることを確認してください。古いバージョンでは失敗します。
セッションの作成に失敗する: ターミナルで command -v openroad が動作することを確認してください。サーバーは PATH を継承し、一般的なインストール場所を検索します。プレフィックスが通常と異なる場合は、Claude Code のセクションに示されているように --env で PATH を渡してください。
CommandBlocked でコマンドが拒否される: interactive_openroad_query に状態を変更するコマンドを送信しました。代わりに interactive_openroad_exec を使用してください。
レポート画像が見つからない: サーバーはデフォルトで ~/OpenROAD-flow-scripts/flow を使用します。ORFS が別の場所にある場合は、MCP クライアントの env ブロック (.env ファイルではない) で ORFS_FLOW_PATH を設定してください。

詳細を取得するには、サーバーの環境で LOG_LEVEL=DEBUG を設定してください。

開発

リポジトリをクローンします。.env.example はローカル開発用の参照のみです。direnv などを使用する場合は .env にコピーしてください。サーバーはファイルではなく process.env (MCP クライアントの env ブロック) を読み取ります。

次に実行します:

cd typescript
npm install
npm run build

テスト:

npm run test             # unit tests
npm run test:integration # integration tests
npm run test:performance # performance benchmarks

リンティングと型チェック:

npm run typecheck
npm run lint

貢献

貢献を歓迎します! 開発ワークフローとコード標準の詳細については、CONTRIBUTING.md を参照してください。

ライセンス

BSD 3-Clause License。 LICENSE ファイルを参照してください。

Precision Innovations によって ❤️ を込めて作られました

Available Tools

10 tools

create_interactive_sessionC

Create a new interactive OpenROAD session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No
`command`	No
`env`	No
`cwd`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are unhelpful (all false) and the description does not disclose side effects, resource allocation, or required permissions. It merely states 'Create', which is already obvious from the name, and adds no behavioral context beyond the annotations.

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 a single sentence with no unnecessary words. It is appropriately concise, though it sacrifices completeness for brevity.

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?

For a tool with four parameters, no schema descriptions, and no usage guidance, the description is insufficient. It does not explain output behavior or return value, despite having an output schema. The description lacks necessary context for correct use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain any of the four parameters (cwd, env, command, session_id). Schema description coverage is 0%, and the description fails to compensate, leaving the agent with no insight into parameter meaning or usage.

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 verb 'Create' and the resource 'new interactive OpenROAD session', which distinguishes it from sibling tools like terminate_interactive_session and list_interactive_sessions. It is specific 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 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, prerequisites, or when not to use it. It does not mention any alternatives or context for invocation.

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

get_session_historyC

Read-onlyIdempotent

Get command history for an interactive OpenROAD session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`limit`	No
`search`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, safe operations. The description adds the session context but omits behavioral details like behavior on invalid session IDs or performance implications.

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?

Single sentence with no excess, but too sparse to provide useful guidance. Could include key details without becoming verbose.

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?

Despite an output schema existing, the description lacks context on when history is available, how it relates to sibling tools, and limitations like pagination or size limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the three parameters (limit, search, session_id). The agent must infer meaning from parameter names 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 clearly states the tool retrieves command history for an interactive OpenROAD session, distinguishing it from siblings like get_session_metrics or inspect_interactive_session.

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?

No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, such as requiring an active session, or contrast with similar tools.

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

get_session_metricsB

Read-onlyIdempotent

Get comprehensive metrics for all interactive OpenROAD sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds only 'comprehensive metrics for all sessions,' without further behavioral detail (e.g., performance impact, whether sessions must be active). The description does not contradict annotations.

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, concise sentence with no extraneous words, directly stating the tool's purpose.

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?

Given zero parameters, output schema exists, and annotations are present, the description covers the core purpose. However, it lacks details about the metrics scope (e.g., active vs. all sessions) and does not reference the output schema for completeness.

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?

No parameters exist (100% schema coverage), and the description adds no semantic detail beyond the schema's implicit meaning. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets 'comprehensive metrics for all interactive OpenROAD sessions,' which distinguishes it from siblings like get_session_history (per-session history) and list_interactive_sessions (just listing). However, it does not explicitly differentiate from inspect_interactive_session, which might also provide metrics.

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?

No guidance on when to use this tool versus alternatives such as list_interactive_sessions or get_session_history. The description lacks explicit context for selection or exclusion criteria.

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

inspect_interactive_sessionA

Read-onlyIdempotent

Get detailed inspection data for an interactive OpenROAD session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds minimal behavioral context. It does not elaborate on what data is returned or any side effects, but it does not contradict annotations.

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 a single concise sentence with no redundancy. However, it could be slightly expanded to add parameter context without losing conciseness.

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?

Given the low complexity (1 param, output schema present), the description is adequate but lacks guidance on how to obtain the session_id or what 'detailed inspection data' specifically includes. It meets minimum viability.

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?

The only parameter session_id is described by its type but the description does not explain its purpose or origin (e.g., from list_interactive_sessions). With 0% schema description coverage, the description should compensate but does not.

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 action (Get) and the resource (detailed inspection data for an interactive OpenROAD session). It distinguishes this tool from siblings like get_session_history or get_session_metrics by using 'detailed inspection data'.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites or scenarios, leaving the agent to infer from the purpose.

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

interactive_openroad_execA

Destructive

Execute a state-modifying OpenROAD command (set_*, create_*, read_*, write_*, flow commands).

Use this for loading designs, running placement/routing, applying constraints, and writing output files. Read-only commands are blocked — use interactive_openroad_query instead.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes
`session_id`	No
`timeout_ms`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructive hint. The description adds context by specifying state-modifying nature, listing command types (set_*, create_*, etc.) and use cases (loading designs, placement/routing), enhancing 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?

Two concise sentences with effective front-loading: the first states the core function, the second gives usage context and alternative tool. No unnecessary words.

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?

Despite good purpose and usage guidelines, the description lacks parameter explanations and does not cover session management or timeout behavior. With three parameters and no schema description, the tool is incompletely documented for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no information about the three parameters (command, session_id, timeout_ms). Schema description coverage is 0%, and the description fails to compensate, leaving the agent without guidance on parameter usage.

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 executes state-modifying OpenROAD commands and lists examples, distinguishing it from the sibling query tool by explicitly excluding read-only commands.

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 to use (state-modifying commands) and when not (read-only commands), directing to interactive_openroad_query as the alternative.

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

interactive_openroad_queryA

Read-only

Execute a read-only OpenROAD command (report_*, get_*, check_*, sta, help, etc.).

Use this for querying design state, generating reports, and inspecting timing. Commands that modify design state are blocked — use interactive_openroad_exec instead.

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes
`session_id`	No
`timeout_ms`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description reinforces that by stating modifying commands are blocked. It also names the sibling for mutable operations, adding context beyond annotations. No contradiction.

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?

Two focused sentences: first defines the tool and lists example commands, second provides usage boundaries and alternative. No extraneous information; every word adds value.

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?

The tool has an output schema (context indicates present) and 3 parameters, yet the description omits output semantics and parameter details. While purpose and usage are clear, the lack of parameter documentation leaves the description incomplete for an agent to correctly invoke the tool without additional inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 3 parameters (command, session_id, timeout_ms) with 0% schema description coverage. The description does not mention or explain any of these parameters, leaving the agent with no semantic guidance beyond the 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 the tool executes read-only OpenROAD commands, lists examples (report_*, get_*, check_*, sta, help), and explicitly contrasts with the sibling tool interactive_openroad_exec for mutable commands. This leaves no ambiguity about 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?

The description explicitly tells when to use the tool (for querying design state, generating reports, inspecting timing) and when not to (commands that modify design state), directing to the alternative sibling. This provides complete guidance.

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

list_interactive_sessionsA

Read-onlyIdempotent

List all active interactive OpenROAD sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, read-only nature is clear. The description adds 'active interactive' scope but does not disclose any further behavior like pagination, error handling, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no extraneous words. Every word is necessary to convey the 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?

Given the tool's simplicity (no parameters, rich annotations, and an output schema), the description is mostly complete. It could hint at the output format, but the existence of an output schema covers that. The description adequately captures the tool's core function.

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?

There are zero parameters, and the schema coverage is 100%. The description confirms the resource is 'all active interactive OpenROAD sessions', which adds meaning beyond the empty schema. Baseline for 0 parameters is 4.

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 lists all active interactive OpenROAD sessions. It uses a specific verb 'List' and identifies the resource, distinguishing it from sibling tools like create_interactive_session or terminate_interactive_session.

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 does not mention any conditions, exclusions, or related tools, leaving the agent to infer usage from the name alone.

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

list_report_imagesB

Read-onlyIdempotent

List available report images from ORFS runs organized by stage.

ParametersJSON Schema

Name	Required	Default
`platform`	Yes
`design`	Yes
`run_slug`	Yes
`stage`	No	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint, idempotentHint, and non-destructive. The description adds that results are organized by stage, providing minimal extra behavioral context beyond annotations.

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 a single concise sentence with 14 words, efficiently stating the core action. It is well-structured and front-loaded, but could benefit from additional details without becoming verbose.

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 4 parameters and no schema descriptions, the description is too brief. It does not explain the required parameters or the meaning of 'available', leaving significant gaps for an agent to correctly invoke the 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%, and the description only mentions the stage parameter's role (organizing by stage). No semantics are provided for the required parameters (platform, design, run_slug), leaving the agent under-informed.

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 lists report images from ORFS runs organized by stage. It uses a specific verb and resource, and distinguishes from sibling tools like read_report_image and list_interactive_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?

The description provides no explicit guidance on when to use this tool versus its siblings. It lacks context about when to choose list_report_images over read_report_image or list_interactive_sessions.

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

read_report_imageC

Read-onlyIdempotent

Read a report image and return base64-encoded data with metadata.

ParametersJSON Schema

Name	Required	Description	Default
`platform`	Yes
`design`	Yes
`run_slug`	Yes
`image_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the agent knows the tool is safe and non-destructive. The description adds that the output is base64-encoded data with metadata, but lacks detail on the metadata structure or edge cases (e.g., image not found).

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 sentence of 12 words, directly stating the action and output. It is front-loaded with the key verb and object, with no extraneous information.

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?

Despite having an output schema, the description fails to explain the meaning or constraints of the input parameters, which are all required and have zero schema description. The tool may be under-specified for correct usage without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameter descriptions (0% coverage), and the description does not explain any of the four required parameters (design, platform, run_slug, image_name). This leaves the agent guessing the meaning and valid values for each parameter.

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 verb 'Read' and the object 'report image', and specifies the output as base64-encoded data with metadata. However, it does not distinguish itself from the sibling tool 'list_report_images', which likely lists images without reading content.

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?

No guidance is provided on when to use this tool versus alternatives like 'list_report_images'. The description merely states the action without any contextual advice on prerequisites or preferred scenarios.

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

terminate_interactive_sessionA

DestructiveIdempotent

Terminate an interactive OpenROAD session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	Yes
`force`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=true, so the description is consistent but adds no behavioral context beyond these annotations.

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 sentence, concise with no unnecessary words, making it easy to parse.

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?

The tool is simple but lacks details about the force parameter and what happens when the session terminates, given the presence of sibling tools and a destructive hint.

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%, and the description does not explain the parameters (session_id, force) or their semantics, leaving the agent without guidance.

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 verb ('Terminate') and resource ('interactive OpenROAD session'), distinguishing it from sibling tools like create, inspect, list, etc.

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 (when to end a session) but provides no explicit guidance on prerequisites, when to use alternatives, or exclusions.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: session management (create, list, inspect, history, metrics, terminate), command execution (exec vs query separated by state-modifying vs read-only), and reporting (list and read report images). No overlap.

Naming Consistency4/5

Most tools follow verb_noun pattern (create_interactive_session, get_session_history, etc.), but interactive_openroad_exec and interactive_openroad_query deviate by using a different prefix. Overall pattern is recognizable.

Tool Count5/5

10 tools is well-scoped for managing interactive sessions, executing commands, and handling reports. Not too many or too few.

Completeness4/5

Covers session lifecycle (create, list, inspect, terminate) and command execution (read/write), plus reporting. Minor gaps like a tool to get session details by ID are covered by inspect_interactive_session, so mostly complete.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
Fcc Ecfs A
io.github.pipeworx-io
MCP server for fcc-ecfs
Government Data Open Data
352
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362

Related MCP Servers

openrpc-mpc-server
Developer Tools API Testing
shanejonas
A
license
B
quality
F
maintenance
A Model Context Protocol (MCP) server that provides JSON-RPC functionality through OpenRPC.
Updated 6 months ago (2026-03-02 15:13 UTC)
2
52
43
Apache 2.0
MCP Server
Autonomous Agents Developer Tools
la-rebelion
A
license
Not graded
quality
D
maintenance
MCP Server simplifies the implementation of the Model Context Protocol by providing a user-friendly API to create custom tools and manage server workflows efficiently.
Updated 2 years ago (2025-01-13 19:45 UTC)
21
4
MIT
MCP REST API Server
Developer Tools Code Execution
vinaykp
F
license
Not graded
quality
D
maintenance
A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
Updated a year ago (2025-06-01 03:08 UTC)
KiCad MCP Server
Embedded system Developer Tools
aswego123
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that exposes KiCad PCB design automation tools to AI assistants and other MCP clients.
Updated a year ago (2025-10-07 10:58 UTC)

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/The-OpenROAD-Project/OpenROAD-MCP'

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