LLMs and MCP

This guide explains how to let an AI agent (a procurement assistant, a design copilot, an internal bot) ask Quotometry for prices without letting it invent one. The rules are the same as for any other API client, with one addition.

Before you begin

• A secret key from Developers → API keys, with the narrowest scopes the agent needs.
• A back end of your own to hold that key. The agent calls your tools; your tools call Quotometry.

The one rule

In practice:

• treat POST /v1/price as the only source of a number;
• pass the response through verbatim;
• do not let the model restate a total in its own words. If you show a breakdown, show the one the API returned.

llms.txt

This site publishes /llms.txt: a short map of the documentation for a model with a small context window and no interest in our navigation. Fetch it first, then the one page you need.

Choose the right key

Use a secret key with the narrowest scope that works, from your own back end. Never give an agent a key that can create orders if it only needs to price.

A widget key is not an alternative: it only works from a page whose Origin is on the widget’s allow-list, and an agent has no such page.

An agent that can place orders must send an Idempotency-Key derived from its own task id. Agents retry.

A sensible tool surface

If you wrap Quotometry as tools for a model, four are usually enough:

Tool	Maps to	Notes
list_options	The shop’s materials, colours and options	So the model picks a material that exists.
upload_part	POST /v1/uploads, then POST /v1/uploads/{id}/complete	Return the model_id and nothing else.
price_part	POST /v1/price	Return the response unchanged.
create_quote	POST /v1/quotes	A quote is durable; make this a deliberate step.

Keep a create_order tool out of the list unless ordering is genuinely the agent’s job. Most “quote me this” workflows end at a quote that a person then approves.

What to tell the model

• Materials, colours and finishes come from the shop’s option list. Do not let it guess "PLA+" because that sounds right: the shop either stocks it or does not.
• A line can come back with a state of review or blocked, with reasons. That is an outcome, not an error. The right response is to offer a request for quote, not to retry with a smaller quantity until a number appears.
• Units matter. An STL file carries none, so the unit is something the user knows. Asking is better than assuming: reading a part modelled in inches as millimetres makes its volume about 16 000 times too small.
• A quote expires. If the model resumes a conversation from yesterday, it should price again.

MCP

Quotometry does not ship an MCP server yet. If you expose Quotometry through your own, the same shape applies: read-only tools for options and prices, an explicit tool for creating a quote, and no tool at all that computes money.

Rate limits apply per key, so a server shared by many users should keep its own per-user limits, or one busy user will exhaust the budget for everyone.

Next steps

• Rate limits: the budgets a shared key draws on.
• Errors: line states and reasons the model must understand.
• REST reference: every endpoint and field.