Skip to main content
Glama
Sign In

The Cable Code

by io.github.exquad
OverviewDiscussionsAdmin

List what the cable designer can build

design_presets
Read-onlyIdempotent

List what the cable designer builds, before calling design_cable: presets[] (power, MV, HV, North American, building wire, cords, control, LAN, coaxial, fibre), each with its id, standard, the sentence that builds it in design_cable, its designation (name), voltage, cores, section and metal; and spec_standards[], every family a design_cable spec may name in spec.standard, with its voltages, core counts, sections and metals. Takes only lang. Free, outside the daily free calls, no LLM.

Input Schema

NameRequiredDescriptionDefault
langNoThe language of the preset sentences and names: any of the site's 15 (en, tr, de, nl, sv, fr, es, da, no, fi, it, ro, pl, cs, ru); default en.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / lang / description
      Added value: +"The language of the preset sentences and names: any of the site's 15 (en, tr, de, nl, sv, fr, es, da, no, fi, it, ro, pl, cs, ru); default en."
  2. Changed1 schema field changed
    • changedInput schema / properties / lang / enum
      Previous value: -[
-  "en",
-  "tr"
-]New value: +[
+  "en",
+  "tr",
+  "de",
+  "nl",
+  "sv",
+  "fr",
+  "es",
+  "da",
+  "no",
+  "fi",
+  "it",
+  "ro",
+  "pl",
+  "cs",
+  "ru"
+]
  3. Added

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent and closed-world safety, yet the description adds cost and quota behavior ("Free, outside the daily free calls, no LLM") that no annotation conveys. With no output schema, it also describes the return fields of both arrays, including that presets carry the exact sentence design_cable expects — a genuinely useful behavioral detail.

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?

Purpose and sequencing are front-loaded, and the long enumeration of preset families is reference detail rather than filler. It is dense and runs as one long clause, which slows scanning slightly, but no sentence is wasted.

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?

For a single-optional-parameter read tool with no output schema, the description carries all the needed weight: it explains both returned arrays field by field, what design_cable does with them, and the cost model. Nothing an agent needs to invoke it correctly is absent.

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 coverage is 100%, and the schema already documents the lang enum, its 15 values and the default. The description's "Takes only lang" adds no meaning beyond that, so the baseline of 3 applies.

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 ("List what the cable designer builds") and immediately names the two arrays returned, presets[] and spec_standards[]. It also distinguishes itself from design_cable by positioning itself as the lookup that precedes that tool.

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 an explicit usage rule: call this before design_cable to learn the acceptable preset ids and spec.standard values. It does not state when not to call it or name a competing alternative, but the sequencing guidance is concrete enough that an agent knows exactly where this fits.

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

All The Cable Code 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