Colour Memory

by app.railway.up.colour-memory-api-production

Historical Colour Evidence

historical_colour_query

Read-only

Answers a question about how historical colour authorities actually reasoned, with evidence and provenance rather than a summary. Covers seven validated source builds -- Jennings (paint recipes, 1902), Bradley (rotating-disc apparatus, 1895), Vanderpoel (quantified object analyses, 1902), Beaumont (woven colour relationships), Hay (harmonic proportional powers, 1838), Guichard (measured spatial extents, 1880) and Hokusai (subject-conditioned colour application, 1848). Each answer names its source, its locator and what that kind of evidence CANNOT support. Suited to questions like 'how do I paint a leaf', 'what did Bradley's disc proportions measure', 'what's the difference between making a colour and applying it', or checking a claim attributed to one of these authors. Crucially, these sources' numbers are NOT interchangeable: a recipe part, a disc share, an object percentage, a proportional power and a measured extent answer different questions, and the response says so explicitly rather than averaging them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "historical_colour_query"
  }
}

Input Schema

Name	Required	Description
`mode`	No	'user' (default) returns an evidence-led answer packet with structured values retained. 'evidence' additionally returns the complete underlying records.
`query`	Yes	Plain-English historical colour question.
`sources`	No	Optional restriction to named sources.
`max_results`	No	Upper bound on evidence items (default 12).
`high_confidence_only`	No	Only high-confidence records.

Output Schema

Name	Required	Description
`answer`	No	Evidence-led answer: what the evidence supports, one observation that changes the question where the records support one, and the boundary of the claim.
`evidence`	No
`do_not_say`	No
`incomparabilities`	No
`premise_correction`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedAug 19, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: every answer names its source, locator, and what that evidence 'CANNOT support', and it warns that the sources' numbers are not interchangeable rather than averaged. It still says nothing about response size, latency, or what happens when a query matches no source.

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?

The core claim and the source inventory are front-loaded, and the closing sentence on non-interchangeable numbers is the most decision-relevant caveat. The parenthetical author/date/evidence catalogue is long but carries real routing value; the sentence could be tightened without losing much.

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 a full-coverage input schema, an output schema and readOnlyHint already present, the description only needs to justify the tool's existence and its evidentiary limits, which it does well. Missing is any note on what an empty or low-confidence result looks like, which matters for a provenance-oriented query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters are already documented in the schema, and the description does not restate or extend the meaning of mode, sources, max_results or high_confidence_only. Its point about non-interchangeable evidence types gives indirect motivation for the sources restriction but no added parameter-level detail, so baseline 3 applies.

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: it 'answers a question about how historical colour authorities actually reasoned' and returns 'evidence and provenance rather than a summary'. It then enumerates the seven source builds by author, date and evidence type, which makes it unmistakable against siblings like query_hex or colour_metrics.

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?

Gives concrete when-to-use signals through four example question shapes ('how do I paint a leaf', Bradley's disc proportions, making vs applying a colour, verifying an attributed claim). It does not explicitly name which sibling to use instead for non-historical colour questions, so it stops short of full alternative routing.

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

All Colour Memory 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.

Resources

Need Help?