LLPRO Campus

Check work and get a signed stamp

countersign_stamp

Use when you need an independent, signed check of work you or another agent produced (a report, calculation, summary, filing draft or code) before relying on it or handing it on. Countersign re-computes arithmetic, looks up quotes and values in the cited sources, opens links and parses code, then returns a signed stamp (pass, fail or inconclusive) saying exactly what is wrong, with time and method. The stamp is kept in a public log. It never checks work it produced.

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": {
      "output": "<output>",
      "producer": "<producer>"
    },
    "name": "countersign_stamp"
  }
}

Input Schema

Name	Required	Description
`kind`	No
`claims`	No	Optional explicit items: {type:'arithmetic', expression, claimed} or {type:'quote', source_url, quote} or {type:'value', source_url, value}
`output`	Yes	The work to check, as text (max 100000 chars). Equations written as '12 * 4 = 48' are re-computed.
`private`	No	If true the public log shows only a hash of each finding's detail; you still get the full detail
`sources`	No	Optional cited sources: {url, quote?}
`language`	No	For code: python or json get a syntax check
`producer`	Yes	Who made the work: {agent_id, model}. Required; used for the independence rule.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, and the description adds real substance on top: what the checker actually does (re-computes arithmetic, looks up cited quotes/values, opens links, parses code), the shape of the result (pass/fail/inconclusive plus what is wrong, time and method), and that the stamp persists in a public log. The public-log disclosure is important behavioral context an agent would not get from the annotations alone. It does not discuss cost, latency, or failure behavior when sources are unreachable, so a 4 rather than a 5.

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 'Use when' trigger, then the mechanism, then the result and the public-log caveat. Every sentence carries information and there is no filler. The single dense paragraph could be broken into trigger/mechanism/result segments for faster scanning, which keeps it off a 5.

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 7-parameter tool with nested objects and no output schema, the description still conveys the verdict vocabulary and what accompanies it (what is wrong, time, method), which is the key return information. Combined with 86% schema coverage and explicit annotations, an agent has enough to invoke it correctly. Minor gaps remain around behavior when cited sources are unreachable or the check times out.

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?

Schema description coverage is 86%, so the schema already explains output, claims, sources, private, language and producer. The description adds only marginal meaning, such as that equations written inline as '12 * 4 = 48' are re-computed and that producer feeds the independence rule. Baseline 3 is appropriate given the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it independently re-checks produced work and returns a signed pass/fail/inconclusive stamp. The scope is unusually concrete (arithmetic, quotes, links, code) and it explicitly rules out checking its own output. It stops short of naming how it differs from the related countersign_verify / countersign_log siblings, so it is clear but not fully sibling-differentiated.

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?

Opens with an explicit trigger: 'Use when you need an independent, signed check of work ... before relying on it or handing it on.' That covers the when-to-use case well, including the trust context that motivates it. It gives no explicit when-not conditions or named alternative tools, so it is a clear context rather than a full routing rule.

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

All LLPRO Campus 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?