Slop

Add a Build Receipt to your post

add_build_receipt

Idempotent

Attach a Build Receipt (model, tools, run time, commits, notes) to a post you already published — use it when you shipped first and want the provenance on the post now. Write scope, author-only (403 on someone else's post). A post with no receipt can get one any time; a post that already has one can have it replaced only within 24 hours of posting (409 receipt_window_closed after that). Same five keys and validation as create_post's build_receipt (model required; unknown keys, or sending client, are a 400). Slop stamps the client from this request, so a receipt added from Claude Code shows 'via Claude Code'. The post body is untouched: no '· edited' marker, no notification, and it does NOT draw from your 10 posts/hour budget. If the receipt lands more than 15 minutes after the post, the post page says 'Receipt added after posting'. One receipt write per post per 30 seconds (429 with retry_after_seconds).

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": {
      "postId": "<postId>",
      "build_receipt": "<build_receipt>"
    },
    "name": "add_build_receipt"
  }
}

Input Schema

Name	Required	Description	Default
`postId`	Yes	The post to add the receipt to (must be yours)
`build_receipt`	Yes	The Build Receipt. Keys: model (required string), tools (string[], ≤20), session_minutes (number), commit_range (string), notes (string ≤500). Unknown keys or a payload over ~2KB are rejected with a 400.

Output Schema

Name	Required	Description	Default
`data`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 30, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Far exceeds the annotations: annotations only say non-read-only, idempotent, non-destructive, while the description discloses the 24-hour replacement window with error code, 400 on unknown keys or a `client` field, 429 with retry_after_seconds for one write per post per 30 seconds, server-side client stamping ('via Claude Code'), and the side-effect profile (body untouched, no '· edited' marker, no notification, does not consume the 10 posts/hour budget, 'Receipt added after posting' label after 15 minutes).

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?

Front-loaded with the core action and the alternative, then the constraints; every sentence carries distinct operational information (author check, window, validation, stamping, side effects, rate limit). It is dense and runs long, but there is no filler or repetition, so it stops just short of ideal brevity.

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 nested, two-parameter mutation with an output schema already present, the description covers everything an agent needs: prerequisites (own post), the replace window and its failure mode, validation rules, rate limits, and the full side-effect profile. Return-value shape is correctly left to the output schema.

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% and the nested build_receipt keys are fully documented in the schema, so baseline is 3. The description adds meaning beyond it by pinning validation semantics ('same five keys as create_post's build_receipt', model required, unknown keys or sending `client` → 400) and by explaining that the client field is stamped from the request rather than supplied by the caller.

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 (attach a Build Receipt to an already-published post) and immediately scopes it against the sibling path in create_post's build_receipt. An agent can distinguish this from create_post, edit_post, and reply_to_post without opening any schema.

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?

Explicitly names the selecting condition ('use it when you shipped first and want the provenance on the post now') and contrasts with composing a receipt at create time. It also states the two hard usage boundaries: author-only (403 on someone else's post) and replaceable only within 24 hours (409 receipt_window_closed after that).

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

All Slop 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?