mcp-server

Navigate the PTPGE hierarchy. Returns a node and its children (id, notation, label, level, elementType, hasChildren). Omit id_or_path to get the three top concepts (printing, ordering, variables). Use this for systematic exploration instead of guessing search keywords.

Does an agent find PTPGE on this domain? Fetches exactly what a checkout agent fetches — https://<domain>/.well-known/ucp (the UCP manifest and its ptpge block), the vendor declaration at /.well-known/ptpge/declaration.json, the identity in the vendors register, and a supplier catalogue if the domain is a maker — and validates each against its published JSON Schema (ptpge.org/v1/schemas/) and the vocabulary. Returns a verdict (ready | partial | none), one line per step with errors and warnings, what the agent sees (name, identity, products, capability counts) and what is missing with where to fix it. Read-only; nothing is stored. Use it to answer 'is <printer> agent-ready?' or 'why does my declaration not validate?'.

Expand a spec or request fingerprint (ptpge-cfs/1, full 64-hex or 16-hex short form) back into its structured configuration — the read-back path for MIS/ERP: matched profile, product, every binding with resolved labels, the canonical string, and the dataset version. This is a LOOKUP in the public resolver (ptpge.org/f/), not an inversion of the hash: it resolves when the fingerprint has been registered (every fingerprint computed by ptpge_fingerprint is self-registered within seconds). An unregistered fingerprint is still a valid identity — it simply has no stored expansion yet; returns status 'unknown' then.

Compute the canonical ptpge-cfs/1 serialization and SHA-256 fingerprint of a resolved product configuration (SD-0040) — the vendor-neutral identity used as quote/order/cache key. Returns both profiles in strict containment spec ⊂ request: 'spec' = the manufacturable artifact, commercial cluster excluded; 'request' = spec plus the commercial cluster — the variables under variables/order/ (quantity, lead-time, delivery-method, incoterm; SD-0040) without a vendor. An 'offer' is a request plus variables/order/vendor, one per vendor (SD-0108). Transaction data (print-ready file, delivery date, price) is keyed BY the request fingerprint and never hashed into it. SD-0083: the input is validated first and an identity is issued ONLY for a valid, complete configuration — every required axis of the product bound (or envelope-implied where the envelope offers one value; those are written into the identity) and every surface one of the bound setup's faces. Otherwise the result is error=not_fingerprintable with the validator's needs_disambiguation: put each question to the user verbatim, bind the answer, call again. Never guess a missing axis.

Return the complete Configuration Envelope of a product class in one call: supportsSetupModel, every supports* and perSurfaceSupports* predicate with resolved labels, plus typical* descriptors. This is the full menu of what can be configured for the product — use it before composing a configuration, instead of many individual ptpge_get_term calls. Absent predicates mean NOT supported (closed semantics).

Fetch full context for a single PTPGE term: definition, broader/narrower relations, exactMatch / closeMatch mappings, properties, notation, level, and metadata. Accepts either a full URI (https://ptpge.org/v1/...) or a relative path under /v1/.

Return the current PTPGE dataset version, total term count, counts per level and per group, license, scheme URL, and server version. Useful for version-pinning, health checks, and diagnostics.

Resolve print colour pair notation (4/4, 4/1, 4+4) into per-surface colour bindings for a given product. The number is a COUNT OF SEPARATIONS, not a colour: it is resolved by searching the combinations this product's envelope actually supports whose colorChannelCount sums to that number. Returns one of three outcomes per surface — a deterministic binding, `needs_disambiguation` with the candidate combinations, or `invalid_for_template` when no combination is possible. IMPORTANT: when `needs_disambiguation` is returned you MUST put its `question` to the user and never infer the answer yourself. '1' is black on some products and a named spot colour on others; guessing gives two different products the same identity. Do not fingerprint an unresolved configuration.

Free-text search over the PTPGE vocabulary and registers — the open specification of print. Returns a ranked list of matching terms with their URI, notation, preferred label, level (top-concept / group / category / sub-category / element), group, and a relevance score (0.0–1.0).

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 <matching-system term>/<code>: 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).

Validate ONE document you hand over — a vendor declaration, supplier catalogue, request, quote or UCP manifest (its `schema` field says which) — against the published JSON Schema, the vocabulary (every term URI must exist; deprecated warns) and, for request/1 and quote/1, the identity: the spec and request fingerprints are recomputed from the configuration and must match what the document states; a quote's offer fingerprint must equal request + the quote's vendor (SD-0108). Nothing is fetched from any domain and nothing is stored. This is the PTPGE Ready conformance check for a module that writes these documents (ptpge.org/ready/). Returns valid, errors[], warnings[] and what was checked.