Skip to main content
Glama

Crimp

by studio.crimp
OverviewDiscussionsAdmin

create_draft

Read-onlyIdempotent

Build and analyze a Crimp planning draft from exact catalog IDs and structured connections, without an AI model call. Agent provides physical lengths and provenance; Crimp selects terminals, layout, wire and fuse suggestions. Display the exact returned reviewUrl as a clickable HTTPS link labeled Review schematic in Crimp; do not substitute a local HTML wrapper. The link opens a view-only preview; Edit a copy is a separate explicit action that creates a new local project. At most 10 counted equipment items, 40 components and 100 cables. Does not save, replace or publish a user's project. Retain assumptions and review findings before installation.

Input Schema

NameRequiredDescriptionDefault
draftYes
designProfileIdNo

Output Schema

NameRequiredDescriptionDefault
okYes
dataNo
toolYes
errorNo
metadataYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / draft / properties / connections / items / properties / fromPort / description
      Added value: +"Select this part's circuit independently of cable direction. Engine positive connections require explicit \"input\" for the starter or \"output\" for the separate alternator connection; \"any\" is ambiguous. The shared engine ground may use \"any\". Also select explicit input/output for separate charger or converter circuits."
    • addedInput schema / properties / draft / properties / connections / items / properties / toPort / description
      Added value: +"Select this part's circuit independently of cable direction. Engine positive connections require explicit \"input\" for the starter or \"output\" for the separate alternator connection; \"any\" is ambiguous. The shared engine ground may use \"any\". Also select explicit input/output for separate charger or converter circuits."
  2. Changed1 schema field changed
    • addedInput schema / properties / designProfileId
      Added value: +{
+  "maxLength": 100,
+  "minLength": 1,
+  "pattern": "^[A-Za-z0-9_.-]+$",
+  "type": "string"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: hard limits (10 equipment items, 40 components, 100 cables), the fact that it is a view-only preview, that 'Edit a copy' is a separate explicit action creating a new local project, and the requirement to use the exact returned reviewUrl as an HTTPS link. These details align with readOnlyHint/idempotentHint rather than repeating them.

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-loads the core capability, then limits, then the critical display instruction about reviewUrl, which is correctly ordered by operational importance. A few clauses (the local HTML wrapper warning, the Edit-a-copy aside) are wordy, but each carries real behavioral content.

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?

Coverage is strong for a complex mutation-shaped-but-read-only tool: size caps, non-persistence, preview semantics, and link handling are all stated, and an output schema exists so return values need not be described. The one material gap is the absence of any guidance on the optional designProfileId parameter.

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 0% and the payload is deeply nested, so the description must compensate; it partially does by indicating that the agent supplies physical lengths and provenance flags, mapping loosely to lengthM/lengthEstimated and partEstimated/countEstimated. Key inputs remain unexplained — designProfileId is undocumented anywhere, and seriesLink, marker, polarity, and ref-vs-catalogId semantics get no treatment.

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?

States a specific verb and resource (build and analyze a Crimp planning draft) plus the discriminating mechanism: it works from exact catalog IDs and structured connections with no AI model call. That lets an agent separate it from analyze_system without opening either schema.

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?

Gives a clear precondition (agent supplies physical lengths and provenance; Crimp does terminal/layout/wire/fuse selection) and an explicit boundary ('does not save, replace or publish a user's project'). It does not name analyze_system or search_components as the alternatives to prefer when catalog IDs are unknown, so routing is implied rather than spelled out.

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

All Crimp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources