proofrelay.wrap_mcp_tool_evidenceConvert hash-only MCP tool request, response, schema, authority, and payment context references into a portable ProofRelay evidence wrapper without ingesting raw prompts, outputs, credentials, or logs.
| Name | Required | Description | Default |
|---|---|---|---|
| tool_evidence | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description meaningfully adds behavioral clarity: it explicitly states the tool only accepts hashes and does not ingest raw data—important context about privacy/safety boundaries beyond the annotations. It doesn't describe failure modes or error handling, but for a pure wrapping tool this is solid transparency.
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 packs in verb, resource, constraints, portability outcome, and privacy exclusions. No wasted words. Front-loads the action and specifies the security boundary at the end.
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?
Given the sensitive security context (hashing raw references, handling secrets), the description's note about 'non-secret refs' and the exclusion of 'raw... credentials' is well-placed. The annotations cover read-only/idempotency, the output schema exists, and the input schema is quite descriptive on its own. The description could theoretically mention what happens if invalid hashes are passed, but for a stateless wrapping operation this is near-complete.
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 single parameter is a nested object with a mix of required and optional fields. The description provides security context (mentions 'payment context references', 'authority', 'non-secret refs'), which adds mild meaning beyond the field names. However, it doesn't describe field-level semantics like expected hash formats (hex? base64?), which would meaningfully help agents construct valid input. The description's 'hash-only' framing is helpful but doesn't fully compensate for the lack of field documentation.
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 uses a specific verb (Convert) and identifies a precise resource (hash-only MCP tool request/response references into a ProofRelay evidence wrapper). It clearly distinguishes itself from sibling tools by naming the wrapping/conversion functionality and the input constraints (hash-only, no raw data).
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 clearly implies when to use this tool (when hash-only references are available and a portable wrapper is needed) and explicitly states what it does not do ('without ingesting raw prompts, outputs, credentials, or logs'). While alternatives are not named, the exclusion criteria is strong guidance for an agent deciding between this and related proof-construction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
All 26 tools have distinct names that clearly indicate their purpose (e.g., adapt_agent_identity_evidence vs. build_audit_pack_manifest). No two tools have overlapping or ambiguous functions, even though some share similar verbs; the nouns and description contexts differentiate them effectively.
The tool names follow a uniform convention: all start with 'proofrelay.' and use lowercase verb_noun with underscores (e.g., proofrelay.build_bundle_draft, proofrelay.verify_signed_attestation). There is no mixing of camelCase, across the entire set.
The server exposes 26 tools, which exceeds the 'borderline' range of 16–25 and falls into the 'too many' category (>25). While the tools cover a broad domain (evidence verification, risk scanning, etc.), the large number might overwhelm agents and suggests that some tools could be merged or the scope narrowed.
The tool set covers a comprehensive range of operations—adapting, building, verifying, scanning, recommending, and summarizing—across multiple subdomains (identity, payment, audit, etc.). Minor gaps exist, such as missing tools for updating or deleting evidence, but overall the surface appears very complete for the described functionality.