Loading ToolBench
An MCP server providing access to OWASP CheatSheetSeries content via HTTP endpoints for listing, retrieving, and searching cheat sheets.
The server provides three READ_ONLY tools for accessing OWASP cheat sheet content. Tool names follow verb_noun convention (list_*, get_*, search_*) which is good. Descriptions exist but are brief (14-106 chars) and lack context on WHEN to use each tool or dependencies between them. The get_cheatsheet tool has a reasonable parameter description ('The name of the cheat sheet file to retrieve (e.g., 'Authentication.md')'), but examples in descriptions violate the anti-pattern (LLMs reuse literal examples). Input schemas are minimal but present: list_cheatsheets has empty object {}, get_cheatsheet has a single string parameter 'name', and search_cheatsheets has a single string parameter 'q'. Output schemas are not documented in the source code. Error handling is present (HTTPException for 404, 500) but returns generic HTTP status codes without recovery guidance. No output documentation means LLMs cannot plan downstream operations. Parameter descriptions mention examples rather than constraints, and the search tool's 'q' parameter lacks a description entirely in the visible code (just referenced as a query parameter).
Retrieves the full content of a specific OWASP cheat sheet by name
Lists all available OWASP cheat sheets as markdown files in the cheatsheets directory
Searches all cheat sheets for content matching a query string and returns matching filenames
Output schemas are not documented. LLMs cannot infer what fields to expect from list_cheatsheets, get_cheatsheet, or search_cheatsheets responses. list_cheatsheets returns {"cheatsheets": [...]}, get_cheatsheet returns plaintext, search_cheatsheets returns {"results": [...]}, but these are not formally declared in the tool definitions visible in the code.
Tool descriptions are too brief (14-106 chars; baseline median 194 chars) and lack guidance on WHEN to use each tool or prerequisites. E.g., list_cheatsheets description (14 chars) does not explain that users should call this first to discover available sheets before calling get_cheatsheet.
Example values appear in parameter descriptions ('e.g., 'Authentication.md'') instead of formal constraints. LLMs tend to reuse example values literally, risking failed calls if cheat sheet names differ. Replace with an enum of valid names or a pattern constraint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
Error responses return HTTP status codes (404, 500) without actionable guidance for LLMs. 'Cheat sheet not found' does not tell the agent to call list_cheatsheets to discover valid names or check the spelling. Errors should include recovery hints.
Parameter descriptions are missing or incomplete. The search_cheatsheets 'q' parameter description is not visible in the tool definition schema shown in the problem statement; it only appears as a FastAPI query parameter. The description should explain the search semantics (e.g., 'case-insensitive substring match' vs regex vs full-text).
get_cheatsheet returns plaintext content without structure. Large cheat sheets could overwhelm the context window. No pagination, limits, or summary mechanism is offered. Baseline pattern: tools returning large content should accept a 'limit' or 'snippet' parameter and return metadata (total_chars, is_truncated).