Proxy a JSON-RPC tools/list or tools/call request to an upstream MCP server. Cyphrex enforces threat policy before the caller receives the upstream result.
| Name | Required | Description | Default |
|---|---|---|---|
| agentId | Yes | ||
| message | Yes | ||
| upstreamUrl | Yes | ||
| upstreamSessionId | No | ||
| upstreamAuthorization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds one key behavioral trait: Cyphrex enforces threat policy before returning results. However, it does not disclose details such as session handling, auth requirements, error behavior, or what happens when policy is violated, leaving meaningful gaps.
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?
The description is a single sentence of about 20 words, no filler, and front-loads the key action. Every phrase adds value.
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?
The tool is moderately complex (5 params, nested object, no output schema). The description lacks critical context: how to construct the message, purpose of agentId, session/auth flows, and behavior on policy rejection. It is not complete enough for an agent to invoke reliably without additional information.
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%, so the description must compensate. It clarifies that 'upstreamUrl' is an MCP server and 'message' is a JSON-RPC request, but provides no meaning for 'agentId', 'upstreamSessionId', or 'upstreamAuthorization'. With 5 parameters, this is insufficient.
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 clearly states the tool's function with a specific verb ('Proxy') and resource ('JSON-RPC tools/list or tools/call request to an upstream MCP server'). It differentiates from sibling tools (e.g., scan_mcp_tool_result, scan_mcp_tools_list) by focusing on the proxying action itself, not scanning results.
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 implies when to use the tool: when you need to proxy MCP requests while enforcing threat policy. However, it doesn't explicitly mention alternatives or exclusions, though sibling tool names provide context. This is clear usage context without formal exclusions.
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.
Each tool targets a distinct action: checking proposed actions, logging/reading audit data, proxying requests, registering/verifying agents, scanning different payload types, and setting profiles. The separation between check_action and scan_mcp_tool_result is clear from their descriptions (proposed action vs. upstream result).
All tool names follow a consistent verb_noun snake_case pattern (e.g., check_action, get_audit_log, set_behavior_profile). No mixing of styles or vague verbs beyond standard operation names.
With 9 tools, the set is well-scoped for a security-focused MCP governance server. Each tool addresses a clear need without redundancy or excessive granularity.
The tool set covers the core lifecycle: agent registration, verification, behavior profiling, action checking/logging, audit retrieval, proxying, and scanning. Minor gaps include no explicit agent removal or policy management tools, but these may be intentionally outside the server's scope.
