Planner (proof-of-done)

goal-request-upload

PREFERRED path to attach a LARGE binary evidence file (screenshot, log dump, PDF, session transcript — anything > ~1 KB) to an acceptance criterion. Returns a one-time {uploadUrl, expiresAt} scoped to this criterion. Then STREAM the raw file to it with a single PUT — no base64, no token:

curl -sS --fail --upload-file "/abs/path/to/file.png" ""

Optionally pass the hex SHA-256 of the file so the server fast-fails on any in-flight corruption: curl -sS --fail -H "X-Content-Sha256: " --upload-file "/abs/path/to/file.png" ""

The PUT response is the same evidence JSON that goal-attach-evidence returns (evidence id, serverSha256, judge verdict, criterion evidenceCount). A non-2xx PUT means the upload was rejected (expired/already-used/wrong-criterion/hash-mismatch) and NO evidence was created — request a fresh URL and retry.

Use this instead of goal-attach-evidence for any non-trivial file. Use goal-add-evidence-text only for byte-less context (external URLs, manual repro notes) — it does NOT cover an AC.

GOAL ATTACHMENTS (description illustrations, NOT evidence): pass goalId INSTEAD of criterionId. The PUT then creates a goal attachment and returns {attachment.url, attachment.markdown} — paste markdown into the goal description and the web UI renders images inline. Such a file is not bound to any AC and never counts toward closing the goal.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	No	Optional evidence kind override. Only accepted value is `session_history` (goal-level transcript artifact; does NOT cover an AC).
`goalId`	No	UUID of a goal — issues a ticket for a DESCRIPTION ATTACHMENT (not evidence); mutually exclusive with criterionId
`caption`	No	Optional human-readable description, stored on the evidence
`createdBy`	No	Identifier of the uploading agent
`criterionId`	No	UUID acceptance criterion the file will be evidence for (omit when goalId is given)

TDQS

A4.6/5.0

Behavior5/5

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

The description thoroughly discloses the tool's behavioral traits: returns a one-time URL that expires, requires a subsequent PUT, handles hash mismatch rejection, and differentiates evidence creation from goal attachments. This goes well beyond the minimal annotations (readOnlyHint=false, idempotentHint=false) and fully informs the agent of side effects and error handling.

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?

While the description is long, it is densely packed with essential information: primary use, curl examples, failure handling, alternative use, and special cases. The structure front-loads the primary usage and then expands logically. Every sentence earns its place, though it could be slightly more concise.

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 (5 optional params, no output schema, mutating non-idempotent operation), the description is fully complete. It covers the entire workflow, error conditions, alternative tools, and the distinction between evidence and goal attachments. No critical information is missing for an agent to invoke it correctly.

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?

All parameters are described in the schema with 100% coverage, so the description adds limited additional meaning. It reinforces the mutual exclusivity and clarifies the kind parameter's accepted value, but these are already present in the schema. The description does not add significant semantic value beyond what structured schema 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 clearly states the tool's purpose: to issue a one-time upload URL for attaching large binary evidence files to an acceptance criterion. It uses specific verbs ('attach', 'stream') and distinguishes from siblings like goal-attach-evidence and goal-add-evidence-text with explicit instructions on when to use each.

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?

Provides explicit when-to-use and when-not-to-use guidance: 'Use this instead of goal-attach-evidence for any non-trivial file' and 'Use goal-add-evidence-text only for byte-less context'. Also clarifies the difference between evidence and goal attachments, including the mutual exclusivity of goalId and criterionId.

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

All Planner (proof-of-done) 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.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

Need Help?