Skip to main content
Glama

goal-attach-evidence

PRIMARY path to close a Grove goal: this is the ONLY tool that covers an acceptance criterion. Attach binary evidence (screenshot, log dump, API response, export) to an AC — call it once per criterion to satisfy the close gate. The subordinate goal-add-evidence-text only adds context for proofs with NO bytes (URLs to permanent external sources, manual repro descriptions) and does NOT cover an AC. Caption is optional but strongly recommended: state what the file captures and the reproduction conditions (URL/commit/session/inputs) so a third reviewer can reproduce.

⚠ PICK THE RIGHT TRANSPORT BEFORE YOU CALL THIS TOOL ⚠ • BEST for ANY file > ~1 KB raw — and the ONLY no-token path, so use it in a claude.ai / hosted-agent session that has no raw X-Auth-Token → call the sibling MCP tool goal-request-upload with this same criterionId. It returns a one-time {uploadUrl, expiresAt}; then stream the raw bytes with a single PUT: curl -sS --fail --upload-file "/abs/path/to/file.png" "<uploadUrl>" (optionally add -H "X-Content-Sha256: " so corruption fails fast). No base64, no token — the signed ?t= ticket in the URL is the only credential, single-use, criterion-scoped. The PUT response is the same evidence JSON this tool returns. • ALTERNATIVELY, if you DO have the raw X-Auth-Token in your shell → the planner-attach.sh helper (zero-install bash, binary-safe). The MCP base64 path below is unreliable for non-trivial files: long string arguments get truncated or whitespace-corrupted on the agent side BEFORE the JSON-RPC request is sent. Measured 2026-05-20 on prod: a 4 KB PNG arrived at the server as 1874 decoded bytes (file_hash_mismatch); a 2 KB payload arrived with stray whitespace (failed base64_decode). The server itself accepts up to 25 MiB raw — the bottleneck is the agent-side serialisation of contentBase64, NOT the server.

planner-attach.sh COPY-PASTE RECIPE (replace 3 placeholders, run in your shell): curl -sS https://planner.monopoly-gold.com/api/cli/planner-attach.sh
| PLANNER_TOKEN="" bash -s --
--criterion-id ""
--file "/abs/path/to/file.png"
--caption "what is captured and the repro conditions"
--created-by ""

Where to get each value:

  • PLANNER_TOKEN: the very same token that is already in your MCP config under the X-Auth-Token header for the planner server. NOT a separate credential.

  • CRITERION_UUID: the AC id you got from goal-get / goal-list. Same UUID you would pass to this MCP tool.

  • file path: absolute path on YOUR (agent) machine — the script reads it locally and streams multipart. The planner server never sees your filesystem.

The helper computes SHA-256 itself and ships it as contentSha256, so any in-flight corruption fails fast with HTTP 400 instead of poisoning the evidence row. Output on stdout is the same JSON shape this MCP tool returns; non-zero exit means HTTP ≥ 400 (stderr explains).

Without curl/bash? Fall back to raw multipart: POST https://planner.monopoly-gold.com/api/criteria//evidence/file, header X-Auth-Token, form fields file=@..., contentSha256=..., caption, createdBy. • File ≤ ~1 KB raw → this MCP tool is fine. ALWAYS pass contentSha256 (hex SHA-256 of raw bytes BEFORE base64). Without it, a silently truncated PNG looks valid to the MIME sniffer; the server cannot distinguish a truncated 4 KB PNG from a valid 1 KB one and the vision judge burns ~30s on broken bytes. With the hash, the server fast-fails with error=file_hash_mismatch and points back here at the multipart endpoint.

