Skip to main content
Glama

nutrition-intelligence

add_proof

Submit proof: a first-party URL (brand or restaurant page, PDF, CSV), or label photos (base64; several sides of one package beat one photo), with your reading of it. A URL is a citation: we never download it. Values that fill gaps publish at once, marked unverified; they become verified when an agent with a different owner finds its own proof of the item and reads the same values exactly. A label photo is re-encoded and read by OCR on our server (no model): a field the label text states the same value for is marked photo_confirmed, which is more than unverified and less than verified. Values that would replace existing contributed ones wait for that verification. Values imported from a source (verification "source") are authoritative and never replaced: a contradicting reading is kept beside them; flag a source value you believe wrong. An item the database lacks (a restaurant dish, a new or small-brand product, a supplement) is created with new_entity in place of id, with market and your reading; it publishes at once as unverified and is verified the same way. First-party sources are the strongest proof. Share-alike sources (Open Food Facts, Wikipedia) are refused. Text addressed to AI agents in a proof quarantines it.

Input Schema

NameRequiredDescriptionDefault
idNoThe entity this proves. Give id, or new_entity to create one; a proof with neither waits for a reader to name one.
urlNoA link to the proof: the brand's or restaurant's own page, a PDF or a regulator's record. It is kept as a citation, as text with the date you read it; our server never visits it, and no other agent is sent to it. To keep a copy, upload the file.
noteNo
filesNo
marketNoISO 3166-1 country the label is for, e.g. US, GB, JP. Required with new_entity: it becomes the item's market.
regimeNoLabelling regime of the label if known (US, EU, UK, ...). Detected when absent.
read_atNoThe date you read the page, YYYY-MM-DD. Today when absent.
readingNoYour reading of the proof. Needs id or new_entity.
new_entityNoThe item to create when it does not exist yet: search and lookup_barcode first. It publishes at once as unverified, with its values, and a blind second reader verifies it like them. An obvious duplicate (same barcode in the same market, or same brand and name) is refused with the id to use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: URLs are never fetched, photos are re-encoded and OCR'd server-side with no model, gap-filling values publish immediately as unverified while replacement values wait, source values are never overwritten, duplicates are refused with the id to use, and AI-addressed text quarantines the proof. This is the verification lifecycle an agent cannot infer from the schema.

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?

Everything stated is substantive, but it arrives as a wall of tightly nested clauses with no paragraphing, mixing submission mechanics, verification lifecycle, entity creation and quarantine policy. The core action is front-loaded, then the rest blurs into a single run-on block that is hard to scan.

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?

For a nine-parameter, nested, annotation-free mutation tool this covers the policies that matter: publishing vs waiting, verification levels, entity creation, and refusal. It omits only the shape of the response (what the returned proof or error object looks like), and no output schema exists to cover that gap.

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?

Coverage is already 78%, yet the description still adds meaning: photos should be multiple sides rather than a single image, a URL is a citation not a fetch, and proof quality tiers (first-party vs share-alike) govern what the url parameter may contain. It does not add much on reading/regime/note, but the schema already documents those.

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?

"Submit proof: a first-party URL ... or label photos ... with your reading of it" names a specific verb and resource and enumerates the two accepted proof forms. What is missing is differentiation from the nearby siblings (submit_reading, verify, flag), which the description never mentions.

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?

It supplies real selection rules: use new_entity instead of id when the item is absent, prefer several sides of one package over one photo, 'First-party sources are the strongest proof', and share-alike sources are refused. It stops short of stating when to call this versus submit_reading, so the exclusions are complete but the alternatives are not.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources