Proofsource

I shipped a fix

mark_fix_shipped

Idempotent

Records that a fix shipped, against a gap_id from list_fix_opportunities or a published content_draft_id, so get_fix_verification can measure whether it moved the brand's mention rate. Calling again with the same fix and description returns the existing record.

Input Schema

Name	Required	Description
`gap_id`	No	The gap finding the fix addresses (one of gap_id or content_draft_id).
`brand_id`	No	Brand id from list_brands. May be omitted when the workspace tracks a single brand.
`shipped_at`	No	When it shipped: RFC 3339 timestamp or YYYY-MM-DD. Default now.
`description`	Yes	What shipped, in one or two sentences.
`content_draft_id`	No	A published content draft (one of gap_id or content_draft_id).
`acknowledge_unfilled_gaps`	No	A content draft that still has [INSERT ...] gaps is refused and the gaps listed. Set true only after the user confirms the shipped page has them filled.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 18, 2026

addedInput schema / properties / acknowledge_unfilled_gaps

Added value: +{
+  "description": "A content draft that still has [INSERT ...] gaps is refused and the gaps listed. Set true only after the user confirms the shipped page has them filled.",
+  "type": "boolean"
+}

First observedOct 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world. The description adds real context beyond them: the idempotent repeat call returns the existing record, and the record feeds mention-rate verification downstream. It omits the refusal path for drafts with unfilled [INSERT] gaps, but that is covered in the schema parameter description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, and the core action plus its downstream purpose are front-loaded before the idempotency note. Every clause earns its place.

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?

For a 6-parameter mutation with only one required field and no output schema, the description covers purpose, input sourcing, idempotency, and the verification loop. It could mention what the recorded result looks like or the unfilled-gaps refusal, but the schema fills those gaps.

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, and the description goes beyond it by naming the sourcing tool for gap_id and qualifying content_draft_id as a published draft. It does not add format or default details for shipped_at/brand_id, which the schema already handles.

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 ('Records that a fix shipped') and immediately scopes it to the two valid ID sources (gap_id from list_fix_opportunities, or a published content_draft_id). It also names the downstream consumer, get_fix_verification, so the agent understands what this write is for and can distinguish it from sibling list/get tools.

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?

Clearly says which inputs to use and where they come from ('against a gap_id from list_fix_opportunities or a published content_draft_id'), and states the repeat-call behavior. It gives strong positive guidance but no explicit when-not-to-use rule or prerequisite conditions (e.g., that the fix must actually be shipped before recording).

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

All Proofsource tools Inspect

Try in Browser