Loading ToolBench
AI agent firewall — policy engine for tool call authorization with approval workflows
Rampart is an HTTP-based policy engine proxy, NOT an MCP server. It exposes 19 HTTP REST endpoints, not MCP tools. The tool definitions provided are REST API endpoints masquerading as MCP tools. None of these tools have visible JSON Schema input definitions, descriptions are minimal (10-40 chars typically), and there is no evidence of MCP tool registration, resource/prompt support, or structured error reporting. The server appears to be a standalone policy enforcement proxy for AI agents, not an MCP-compliant tool server. Per the rubric: tools with no visible input schemas score 0 for schema; missing/trivial descriptions score 0-20; tools inferred rather than explicitly registered cap at 50. Since ALL 19 tools lack visible schema definitions in the source code and descriptions are generic HTTP endpoint descriptions (not LLM-optimized tool descriptions), the overall definition quality is critically low.
Apply patches to files with policy-based authorization
OpenClaw bash tool alias mapping to Rampart exec policy class
Browser automation tool with policy-based authorization
Canvas tool with policy-based authorization
Edit files with policy-based authorization
Execute shell commands with policy-based authorization and approval workflows
Fetch URLs with policy-based authorization
Server is NOT an MCP server; it is a policy engine HTTP proxy. All 19 'tools' are REST API endpoints, not MCP tools. No evidence of MCP tool registration, protocol compliance, or structured schemas in source code.
ZERO input schemas visible in source code for any of the 19 endpoints. Input parameter definitions are inferred from HTTP request structure, not declared as JSON Schema.
Descriptions are trivial HTTP endpoint descriptions (10-20 chars), NOT LLM-optimized tool descriptions. Rubric requires 50-200 chars with context on WHAT, WHEN, and WHY. Examples: '/v1/approvals': 'List all pending approval requests' (6 words); '/v1/status': 'Get proxy server status' (4 words).
No parameter type constraints, enums, defaults, or validation rules visible. Parameters are bare field names (agent, session, params, tool, command, approved, etc.) with no JSON Schema type/format/enum/pattern/minimum/maximum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 18 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 14 | - | v1 |
Find files with policy-based authorization
Search file contents with policy-based authorization
Image tool with policy-based authorization
List directory contents with policy-based authorization
Send messages with policy-based authorization
Read file contents with policy-based authorization
Fetch web content with policy-based authorization
Search the web with policy-based authorization
Write file contents with policy-based authorization
No documented output schemas or response structures. Agents cannot plan downstream calls if they do not know what fields are returned. Example: GET /v1/approvals returns list but pagination, field names, and structure unknown.
Destructive operations (DELETE /v1/rules/auto-allowed/{index}, POST /v1/policy/reload, POST /v1/approvals/{id}/resolve with approved:false) lack confirmation/dry-run patterns and proper error guidance.
Parameter naming inconsistencies and ambiguities: 'params' is overloaded (POST /v1/tool/{toolName} input param vs tool-specific parameters); 'approved' boolean unclear in resolve endpoint (does true mean approve or reject?); generic 'id' in DELETE without context.
No error handling guidance. Endpoints have no documented error responses, recovery paths, or actionable error messages. Example: DELETE /v1/rules/auto-allowed/{index} fails if index out of range, no error schema or guidance on available indices.
No pagination guidance or limits. List endpoints (GET /v1/approvals, GET /v1/audit/events) accept limit and offset but no min/max constraints, default values, or large result handling documented.
No tool composition support. Endpoints operate in isolation with no cross-references. Example: POST /v1/approvals creates approval request but does not return approval_id needed for subsequent GET /v1/approvals/{id} or POST /v1/approvals/{id}/resolve.