Colour Memory

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

Archive Report Brief

archive_report_brief

Read-only

One-call complete archive research package for a document, PDF, or editorial brief. Input: title, audience, themes, archives to draw from, things to avoid, number of colours. Output: ranked colour cards with full provenance, story order, source confidence flags, pull quote, CTA line, CSS tokens, image prompt for Midjourney/Flux/DALLE, editorial argument, weakest and strongest entries identified. Replaces chaining archive_search + get_colour_card + cliche_breaker + agent_brief separately. Two Claude calls total. This is the endpoint for building premium archive documents, PDFs, briefs, and editorial content. Use this first for any document workflow.

Input Schema

TableJSON Schema

Name	Required	Description
`avoid`	No	Topics to suppress e.g. ['arsenic wallpaper', 'Wedgwood blue']
`title`	No	Document title e.g. 'The Colours of Georgian Power'
`themes`	Yes	Research themes e.g. ['racing silks', 'EIC trade', 'Keats']
`archives`	No	Archives to search e.g. ['RacingSilks', 'EIC', 'Keats', 'Dickens']
`audience`	No	Target audience e.g. 'serious Georgian collector'
`n_colours`	No	Number of colours to return (default 8, max 16)
`period_end`	No	Hard period gate: exclude entries dated after this year. Default 9999 (no upper bound).
`period_start`	No	Hard period gate: exclude entries dated before this year. Default 0 (no lower bound).
`allow_partial`	No	If false (default), returning fewer cards than requested sets ok=false with error_code INSUFFICIENT_PALETTE_RESULTS instead of a silent short 'success'. Set true to accept a short result.
`output_format`	No	Reserved for future use -- currently accepted but has no effect on the response shape (the endpoint always returns the full report).
`strict_sources`	No	Only return entries with named primary sources (default true)
`family_card_mode`	No	How near-identical cultivars/records are presented. 'auto' (default): current behaviour, groups into family cards above the standard ΔE threshold. 'always': widens the clustering threshold so more near-duplicates group into family cards. 'conservative': suppresses family cards over max_family_card_share of the deck, instead promoting one hero cultivar per suppressed family with the rest folded into that card's also_supported_by list (never dissolved back into separate near-duplicate swatches).
`confidence_threshold`	No	Minimum confidence score (0.0-1.0) for an entry to be included. Default 0.5 filters out weakly-matched stubs.
`max_family_card_share`	No	Conservative mode only: maximum fraction (0.0-1.0, default 0.5) of presented cards that may be family cards before excess families are suppressed to hero cards. Ignored in auto/always modes.
`minimum_claim_strength`	No	Hard evidence-grade floor: A, B, C, D, or E. Never silently relaxed.
`strict_semantic_colour`	No	Default false. When true, excludes entries whose quoted colour language contradicts their stored hex (e.g. a record naming 'Prussian blue' whose hex is actually a pale cream) rather than presenting them as normal evidence. Never alters hex values, only excludes flagged ones.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.1/5.0

Behavior4/5

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

The description reveals that it makes 'Two Claude calls total', which is a behavioral trait beyond the readOnlyHint annotation. It also describes the composite nature, replacing multiple tools, and the full output list. This adds meaningful context without contradicting annotations.

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 description is long but well-structured with an 'Input:' and 'Output:' list, front-loading the core purpose. Each section earns its place; the alternative naming and usage instruction are not filler. It is appropriately dense for a complex 16-parameter tool.

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?

Given the complexity (16 params) and presence of an output schema, the description does not need to explain return values. It covers purpose, inputs, outputs, alternatives, and usage in enough detail. It could mention edge cases or error behavior, but the output schema likely handles that, so 4 is fair.

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?

The input schema already has 100% coverage with descriptions for all 16 parameters. The description's input list ('title, audience, themes, archives to draw from, things to avoid, number of colours') just summarizes the schema and adds no new per-parameter semantics. Therefore baseline 3 is appropriate.

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?

The description clearly states this is a 'one-call complete archive research package' for documents/PDFs/briefs, explicitly distinguishing it from chaining individual tools like archive_search and get_colour_card. It names the tool as the endpoint for document workflows, providing specific verb + resource + scope.

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 explicitly says 'Use this first for any document workflow' and identifies alternatives by naming the tools it replaces ('Replaces chaining archive_search + get_colour_card + cliche_breaker + agent_brief separately'). However, it doesn't explicitly state when to avoid it in favor of those individual tools.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation2/5

Multiple tool clusters have unclear boundaries: colour_passport, colour_dna, colour_metrics, and colour_cultural_risk overlap heavily; palette_extract, extract_image_colours, image_palette, and ingest_image cover similar image-colour extraction territory; and compound tools like design_session, image_brief, session_brief, and archive_report_brief duplicate chains of component tools. The descriptions are detailed and occasionally state 'use this instead of X', but an agent still faces many near-duplicate choices.

Naming Consistency3/5

Names are consistently snake_case and often use domain prefixes (colour_, palette_, archive_, brand_, accessibility_), but verb placement is mixed: some are verb_noun (extract_image_colours, query_hex, style_match), others are noun_verb (colour_dna, palette_generate, brand_audit), and a few standalone names (ui_states, tool_guide, meta_capabilities) don't fit either pattern. The convention is readable but not uniform.

Tool Count1/5

At 88 tools, this is far beyond the reasonable well-scoped range and exceeds the 50+ extreme mismatch threshold. Many tools are compound wrappers that consolidate chains of simpler tools, adding redundancy and cognitive load rather than genuine coverage.

Completeness5/5

For the apparent domain, the tool surface is extremely comprehensive: colour extraction, analysis, naming, accessibility, cultural/provenance research, palette generation, brand systems, interior design, ecommerce copy, image briefs, project lifecycle, exports, and diagnostic tools are all present. Persistent objects have list/get/versions/delete/export support, so there are no obvious dead ends.

Resources

Need Help?