Loading ToolBench
MCP server exposing AgentProvenance's AI tool surface for querying verifiable provenance graphs, evaluating proposed agent actions through a trusted policy gate, and recording application-asserted context. Implements the Model Context Protocol (MCP) as a stdio JSON-RPC 2.0 server.
AgentProvenance defines 8 tools with complete input schemas and descriptions. Naming follows verb_noun convention (verify_run, get_signals, list_risks, list_events, get_timeline, evaluate_action, bind_scope, record_tool_call). All tools have descriptions (avg 150 chars, within 10-1024 range). Schemas are properly typed with required fields. However, output schemas are NOT documented, LLMs cannot predict return structure. Parameter descriptions are present but sparse (e.g., 'run id' lacks context on format/length). Error handling is absent from tool definitions. No guidance on when to call each tool vs. alternatives. Risk annotations (READ_ONLY, WRITE) are present but not formalized as MCP readOnlyHint/destructiveHint.
Register a ToolCallScope binding: assert that this run+tool_call ran as the given OS process/container/cgroup so independent system telemetry can later be correlated to it (zero-instrumentation). This is APP-ASSERTED context only -- the binding is recorded with source ai_asserted and cannot fabricate system events or signatures; it merely provides a join key the trusted correlation engine may use when real kernel events arrive.
Pre-flight gate: evaluate a PROPOSED agent action against the security policy WITHOUT executing it. Returns a verdict (allow|deny|quarantine|kill) computed by the trusted engine. Call before running a tool/command/connection.
List the unified signals (behavior/cost/quality/security) attached to a run's causality graph.
Get the merged application-context + runtime-telemetry timeline for a run.
List runtime telemetry events for a run (paged), optionally filtered by event type.
List the security risk signals (metadata-IP, private-CIDR, secret-path, etc.) raised for a run, with recommended actions.
Output schemas not documented. LLMs cannot predict return structure (fields, types, nesting). Forces agents to guess what data is available for downstream calls.
Parameter descriptions are minimal (e.g., 'run id', 'optional event_type filter'). Missing format constraints, length limits, and dependency hints. LLMs cannot validate inputs before calling.
No error handling guidance in tool definitions. Agents cannot distinguish retryable errors from user-fixable ones. No recovery hints (e.g., 'run not found, try list_runs first').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2025-06-18+ | v2 |
Record an APP-ASSERTED tool call: anchor that this run invoked the named tool/command, returning a tool_call id you can then bind_scope to a process. This does NOT execute anything and does NOT create system evidence; the row is stored with status/policy_decision 'asserted' so consumers can tell it apart from a gate-decided or kernel-observed call.
Verify a run's evidence chain (object hashes, parent links, policy->risk->response->signal integrity). Returns status ok|failed with any issues.
Risk annotations (READ_ONLY, WRITE) are metadata but not formalized as MCP tool annotations (readOnlyHint, destructiveHint). Clients cannot auto-detect safe vs. unsafe tools.
list_events accepts 'limit' parameter but no pagination cursor/offset. Large result sets will blow context window. No guidance on default/max limits.