Loading ToolBench
MCP server on the official SDK with Kerberos (SPNEGO) authentication. Provides Kerberos-authenticated access to tools with per-tool IPA group authorization policy.
Server has 4 tools with clear names and descriptions. All tools have input schemas with type definitions. However, descriptions vary significantly in quality: whoami and list_projects are concise (34-45 chars), while trigger_build is excessively verbose (600+ chars, violates 1024-char guideline by burying key details). Parameter descriptions are present but minimal. No output schemas documented. Error handling is implicit (PermissionError raised) but lacks recovery guidance. Tools follow verb_noun naming convention well. Security-focused design with require() and forward_header() patterns is excellent, but this is implementation detail, not definition quality.
List projects visible to the caller.
Restart a managed service (privileged).
Trigger a CI build as the caller, so the downstream logs the human rather than this service. CI is just one example. Delegation forwards to any Kerberized downstream service the caller could reach: an internal REST API, a directory, a database proxy, a second MCP server. This tool illustrates the pattern with a CI build because "trigger a build as me" is easy to picture; the mechanism knows nothing about CI. Point TOOL_TARGETS at whatever service you actually forward to. The template for every forwarding tool. Copy this shape: p = require(ctx, '<my_own_name>') # authorize, always first h = forward_header(ctx, '<my_own_name>') # same literal, never computed ... send h as the Authorization header ... Both calls take this function's own name as a literal. Passing another tool's name would run under that tool's group policy or reach that tool's downstream service, and tests/python/test_tool_policy_invariant.py fails the build if either literal drifts. Inert until an operator sets MCP_DELEGATION=1 and names a target for 'trigger_build' in MCP_DELEGATION_TARGETS; without both, forward_header raises and this returns an error rather than quietly acting as the service account. The HTTP call is left as a stub deliberately. Minting the ticket is the part that is hard to get right and the part this repo owns; which endpoint your downstream service exposes is site-specific, and a half-guessed request here would be a worse starting point than none. Send `h` as the Authorization header from whatever client you already trust.
trigger_build description is 600+ characters, violates 10-1024 guideline and buries actionable details. Excessive explanation of delegation pattern obscures what the tool actually does.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields without knowing return structure.
Parameter descriptions are minimal or absent. 'name' in restart_service and 'job' in trigger_build lack detail on format, constraints, or examples.
Error handling raises PermissionError with minimal context. No recovery guidance (e.g., 'Try with a different principal' or 'Contact admin').
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Return the caller's authenticated Kerberos principal.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Risk levels are declared in metadata but not in tool definitions.