mcp-server

Find print shops that can make it

ptpge_find_vendors

Read-onlyIdempotent

Who can make this? Reads the PTPGE vendor register and every claimed print shop's own declaration (/.well-known/ptpge/declaration.json — the file is the source) and filters on what the documents say: country (ISO 3166-1 alpha-2), product template (e.g. ordering/products/booklets or just «booklets»), printing technology (a term under printing/technologies/printing-technologies — a parent matches its children, so «digital» finds laser and inkjet), certification (e.g. nordic-swan-ecolabel), substrate, or free text on name/city. Returns each matching shop with its identity, countries and cities, products, technologies, certifications, the matching offerings (minimum quantity, lead time) and the doors an agent needs next: the declaration, the UCP manifest, the register entry. Never ranked, never priced — for price and an order use the shop's own MCP endpoint from its manifest; the spec fingerprint is the same key everywhere. Read-only; cached ten minutes; nothing stored.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ptpge_find_vendors"
  }
}

Input Schema

Name	Required	Description	Default
`text`	No	Free text matched against name, legal name, domain and cities.
`limit`	No
`country`	No	ISO 3166-1 alpha-2, e.g. NO, DE, US.
`product`	No	Product template: URI, /v1/ path or slug (booklets, business-cards, posters …).
`language`	No		en
`substrate`	No	Substrate term: URI, path or slug (paper, cardboard, vinyl …).
`technology`	No	Printing technology term: URI, path or slug (offset, digital, laser, uv-inkjet …).
`certification`	No	Certification term: URI, path or slug (nordic-swan-ecolabel, fsc, trykt-i-norge …).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly, idempotent, openWorld): states results are never ranked and never priced, that caching lasts ten minutes and nothing is stored, and that results include operational 'doors' (declaration, UCP manifest, register entry) the agent needs next. This is exactly the extra context the safety hints cannot convey.

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-loaded with the question it answers and dense with substance rather than filler; the enumeration of filter dimensions earns its space. It is a single long run-on paragraph with heavy parentheticals, which costs some scannability.

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?

With no output schema, the description compensates by enumerating returned fields (identity, countries, cities, products, technologies, certifications, matching offerings with minimum quantity and lead time, plus follow-up links). Reasonably complete for an 8-parameter tool, though the limit/pagination behavior and the language parameter are left unexplained.

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?

Adds real meaning beyond the 75%-covered schema -- notably that a parent technology term matches its children, so 'digital' finds laser and inkjet, and that product terms accept URI, path or bare slug. Gaps remain: limit and language are never mentioned, and 'free text on name/city' is narrower than the schema's name, legal name, domain and cities.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb and resource -- it reads the PTPGE vendor register plus each shop's declaration.json and filters shops by country, product, technology, certification, substrate or free text. The scope boundary against pricing/ordering is stated, but it never distinguishes itself from the sibling ptpge_find_suppliers, which an agent would plausibly consider interchangeable.

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?

Clear usage context: use this to discover who can make something, and route to the shop's own MCP endpoint from its manifest for price and ordering. It stops short of explicit when-not-to-use rules or naming alternative sibling tools, so the routing guidance is one-sided.

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

All mcp-server tools Inspect

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.