Skip to main content
Glama

Colour Memory

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

Export House Project as Editable DOCX or XLSX

project_export
Read-onlyIdempotent

Export the same house-flagship content palette_pdf renders as a genuinely editable Word document or Excel workbook -- for a client who needs to annotate the scheme, or a contractor building a materials/procurement schedule from it. Accepts exactly one of house_ref or project_id -- an inline house object is refused (400) (same resolution and ownership rules as palette_pdf: an authenticated project_id or house_ref requires its owner; an anonymous temporary house_ref works bearer-only). Never calls house_specify, never re-runs reasoning or re-matches archives -- it renders exactly what was already resolved and stored. DOCX mirrors the PDF flagship's structure (title page, house thesis, whole-house progression, one section per room, implementation details with the same historical/digital-estimate/commercial-candidate distinction, and a deduplicated source appendix) as real editable paragraphs and tables, never images. XLSX produces three sheets: Finishes Schedule (one row per room-surface-colour assignment), Evidence Register (one row per unique colour, the full citation/claim-strength/do_not_say trail), and Paint Procurement (one row per unique paint product, deduplicated for ordering). Every field left blank where the underlying stored data doesn't have it -- nothing is invented. delivery="url" (default) gives a signed R2 download link; delivery="base64" returns the file inline unless the encoded result is too large, in which case it fails closed with OUTPUT_TOO_LARGE_FOR_INLINE_DELIVERY and a repair instruction to use delivery="url" instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
houseNoDO NOT USE -- an inline house object is refused (400 INLINE_HOUSE_NOT_ALLOWED). Pass house_ref (returned by house_specify) or project_id instead.
formatYesWhich editable format to produce.
deliveryNo'url' (default): signed, time-limited R2 download link. 'base64': file bytes returned inline as file_base64, unless too large -- see OUTPUT_TOO_LARGE_FOR_INLINE_DELIVERY.url
house_refNoThe house_ref string house_specify returns. For a durable (authenticated) project this also requires the same API key that created it.
project_idNoThe project_id returned by house_specify for an authenticated (keyed) call. Requires the same API key that created the project.
project_versionNoUsed with either house_ref or project_id -- export this specific immutable version instead of the project's current version. Omit to export the current version.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / house / description
      Previous value: -"house_specify's full response object, unmodified -- alternative to house_ref/project_id. PREFER house_ref or project_id when available."New value: +"DO NOT USE -- an inline house object is refused (400 INLINE_HOUSE_NOT_ALLOWED). Pass house_ref (returned by house_specify) or project_id instead."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already signal readOnly and idempotent behavior, but the description adds substantial operational detail: it never re-runs reasoning or re-matches archives, renders exactly the stored data without inventing fields, and fails closed with OUTPUT_TOO_LARGE_FOR_INLINE_DELIVERY for base64. This goes well beyond the annotation safety profile.

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 the tool is complex and every sentence carries distinct information. It is front-loaded with purpose and then systematically covers output structure, delivery modes, ownership, and failure behavior. Some bullet-like separation would improve scannability, so it is not a perfect 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with six parameters, nested objects, output schemas, and multiple delivery modes, the description is remarkably complete. It covers authentication and ownership rules, versioning, document section mappings, spreadsheet sheet contents, and failure handling. Nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-parameter constraints: exactly one of house_ref or project_id must be supplied, inline house objects are refused with 400, project_version refers to an immutable version, and delivery=base64 can fail closed. This elevates the value above what the schema alone provides.

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 states a specific verb and resource: exporting the same house-flagship content palette_pdf renders as editable DOCX or XLSX. It clearly distinguishes itself from the PDF tool and from inline-house-object workflows, leaving no doubt about what the tool produces.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the conditions for use: a client needing to annotate a scheme or a contractor building a procurement schedule. It also points to palette_pdf as the non-editable counterpart and clarifies that house_specify is never called, making the relationship to sibling tools unambiguous.

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

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