Loading ToolBench
MCP server that makes the BSI IT-Grundschutz++ compendium queryable for AI agents and ISMS tooling.
Strong foundation with 9 well-named, verb-prefixed tools (get_, list_, search_, filter_) and comprehensive parameter schemas. All tools have descriptions (avg 180 chars, within baseline 194). Input schemas are complete with type constraints, enums, and min/max bounds. However, output schemas are not explicitly documented in the source, only inferred from return type annotations. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Descriptions are functional but lack dependency hints and discovery guidance.
Filter requirements by module, security level, effort range, and/or tag. Criteria combine with AND; the result is sorted by requirement id. At least one criterion is required. `security_level` is "normal-SdT" (standard) or "erhöht" (elevated). `min_effort`/`max_effort` express '>= n', '<= n', exactly n, or a band over the ordinal effort scale (0=mandatory/not assessed, 1=quick win, ... 5=complex; see the effort_level field for the full scale). `tag` matches case-insensitively.
Return catalog version, source commit, and license information.
Return aggregate catalog counts: totals by security level, effort, and tag. The by_tag keys also serve as tag discovery before filtering.
Return internal requirement-to-requirement cross-references ('related' or 'required'). Only requirements that have at least one such cross-reference appear as keys.
Fetch a single Grundschutz++ requirement or practice by its ID. Returns null if no requirement has that id.
Output schemas not documented. Return types are inferred from Python type hints (Requirement | None, list[Requirement], dict[str, list[str]]) but no explicit schema documentation visible for LLM consumption. LLMs cannot plan downstream tool calls without knowing response field structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 9 tools are read-only and idempotent, but this is not declared in the tool definitions. Clients cannot infer safety properties without explicit hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | <=2025-11-25 | v2 |
Fetch multiple requirements by id in a single call. Returns one requirement per distinct found id, in first-seen input order. Ids not present in the catalog are skipped. Useful for following the related/required cross-references token-efficiently.
List all modules (Bausteine) in the catalog: id, title, and requirement count. Sorted by module id. Use this to discover which modules exist before calling list_requirements_by_module.
List all requirements belonging to a given Baustein/practice, in catalog (source) order.
Full-text search across requirement titles, texts, and tags (German). Results are returned in catalog (source) order.
Minimal error handling. No recovery guidance in error responses. filter_requirements raises ValueError if no criteria provided, but other tools have no visible validation or error classification (retryable vs user-fixable vs fatal). Agents cannot self-correct.
Descriptions lack discovery and dependency hints. E.g., list_modules says 'Use this to discover which modules exist before calling list_requirements_by_module' but other tools do not explain when to call them or what to do if a lookup fails. No guidance on chaining tools.
No pagination or result limits documented. filter_requirements and search_requirements could return large lists (e.g., all requirements matching a tag). No limit parameter, no offset/page parameter, no total count in response. Large results risk context window exhaustion.