Loading ToolBench
A realistic multi-tool MCP server designed to run inside an Azure Confidential Container on ACI (AMD SEV-SNP). Demonstrates credential aggregation via trusted execution environments with hardware-attested secret decryption.
The MCP TEE Server exhibits severe definition quality gaps across all four tools. While the server demonstrates sophisticated cryptographic and TEE integration concepts (attestation, SKR key release, OAEP decryption), the tool definitions themselves lack fundamental MCP compliance: no input schemas are visible in the source code for any tool, three of four tools have descriptions under 20 characters, parameter descriptions are completely absent, and output schemas are undocumented. The codebase shows the server.py file is truncated mid-function, preventing full analysis of tool registration. Tool names follow verb_noun convention (positive), but lack the supporting schema infrastructure required for production agent use. The attestation_status tool's empty input object {} and the demo.ps1 location of tool definition (non-Python source) suggest incomplete or exploratory implementation.
Report TEE status, proof of hardware-enforced memory encryption, and loaded secrets
Search GitHub issues (needs GITHUB_TOKEN)
Run read-only SQL queries (needs DB_CONNECTION_STRING)
Post to a webhook/Slack (needs WEBHOOK_URL)
No input schemas visible for any of the four tools. Source code shows tool definitions but schema registration is truncated or missing.
Three of four tool descriptions are extremely brief (under 20 characters): 'Search GitHub issues (needs GITHUB_TOKEN)' (43 chars, acceptable), 'Run read-only SQL queries (needs DB_CONNECTION_STRING)' (54 chars, acceptable), 'Post to a webhook/Slack (needs WEBHOOK_URL)' (44 chars, acceptable), 'Report TEE status...' (~20 chars). Descriptions lack context for LLM tool selection: no explanation of WHEN to use vs similar tools, no guidance on prerequisites or failure modes.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | 2025-06-18+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
No parameter descriptions visible in source code. github_search_issues presumably accepts search query, filters, and pagination (but undocumented). query_database likely accepts a SQL string and connection parameters (but undocumented). send_notification likely accepts webhook URL, payload, and metadata (but undocumented). Without parameter descriptions, LLMs cannot infer what values to pass or what formats are expected.
Credentials embedded in tool descriptions as prerequisites ('needs GITHUB_TOKEN', 'needs DB_CONNECTION_STRING', 'needs WEBHOOK_URL') suggest environment variable injection, but the pattern is not validated in the tool schema. PATTERN VIOLATION: credentials must not appear as tool parameters, but here they are named in descriptions without explicit declaration of whether they are server-injected or user-provided. The server.py code shows secrets are loaded via SKR (correct), but tools do not declare their access to these secrets.
No output schemas documented. It is unknown what github_search_issues returns (list of issues with what fields?), what query_database returns (rows, columns, metadata?), what send_notification returns (status, response body?), or what attestation_status returns (attestation report format?). LLMs cannot plan downstream tool calls or extract required fields without documented return types.
No error handling or recovery guidance in tool descriptions. LLMs do not know: if github_search_issues returns 0 results, should it retry with broader terms or ask the user? If query_database fails due to invalid SQL, should the agent report the error or suggest syntax corrections? If send_notification fails due to webhook timeout, is it retryable? Absence of this guidance violates pattern:recovery-guide.
query_database accepts arbitrary SQL as a parameter, creating SQL injection risk if LLM-provided input is not sanitized. Tool description does not restrict to read-only queries (though Risk label says READ_ONLY). No validation against DDL/DML. query_database should validate that the SQL contains only SELECT statements and reject INSERT/UPDATE/DELETE/DROP/ALTER.
send_notification is declared WRITE risk but has no confirmation or dry-run capability. An agent calling send_notification should confirm the payload before posting to a webhook (which might trigger an integration or alert). Pattern:confirmation-request not implemented.
attestation_status is defined in scripts/demo.ps1 (PowerShell demo), not in src/server.py. This suggests the tool is exploratory or not fully integrated into the MCP server.