Skip to main content
Glama

mcp-server

by org.ptpge
OverviewDiscussionsAdmin

Validate a configuration

ptpge_validate_config
Read-onlyIdempotent

Envelope validation of a product configuration against the specification: checks every binding against the product's supports* envelopes. When a value is not in this template's envelope but another template takes every bound value, the result carries alsoOfferedBy (ranked) and switchHint — switch product and validate again rather than dropping what the buyer asked for (a poster on aluminium composite is a panel print). Maps numeric substrate-weight (gsm) to its weight band via the bands' minWeight/maxWeight properties, and returns data-driven advisories (e.g. creasing recommended above the scoring thresholds). NOTE: this validates the ENVELOPE only — cross-variable legality (e.g. valid panel counts per fold topology) and vendor capability matching are an implementation's concern (a configurator), not the specification's; commercial values (date, price) are not configuration and belong to the transaction layer. Elicitation contract (shared by every ptpge_* tool): whenever a result carries needs_disambiguation, each entry has a field, a question that MUST be put to the user verbatim, and candidates — never infer the answer, never fingerprint until it is resolved. SD-0083: the validator also checks completeness — a missing REQUIRED axis of the product (setup/fold, format, page count, binding, colour on the first face, shape where shape is the product) returns needs_disambiguation with the envelope's candidates; a required axis with exactly one allowed value is bound for you as envelope-implied; a surface name that is not a face of the bound setup (faces: flat-sheet front/back, folded-sheet outside/inside, multi-page front-cover…back-cover) is rejected with the allowed faces. complete: true means an identity can be issued. SD-0104 spot inks: a spot-color layer in color-mode is not identified until it is named — bind variables/features/spot-ink on the same face with the value /: Pantone 300 C → printing/standards/color-systems/color-matching-systems/pantone-matching-system/300-c, HKS 43 K → …/color-matching-systems/hks/43-k, RAL 5015 → …/ral/5015 (code lower-case, spaces as hyphens; checked for form only). One spot-ink per spot-color layer; two spots = color-mode values [cmyk, spot-color, spot-color] + two spot-ink values. Fewer inks than layers → needs_disambiguation; the specification sets no limit on the number of spot colours (the press does).

Input Schema

NameRequiredDescriptionDefault
productYesProduct URI or path.
bindingsYesVariable bindings to validate.
languageNoen

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes far beyond the annotations: it discloses returned fields (alsoOfferedBy, switchHint, advisories, complete), the needs_disambiguation elicitation contract ('never infer the answer'), completeness checks for missing required axes, surface-face rejection behavior, and spot-ink binding rules. The readOnly/idempotent/non-destructive hints are already in annotations, so this extra context is pure added value.

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?

Purpose is front-loaded, which is good, but the description is a dense wall of specification detail with internal references (SD-0083, SD-0104) and a long URI-construction example. The shared elicitation contract is boilerplate repeated across ptpge_* tools. All content is relevant, but it could be structured more scannably.

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 carries the full burden and does so: it explains what needs_disambiguation contains, what complete:true means, what alsoOfferedBy/switchHint are for, and what advisories represent. An agent has enough to interpret outputs and follow the elicitation contract without further documentation.

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?

Schema coverage is 67%, and the description compensates well for the bindings parameter: it explains surface-face validity (flat-sheet front/back, folded-sheet outside/inside, etc.), spot-ink value construction with concrete URI examples (Pantone 300 C → …/pantone-matching-system/300-c), and cardinality rules for multi-value variables. The `product` and `language` parameters get no additional treatment in the description, leaving a small gap.

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 — 'Envelope validation of a product configuration against the specification' — and immediately defines what is checked (every binding against the product's supports* envelopes). This is clearly distinguishable from siblings like ptpge_validate_document or ptpge_check_domain, which have different scopes.

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?

Explicitly routes behavior: when a value is not in the envelope but another template accepts it, 'switch product and validate again' rather than dropping the buyer's request. It also names exclusions — cross-variable legality and vendor capability matching are 'an implementation's concern, not the specification's', and commercial values belong to the transaction layer.

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

All mcp-server toolsInspect
Try in Browser
Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources