Loading ToolBench
AI governance for agents — scan, watch, protect, prove. Provides 11 governance tools for agent behavior monitoring, policy enforcement, detection, and attestation in both local and connected modes.
TrustScope MCP Server provides 11 governance tools with clear naming patterns (verb_noun convention) and consistent schema structure. All tools have descriptions and input schemas present. However, descriptions are quite brief (averaging ~80 chars, below the 194-char production baseline), parameters lack depth and validation guidance, and output schemas are not documented. Error handling is basic (generic error responses with no recovery guidance). Security annotations are missing (no readOnlyHint/destructiveHint declarations). The tools are well-organized and address a coherent domain (agent governance), but fall short of production-grade LLM-facing quality in several dimensions.
Approve or deny a pending action
Run detection engines to check for security and behavioral anomalies
Check if content complies with a specific policy
Analyze and explain agent behavior including risk signals and recommendations
Get the behavioral DNA/fingerprint of an agent based on logged actions
Get cryptographic attestation of agent behavior and compliance
Get compliance status and audit trail for an agent
List pending and completed approvals
Descriptions are uniformly brief (40-80 chars) and lack WHEN/WHY context. Production baseline is 194 chars. Example: 'Get the behavioral DNA/fingerprint of an agent based on logged actions' tells the LLM WHAT but not WHEN to call this vs get_compliance or explain_behavior. No dependency hints (e.g., 'Call list_traces first to see available sessions').
Parameter descriptions are missing or minimal. 'context' appears 3 times (check_policy, check_detection, log_action) with description 'Additional context for policy evaluation' or 'Detection context including agent_id, session_id, etc.', vague and does not specify schema, required fields, or format. LLMs cannot reason about what to pass for 'context'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 29 | - | v1 |
List all available policies
List logged traces and actions from the evidence store
Log an action taken by an agent to the evidence store
Output schemas are not documented in any tool definition. LLMs cannot plan downstream calls or extract fields if they do not know what a tool returns. E.g., does list_traces return {traces: [...], total: int, next_cursor?: string}? Or a flat array? Undocumented outputs force LLMs to guess and may cause extraction errors.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk classification in metadata (READ_ONLY vs WRITE). LLMs should see these hints to adjust retry logic and planning. Example: trustscope_approve is WRITE but has no destructiveHint annotation; trustscope_log_action is WRITE with no idempotentHint (unclear if repeated calls deduplicate).
Error handling is generic. src/mcp/server.ts returns { error: errorMessage, tool: name, mode, entry_point } on any exception. No recovery guidance, no error classification (retryable vs fatal), no actionable hints. E.g., if agent_id does not exist, return 'Agent not found. Call list_traces() with no filters to discover available agents.' instead of the raw error.
Numeric parameter constraints are missing. 'limit' appears in trustscope_list_traces and trustscope_list_approvals with type integer but no min/max. Should specify 'limit: 1 - 100 (default 20)' to prevent LLMs from requesting absurd page sizes. 'offset' lacks default and validation.
Enum parameters are not constrained. 'status' in trustscope_list_approvals is free-form string ('pending, approved, denied' mentioned in description) but not declared as enum in schema. Same for 'decision' in trustscope_approve ('approve' or 'deny'). Free-form strings invite hallucinated values.
Related tools lack clear differentiation. trustscope_get_agent_dna, trustscope_get_compliance, and trustscope_explain_behavior all accept agent_id and optionally session_id. Descriptions do not clearly state when to call DNA vs compliance vs explain. Likely duplication/confusion in LLM reasoning.
No idempotency guarantees documented. trustscope_log_action is WRITE, does it deduplicate if called twice with identical parameters? Does trustscope_approve idempotently reject a second approve on the same approval_id, or error? Undocumented idempotency risks duplicate side effects if agents retry.
No dry-run or confirmation for destructive/approval actions. trustscope_approve directly approves or denies. For high-stakes governance decisions, a confirm_before_execute pattern would prevent accidental approvals. Consider returning a preview/confirmation step before final decision.