Skip to main content
Glama
CHASE MCP Server

CHASE MCP Server

by chase-cps

is_implementation

Read-onlyIdempotent

Checks whether a given implementation—LTL formula, state machine, controller, or RTL module—satisfies an assume-guarantee contract, returning valid or an invalid result with a violating trace.

Instructions

Is the implementation an implementation of the contract (M |=_M C)? The implementation is an LTL formula (implementation): implementation & A -> G must be valid; or a state machine, every behavior of which must satisfy A -> G. A machine that refuses inputs can implement a contract only because of that: check it with is_receptive. valid, or invalid with a trace and, in details.violated, the guarantees that this trace breaks (others may fail on other behaviors: check a term alone to know). context: formulas that every behavior satisfies (e.g. an axiom of an encoding, a physical law); the behaviors that violate them are left out. The state machine is given as one of: smv, a program in SMV (the input language of nuXmv: MODULE main with VAR/IVAR, INIT, TRANS..., no specification) that declares the variables of the contract; machine, a state machine in JSON {"name", "inputs", "outputs", "states", "initial", "transitions": [{"from", "when", "outputs", "to"}]}: at each step, in its state, the machine takes a transition whose when (a formula over the variables) holds, sets the outputs of that step, and moves to to; or controller, the controller returned by synthesize, with the contract it was synthesized from in synthesized_from (default: the contract); or rtl, a Verilog or SystemVerilog module (see rtl_ports for its ports).

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": {
      "contract": "<contract>"
    },
    "name": "is_implementation"
  }
}

Input Schema

NameRequiredDescriptionDefault
rtlNo
smvNo
backendNoauto
contextNo
machineNo
timeoutNo
contractYes
controllerNo
implementationNo
synthesized_fromNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • addedInput schema / $defs / ContractSpec / properties / constants
      Added value: +{
      +  "additionalProperties": {
      +    "anyOf": [
      +      {
      +        "type": "integer"
      +      },
      +      {
      +        "type": "number"
      +      }
      +    ]
      +  },
      +  "description": "Named constants: name -> value; the formulas use the names (repair changes them)",
      +  "title": "Constants",
      +  "type": "object"
      +}
  2. Addedv0.4.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, so the bar is lower, but the description still adds real behavior: the result is valid or invalid with a trace, `details.violated` names the guarantees that specific trace breaks, and other guarantees may fail on other behaviors. It also explains that `context` formulas remove violating behaviors from consideration. It never mentions `backend` selection effects or `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.

Conciseness4/5

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

Front-loaded with the core question and reasonably dense for a 10-parameter tool; nearly every clause carries semantics the schema does not. The middle section is jumbled, though: the valid/invalid return discussion is spliced between the receptiveness caveat and the `context` explanation, forcing a re-read.

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 10 parameters, mixed input encodings, no output schema, and 0% schema coverage, the description does substantial work: it explains the return shape, the trace/violated reporting, and all implementation encodings. Gaps remain around solver backend tradeoffs and the timeout, which matter for a verification call that can take minutes.

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?

Top-level schema description coverage is reported as 0%, so the description has to carry the load, and it largely does: it defines `implementation`, `context`, `smv`, `machine` (including the exact transition JSON shape and step semantics), `controller` with `synthesized_from`, and points at `rtl_ports` for the RTL form. It adds nothing for `backend` (9 enum values) or `timeout`, and treats `contract` only indirectly through the A -> G notation.

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?

Opens with a specific check (does implementation M satisfy contract C) and immediately defines what counts as valid: `implementation & A -> G` must be valid, or every behavior of a machine must satisfy A -> G. It also enumerates the accepted implementation forms (LTL formula, smv, machine JSON, controller, rtl). It stops short of a 5 because it never distinguishes the check from overlapping siblings such as `verify`, `refines`, or `is_consistent`.

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?

Usage is implied rather than stated: use it to check whether an implementation satisfies a contract. The one explicit routing hint is a caveat pointing at `is_receptive` for machines that refuse inputs, which is a precondition check rather than an alternative-selection rule. No guidance on when to prefer this over `verify` or `refines`, and no exclusions.

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