Dedup proxy: claim-before-execute, UNKNOWN resolution, CONFLICT and ESCALATED refusal.
Scored across 4 tools
Each tool has a clearly distinct purpose: dedup_execute claims and executes, dedup_receipt reads a stored claim/receipt, dedup_resolve closes an escalated claim, and guard_census reports guard status. There is no overlap in action or resource.
All tools use consistent snake_case with a domain prefix (dedup_ or guard_), but the suffixes mix verbs and nouns (execute, receipt, resolve, census), slightly deviating from a pure verb_noun pattern.
Four tools are well-scoped for this specialized dedup proxy, covering each core operation without redundancy or bloat.
The claim lifecycle (execute, read, resolve) and guard census are covered, but there is no tool to list or search multiple claims, which is a minor gap for operational visibility.
Claim-before-execute a side-effecting tool call: semantic-identity claim, CONFLICT refusal, UNKNOWN resolved by status query, ESCALATED refusal for no-status providers. $0.001/claim after the one-time 100-claim trial; included on Operator/Fleet plans.
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| tool | Yes | ||
| scope_fields | Yes | ||
| provider_mode | No | ||
| supports_status | 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 a claim/refuse/resolve/escalate state machine plus cost structure. But key operational traits are missing: whether the underlying side effect is actually executed or merely claimed, what a successful result looks like, and undefined terms like CONFLICT/UNKNOWN/ESCALATED that the agent must guess at.
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 core purpose is front-loaded in the first sentence, which is good, but that sentence is dense with undefined jargon and the second sentence is a pricing/trial aside of marginal value for actually invoking the tool. Appropriately short, but neither sentence is as informative per word as it could be.
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 complex, five-parameter tool with a nested object, no annotations, no output schema, and 0% schema coverage, the description is thin. It omits parameter semantics, return/error semantics, and sibling routing, so the agent cannot confidently call it correctly despite the helpful state-machine sketch.
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 five parameters (tool, args, scope_fields, provider_mode, supports_status), so the description must compensate and largely does not. It only loosely echoes two concepts ('status query' ~ supports_status, 'semantic-identity' ~ scope_fields) without naming or explaining any parameter, leaving the nested 'args' object and 'provider_mode' entirely undocumented.
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 opening clause 'Claim-before-execute a side-effecting tool call' states a specific action on a specific resource type, so an agent grasps that this is a deduplication gate for side-effecting calls. It is clear enough to distinguish from dedup_receipt and dedup_resolve by name and framing, but it never explicitly contrasts itself with them and leans on undefined jargon ('semantic-identity claim').
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?
The description implies when various branches fire (CONFLICT refusal, UNKNOWN resolved by status query, ESCALATED refusal for no-status providers), which hints at usage context. However, it gives no explicit when-to-use/when-not guidance and never points the agent to the sibling tools (dedup_receipt, dedup_resolve, guard_census) as alternatives for other situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read your stored claim/receipt for a semantic identity (per-tenant scoped).
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| tool | Yes | ||
| scope_fields | 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. 'Read' weakly implies a non-mutating lookup and 'per-tenant scoped' hints at isolation, but nothing is said about what a missing receipt returns, error behavior, or how the identity is computed.
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 compact sentence with the read action and scoping front-loaded. It is efficient, though it is terse to the point of under-specification rather than wasteful.
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?
With no annotations, no output schema, 0% parameter coverage, and a nested args object, the description leaves too much unspecified for an agent to invoke this correctly. It should at minimum define the receipt concept and the three inputs.
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?
All three parameters (tool, args, scope_fields) have 0% schema description coverage, and the description does not explain any of them. 'Semantic identity' and 'per-tenant scoped' loosely gesture at scope_fields but give no format or expected values, especially problematic given the nested 'args' object.
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 read operation on a stored 'claim/receipt' keyed by a semantic identity, which conveys a rough purpose. However, 'claim/receipt' is never defined and the description gives no way to distinguish this from siblings dedup_execute, dedup_resolve, or guard_census.
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 the sibling dedup_execute or dedup_resolve, nor any prerequisite or exclusion. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manual status check closing an ESCALATED claim (committed verdict only).
| Name | Required | Description | Default |
|---|---|---|---|
| args | Yes | ||
| tool | Yes | ||
| scope_fields | 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 does disclose two preconditions (the claim must be ESCALATED and the verdict must be committed), which is useful state-gating context, but it omits what 'closing' actually does, whether it is reversible, what permissions are required, and what the result is.
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 short, front-loaded sentence with no filler. It is efficient, though its terseness verges on obscurity rather than genuinely aiding selection.
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?
With three required parameters at 0% schema coverage, a nested object, no annotations, and no output schema, the description is far too thin. An agent cannot determine how to populate the arguments or what state change to expect.
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 the description says nothing about any of the three required parameters (tool, args, scope_fields). The nested 'args' object in particular is completely unexplained in both places, so an agent has no basis for constructing a valid call.
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 names an action (a manual status check that closes a claim) and a target state (ESCALATED claims with a committed verdict), which is more than a restatement of the name. However, it never clarifies what the tool actually operates on relative to its siblings dedup_execute, dedup_receipt, and guard_census, and 'manual status check closing' conflates two ideas, leaving the core purpose only loosely defined.
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?
No explicit when-to-use or when-not-to-use guidance. The word 'Manual' faintly implies an operator-invoked alternative to an automatic path, but no sibling or alternative tool is named and no triggering condition is described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-server guard census: SELF_GUARDED_VERIFIED only with a checkable status endpoint; invisible guards read NO_VISIBLE_GUARD.
| Name | Required | Description | Default |
|---|---|---|---|
| servers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add genuine behavioral content by disclosing the classification rule: a guard is labeled SELF_GUARDED_VERIFIED only when a checkable status endpoint exists, and invisible guards resolve to NO_VISIBLE_GUARD. That is valuable, but it never states whether the operation is read-only, what permissions it needs, or any side effects, so the safety profile remains undisclosed.
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 dense sentence that front-loads the resource and then the classification semantics, with no filler. It is compact, though the semicolon-clause structure makes it read like a spec fragment rather than an introduction.
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?
There is no output schema, no annotations, and no explanation of what a caller receives back per server. For a tool whose whole value is a per-server verdict, the description should at least outline the returned categories and any input expectations; as written an agent cannot predict the response shape or how to supply 'servers'.
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% for the single required 'servers' array, so the schema itself explains nothing. 'Per-server' weakly implies the input is a list of servers, but the description provides no format, content, or expected element details, leaving the only parameter materially undocumented.
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 names a specific resource (per-server guard census) and conveys the classification axis (SELF_GUARDED_VERIFIED vs NO_VISIBLE_GUARD), so the broad intent is discernible. However, 'guard' is unexplained domain jargon and the description never states what a census of guards actually produces or why an agent would want one, leaving the purpose only partially pinned down. It does not overlap with the dedup_* siblings, so no differentiation credit is needed but none is given either.
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 when-to-use statement, no prerequisites, and no mention of any alternative tool. Usage is only implied by the notion of taking a census of servers' guards. The agent must infer the triggering scenario entirely.
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.
dedup_executededup_receiptdedup_resolveguard_censusEvidence-linked MCP selection and non-executing Safe-Call review; surfaces unknowns.
Look before work, claim it, check a spend, mark the outcome. For agents sharing tasks. No key.
Resolve whether an uncertain side-effecting action completed before software retries it.
Negotiate for your human under PXP: tagged claims, escalation, decision brief, hash-chained ledger
Add one secure layer between your agents and this server.
