CHASE MCP Server

Overview Schema Source Related Servers Discussions Admin

rtl_ports

Read-onlyIdempotent

Reads Verilog/SystemVerilog module ports as state-machine contract variables, exposing inputs, outputs, types, reset, and the start step for formal checks.

Instructions

The ports of a Verilog or SystemVerilog module read as a state machine: the inputs and the outputs with their types ("bool", "word[n]"), as the variables of a contract checked against it, the reset (not an input when given), and start, the step from which the contracts are checked.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rtl": "<rtl>"
    },
    "name": "rtl_ports"
  }
}

Input Schema

Name	Required	Description	Default
`rtl`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.4.2Oct 29, 2026

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds modeling semantics the agent needs to interpret results: one step is a clock cycle, a 1-bit port is a Boolean and a wider one a word, reset is excluded from inputs and holds in the first step, and `start` is the step from which contracts are checked. Some of this duplicates the schema's RTLSpec text, and nothing is said about failure modes when `top` 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.

Conciseness3/5

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

It is a single compact sentence with the resource front-loaded, but the clause structure ("the inputs and the outputs with their types ..., as the variables of a contract checked against it, the reset ..., and `start` ...") is tangled and takes effort to parse.

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?

With no output schema, the description carries the burden of explaining what comes back, and it does so at the semantic level: typed ports, reset handling, and the `start` step. Missing operational details (error behavior, how files and sources interact, multi-clock handling) keep it from being fully complete.

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 single top-level parameter `rtl` gets no direct explanation, though its nested RTLSpec properties are described in the schema. The description reinforces the meaning of reset ("not an input when given") and the port-to-contract-variable renaming, but leaves files vs. sources, defines, clocks, parameters, and the top-level wrapper's required `top` untouched.

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 names the resource concretely: the ports of a Verilog/SystemVerilog module, with inputs/outputs typed as "bool" or "word[n]", plus reset and start. An agent can tell it produces a state-machine view of a module's ports rather than a contract transformation. It stops short of an explicit verb ("returns"/"extracts") and never contrasts itself with siblings like parse_spec or to_spec.

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 statement of when to call this instead of alternatives such as parse_spec, to_spec, or parse_sva, and no prerequisites or exclusions. Usage is only inferable from the noun phrase describing the output.

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