Carrick

Compare consumer and producer types

get_contract_pair

Read-onlyIdempotent

Put one consumer and one producer side by side, operation by operation: the producer's request and response types, every consumer call site with the type that call site expects, and the type verdict the scan stored, with its scanner version. Call it when you are about to change a shape and need to know what the other side already believes it is, or when a compatibility verdict names a problem you cannot place. It reports what the index holds and adds no verdict of its own. It shows HTTP operations side by side, and only the operations a consumer call wins onto; for GraphQL, socket and pub/sub pairs, check_compatibility carries the stored verdicts. For the producer's types alone, use get_endpoint_types; for which calls match at all and which do not, use check_compatibility. Reference: https://docs.carrick.tools/mcp-tools

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": {
      "consumer_service": "<consumer_service>",
      "producer_service": "<producer_service>"
    },
    "name": "get_contract_pair"
  }
}

Input Schema

Name	Required	Description
`path`	No	Narrow to one route path as indexed (e.g. /api/users/:id). A `{field=value}` dispatch suffix, as the listings print it, narrows to that case.
`repo`	No	Your repo as owner/repo (git remote) or just the repo name. Resolves which Carrick project to query.
`limit`	No	Operations per page (default 10, max 50). Ranked by consumer call-site count, then by untyped sides.
`method`	No	Narrow to one HTTP method (GET, POST, PUT, DELETE).
`offset`	No	Operations to skip (default 0). Pass the `next_offset` from a previous call to page through.
`project`	No	Carrick project slug to query. Omit to auto-resolve via `repo`, or omit both when the workspace has one project.
`consumer_service`	Yes	The service making the calls
`producer_service`	Yes	The service serving the operations

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedSep 28, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Goes beyond the readOnly/idempotent annotations by stating the tool 'reports what the index holds and adds no verdict of its own' — a crucial semantic caveat about trusting the output — and by disclosing hard coverage limits (HTTP only, only operations a consumer call wins onto). It does not discuss index staleness or behavior when a pair has no indexed calls, which is the main remaining blind spot.

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?

Front-loads what the agent gets back, then when to call it, then the exclusions and alternatives, then a reference link. Sentences are dense but each carries distinct information; nothing is redundant with the title.

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?

With no output schema, the description compensates by describing the returned structure (side-by-side operations, both type sides, call sites with expected types, verdict plus scanner version). Combined with 100% schema coverage on all 8 parameters, an agent has enough to call and interpret this correctly.

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 100%, so path, method, limit, offset, project, and repo are already fully documented; the description adds no parameter-level meaning beyond restating the consumer/producer framing. Baseline 3 applies since the schema does the heavy lifting.

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?

Names a specific verb and resource ('put one consumer and one producer side by side, operation by operation') and enumerates exactly what the output contains: producer request/response types, consumer call sites, the stored verdict and scanner version. This is clearly distinguishable from the type-inspection and verdict siblings.

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?

Gives two concrete trigger situations ('about to change a shape', 'a compatibility verdict names a problem you cannot place') and names alternatives with their selecting conditions: check_compatibility for GraphQL/socket/pub-sub pairs, get_endpoint_types for producer types alone, check_compatibility for match/no-match questions.

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

All Carrick tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.