Loading ToolBench
Third-party cryptographic proof for AI agent API calls — MCP server providing audit trails, tamper-evident records, and compliance reporting
Server has 5 tools with clear naming (verb_noun pattern) and reasonable descriptions (100-250 chars). However, input schemas are partially visible but lack formal JSON Schema type declarations in the source code excerpt. Parameter descriptions exist but are inconsistent in detail. Output schemas are not documented. Error handling is present but generic. No tool annotations (readOnlyHint/destructiveHint). The certify_call tool is high-risk (WRITE) but lacks confirmation/dry-run pattern. Overall: fair quality with noticeable gaps in schema formality and output documentation.
Assess an MCP server's security posture and get a certified proof of the assessment. Analyzes the server's tool manifest for dangerous capability patterns (filesystem write, code execution, env access, network), detects drift from the previous baseline, and tracks version changes.
Call an external API and get a cryptographic proof of the transaction. Use this INSTEAD of calling the API directly when you need an auditable, tamper-evident record of what was sent and received. The proof is signed by ArkForge (independent third party), timestamped via RFC 3161, and anchored in Sigstore Rekor — not self-signed by your agent.
Retrieve the full cryptographic proof for a given proof ID. Returns the complete proof bundle: request/response hashes, parties, RFC 3161 timestamp, Sigstore Rekor log entry, and archive.org snapshot.
Check your ArkForge API usage and remaining credits for the current period. Returns your tier (Free / Pro / Enterprise), proofs used, proofs remaining, and the reset date.
Get a human-readable summary of what a proof certifies. Useful for explaining to a user or auditor what was independently verified, without reading raw JSON.
Input schemas lack formal JSON Schema type declarations. Parameters are documented in docstrings but not in structured schema format visible in code. This prevents LLMs from validating inputs before calling.
Output schemas are not documented. Tools return JSON strings but the structure of returned objects (fields, types, nesting) is not formally specified. LLMs cannot plan downstream tool calls without knowing what fields to expect.
certify_call is a destructive/write operation (Risk: WRITE) but lacks confirmation or dry-run pattern. Agents could accidentally call external APIs without explicit user approval, risking unintended side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read-only tools from destructive ones without explicit hints. certify_call and assess_mcp_server should be marked destructiveHint=true.
Error messages are generic strings ('Error: ...') rather than structured error objects with classification (retryable, user-fixable, fatal). LLMs cannot determine recovery strategy from unstructured error text.