Lost-and-found for agent-created assets: sweep, title proof, register, check first.
Scored across 7 tools
Each tool targets a distinct action in the reclamation lifecycle: check before creation, list entries, classify dormancy, record heartbeat, prove title, emit exit work order, and sweep for unattributed assets. The descriptions are specific enough that an agent can easily distinguish them despite some domain jargon.
Names mix verb phrases (check_before_create, prove_title, exit_work_order), nouns (dormancy, heartbeat), and a bare verb (sweep), with register_list following a noun_verb pattern. While all use snake_case and are readable, there is no predictable convention, making the set feel somewhat ad hoc.
Seven tools is well-scoped for a focused reclamation service. Each tool covers a necessary operation without redundancy, and the count sits comfortably within the ideal 3–15 range.
The surface covers the core reclamation workflow: prevention (check_before_create), monitoring (heartbeat, dormancy), proof (prove_title), exit (exit_work_order), and recovery (sweep). Minor gaps exist—no explicit tool to create, update, or fetch a single register entry—but these may be handled externally or are out of scope for reclamation.
Check the register before creating/paying for an asset. $0.001/check x402 or Register plan.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| name | Yes | ||
| provider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add genuine behavioral context: the cost model ('$0.001/check x402 or Register plan') tells the agent this is a paid/authenticated call. It still omits the return shape (boolean? duplicate record?), whether it is purely read-only, and idempotency, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the action and trigger front-loaded and the pricing note trailing. Nothing is wasted, though it is terse to the point of under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-required-param tool with no annotations, no output schema, and zero schema description coverage, the description should explain the parameters and the return outcome. It covers neither, leaving only the cost model as extra information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across all three required parameters (kind, name, provider), and the description explains none of them. The bare mention of 'asset' and 'register' is the only hint linking the params to the check, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('check') and resource ('the register') plus a trigger ('before creating/paying for an asset'), which conveys the intent is a pre-creation existence/duplicate check. However, it never distinguishes this from siblings like register_list, prove_title, or sweep, so an agent cannot tell which register-related tool to pick from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear trigger condition ('before creating/paying for an asset'), which is stronger than nothing. But there are no when-not conditions and no named alternatives among register_list, prove_title, or sweep, so routing still relies on inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dormancy classification for a register entry (dormant / quiet_but_live / live).
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the three classification values it returns, which is useful, but says nothing about whether the call is read-only, whether it has side effects on the register, its cost/latency, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler, and the key output categories are front-loaded in parentheses. It is efficient, though the fragment style omits a subject verb that would make it read as a proper statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema or annotations, the description usefully enumerates the returned classification values, which is the main thing an agent needs. However, it omits what the input identifier should reference and under what circumstances the classification matters, leaving real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with a single required parameter (asset_id) and no type-level documentation. The description only implies via 'register entry' that the parameter identifies a register entry; it adds no format, source, or lookup detail to compensate for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation and resource — classifying the dormancy of a register entry — and even enumerates the possible outcomes (dormant / quiet_but_live / live). It is clear, but it makes no attempt to distinguish itself from siblings like heartbeat, sweep, or check_before_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when this classification should be requested, what triggers it, or how it relates to alternatives such as heartbeat or sweep. The agent must infer the usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Emit a CARD-045 exit work order from a register entry (complete, or missing fields named).
| Name | Required | Description | Default |
|---|---|---|---|
| entry | No | ||
| asset_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The parenthetical "(complete, or missing fields named)" does hint at a validation/failure behavior, which is genuinely useful, but it never says whether the tool mutates state or merely renders output, whether it requires authentication, or what side effects emitting a work order has.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with the action front-loaded and no filler. It is appropriately sized, though its brevity partly reflects under-specification rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a nested object parameter, zero schema coverage, no annotations, and no output schema, the description is far too thin. An agent cannot determine required inputs (required count is 0 despite two params), the shape of 'entry', or the resulting behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters are bare: an untyped nested 'entry' object and an unexplained 'asset_id' string. The description clarifies that 'entry' is a register entry that may be incomplete or have fields named, but adds nothing about 'asset_id', leaving half the surface undocumented in both schema and prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a verb ("Emit"), a named artifact ("CARD-045 exit work order"), and a source ("a register entry"), which is more than a tautology. However, "CARD-045" is domain jargon with no explanation, and nothing distinguishes this from siblings like register_list or check_before_create, which an agent must infer relate to the same register lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus register_list, check_before_create, or sweep, nor any prerequisite or precondition. The phrase "from a register entry" only weakly implies that a register lookup happens first; the agent is left to guess the ordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a heartbeat so a quiet-but-live asset is not flagged dormant.
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a write/mutation against an asset and states its effect on dormancy flagging, but says nothing about idempotency, whether the asset must already exist, required permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with the verb first and no filler. It is efficient, though the extreme brevity leaves no room for the operational detail this tool's context would justify.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description conveys purpose and effect, which covers the core for a low-complexity single-parameter tool, but with no annotations, no output schema, and 0% schema description coverage, an agent still lacks the input identity and result expectations needed to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 0% schema description coverage, and the description never mentions 'asset_id' or what form a valid identifier takes. The single critical input is left entirely to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Record a heartbeat') and clarifies intent with the effect clause about not being flagged dormant, which implicitly contrasts with the 'dormancy' sibling. It does not explicitly name an alternative tool, so it falls short of a 5 by the calibration bar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'so a quiet-but-live asset is not flagged dormant' hints at the scenario, but there is no explicit when-to-use vs. when-not guidance and no mention of how it relates to 'dormancy', 'sweep', or 'exit_work_order'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim-by-challenge title proof (hash comparisons only; posture C register-only).
| Name | Required | Description | Default |
|---|---|---|---|
| proofs | No | ||
| asset_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It vaguely signals a read/verification profile via 'hash comparisons only' and 'register-only', but never states side effects, required permissions, whether anything is mutated or persisted, or what failure looks like. 'Posture C' is undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single front-loaded sentence with no padding, which is structurally good, but the compression comes at the cost of comprehensibility rather than being genuinely information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, a nested-object parameter with 0% documentation, and a two-parameter contract reduced to a jargon fragment. An agent has almost nothing to call this correctly or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and one parameter is an opaque nested object ('proofs'), yet the description only obliquely hints at its contents via 'hash comparisons'. asset_id is never mentioned. The description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Claim-by-challenge title proof' names a resource (title) and an action (prove), and adds two scope qualifiers ('hash comparisons only', 'register-only'). However, the qualifiers are dense internal jargon ('posture C register-only') that an agent cannot decode, and nothing distinguishes it from siblings like check_before_create or register_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool, no prerequisites, and no routing to or away from the sibling tools (check_before_create, register_list, sweep). The agent must guess the intended workflow from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your register entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral load. 'List' implies a read operation, but there is no disclosure of permissions, scope, pagination, return format, or any other trait beyond the implied read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is appropriately concise, though extremely terse and lacking any structural elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema or annotations, the description is minimally viable: an agent knows to call it with no arguments. It does not explain what 'register entries' are or what the response contains, leaving some ambiguity about the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. Per the baseline rule, a description with no parameters scores 4 here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('List') and resource ('your register entries'), so the basic action is unambiguous. However, it does not distinguish this tool from siblings such as check_before_create or sweep, and 'register' is not defined, leaving some vagueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sentence merely restates the action without context, prerequisites, or exclusions relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fingerprint-match unattributed provider assets to task traces (strict 1:1). Trial: one single-provider mini-sweep free once per operator; full sweep $29 (x402 header or banked credit).
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| assets | No | ||
| source | No | ||
| traces | No | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it does disclose useful behavior: a payment/auth requirement (x402 header or banked credit), a price point, and a per-operator trial limit. However it says nothing about side effects, idempotency, whether matching mutates the assets/traces, or what happens on zero matches — significant gaps for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core operation front-loaded and the commercial terms compactly parenthesized. No filler, though the second sentence is information-dense and mixes pricing into what is otherwise a capability statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and five undocumented parameters, the description covers the operation and payment model but omits side-effect profile, return shape, match semantics beyond 'strict 1:1', and any parameter meaning. An agent cannot reliably construct a call from this alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Five parameters exist with 0% schema description coverage, so the description must compensate and largely does not. It implicitly maps to provider/assets/traces via 'provider assets' and 'task traces', but never mentions 'seed' or 'source' or specifies types, formats, or required combinations (all params are optional).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resources: 'fingerprint-match unattributed provider assets to task traces', with the '(strict 1:1)' constraint adding real semantics. It is dense jargon and does not differentiate from any sibling, but no sibling tool overlaps this function, so an agent can still identify the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions a trial tier (one single-provider mini-sweep free once per operator) and a paid full sweep, which hints at a try-before-buy path, but gives no explicit when-to-use/when-not guidance or alternatives. The agent must infer that the trial exists to test before committing to the $29 full run.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_before_createdormancyexit_work_orderheartbeatprove_titleregister_listsweepFree agent recovery and continuity. Public triage; register for a token to access private memory.
Copyright protection tools for AI agents. Search supported sources for suspected copies, investigate URLs, collect metadata evidence, prepare and submit authorized takedowns, and monitor outcomes within a budget. Remote MCP and REST with Bearer credentials, prepaid live usage and a free simulated sandbox. Submission receipts are separate from observed removal. Official clients and sandbox examples: https://github.com/founder-sweep/content-sweep-agent-access.
Issue Agent Passports and verify agent authority before value moves. Signed verification records.
Check claimed and solved agent work, then coordinate through a signed public board.
Add one secure layer between your agents and this server.