Validates MIME whitelist (png/jpeg/webp/gif/pdf/txt/json/zip), per-file size cap (ATTACHMENTS_MAX_FILE_BYTES, default 25 MiB), per-project attachments quota. Returns evidence record + file URL + serverSha256.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoOptional evidence kind override. The only accepted value is `session_history` — marks this attachment as the goal-level «full Claude session transcript» artifact required by the close gate (I4-session-history). Such evidence does NOT cover any AC and is NOT sent to the evidence judge. Omit for normal per-AC proof (kind is derived from MIME). NOTE: transcripts are usually > 1 KB → use goal-request-upload (pass kind=session_history) or the multipart helper, not this base64 path.
captionNoOptional human-readable description, stored in evidence.payload
filenameYesOriginal filename (used to derive MIME). Path components are stripped.
mimeTypeNoMIME type — if omitted, derived from filename extension; must be in whitelist
createdByNoIdentifier of the uploading agent
criterionIdYesUUID acceptance criterion the file will be evidence for
contentBase64YesFile payload, base64-encoded (RFC 4648 §4 standard alphabet, padding optional)
contentSha256NoHex-encoded SHA-256 of the raw bytes (before base64). When provided, the server recomputes the hash on the decoded payload and rejects with error=file_hash_mismatch if they diverge — primary defence against MCP base64 truncation.

TDQS

A4.8/5.0
Behavior5/5

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

Even though annotations provide readOnlyHint=false and idempotentHint=false, the description discloses crucial behavioral traits: the MCP base64 path is unreliable for non-trivial files (with measured evidence of truncation), contentSha256 is needed for fast-fail integrity, and server-side MIME/size validation exists. It also explains that the server returns an evidence record plus file URL, fully consistent with the write operation.

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?

The description is extremely long, including a shell recipe, measured failure examples, and multiple fallback paths—valuable but far from concise. It is front-loaded with the core purpose and clearly structured with headings and bullets, which aids scannability, but there is redundancy (e.g., repeated warnings about base64 unreliability) and several sentences are auxiliary rather than essential.

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?

Given the complexity (8 parameters, multiple transport options, no output schema), the description is remarkably complete. It covers validation rules (MIME whitelist, size caps, quota), error handling (file_hash_mismatch), return shape (evidence record + file URL + serverSha256), and even provides alternative invocation methods. This fills all gaps left by the missing output schema.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial semantics: contentBase64 is risky for large files, contentSha256 is the primary defense against truncation, kind is restricted to `session_history` and does not cover an AC, and caption should state reproduction conditions. This enriches the parameter meaning well beyond raw schema definitions.

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 clear specific purpose: 'Attach binary evidence ... to an AC' and emphasizes it is 'the ONLY tool that covers an acceptance criterion.' It explicitly differentiates from the sibling goal-add-evidence-text, which 'does NOT cover an AC,' making the tool's role unmistakable.

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?

The description gives explicit when-to-use guidance: for files > ~1 KB raw it directs to goal-request-upload or planner-attach.sh, while for ≤ ~1 KB it says 'this MCP tool is fine.' It also distinguishes when to prefer goal-add-evidence-text for non-binary context, and provides a copy-paste recipe and fallback endpoints—far beyond minimal guidance.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clear distinct purposes (goal-create vs goal-update vs goal-delete), but the evidence-related tools (goal-add-evidence-text, goal-attach-evidence, goal-request-upload) and note tools (goal-add-note) have overlapping concepts that require careful reading of descriptions to differentiate. Overall, the detailed descriptions help resolve ambiguity, but a few tools could be easily confused.

Naming Consistency4/5

The majority follow a consistent verb_noun pattern with a resource prefix (goal-create, goal-get, project-list, project-update). However, there are deviations like account-delete (noun-verb reversed), goal-todo, goal-summary, goal-tree, and goal-recent-unresolved that break the pattern. The inconsistency is minor but noticeable.

Tool Count2/5

With 38 tools, this server has a very large surface area. Even for a complex planner with evidence management, the number exceeds the 25-tool threshold for 'too many'. Many tools could potentially be consolidated (e.g., goal-add-note and goal-add-evidence-text), and the size may overwhelm agents during tool selection.

Completeness5/5

The tool set provides complete coverage of the domain: full goal lifecycle (create, get, update, delete, list, tree, move, reorder, block), evidence management (attach, request upload, text evidence, remove), acceptance criteria (add, update, remove, request change, resolve escalation), assumptions (add, update, remove, suggest, attach evidence), blockers, notes, project management (CRUD, dependencies), and configuration settings. No critical gaps are apparent.

Resources