Loading ToolBench
Spring Boot REST API server for ISMS (Information Security Management System) checklist management with Ollama LLM integration for security analysis
This MCP server has severe definition quality gaps. While 5 tools are registered with basic descriptions, the parameter schemas are inconsistent, descriptions lack LLM-optimized guidance, and critical parameter documentation is missing. Most tools lack meaningful input validation hints or recovery guidance. The server exposes security-sensitive operations (create, receiveIsmsChecklist) without permission gates or confirmation patterns. No output schemas are documented. Average tool description length is ~120 chars (below the 194-char baseline), and parameter descriptions are sparse or absent.
Analyzes an ISMS checklist by sending it to Ollama LLM and returns security analysis
Creates a new checklist entry
Retrieves all checklists from the database
Retrieves all ISMS checklists from the database for UI display
Receives and saves an ISMS checklist payload to the database
Parameter descriptions are missing or incomplete. The 'create' tool accepts a 'checklist' object with 'id' and 'content' fields, but no descriptions explain what values are valid, whether 'id' is auto-generated or user-provided, or what content format is expected (free text? max length? required fields?). The 'receiveIsmsChecklist' tool payload has field descriptions in the schema, but they lack context on valid ranges, formats, or dependencies (e.g., does 'logRetentionDays' accept any positive integer or specific ranges like 7 - 365?).
No output schemas documented. Tools like 'getAll' and 'getAllIsmsChecklists' return lists of checklists, but there is no specification of what fields each checklist object contains, what types they are, or what the response structure looks like. This forces LLMs to guess and prevents effective chaining (e.g., an LLM cannot know what ID field to extract for a downstream tool call).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 38 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Missing error handling and recovery guidance. No tool description states what errors are possible (e.g., database unavailable, invalid ID, duplicate checklist) or what the LLM should do next. The 'analyzeIsmsChecklist' tool calls an external Ollama LLM, if Ollama is down, does the call hang? Timeout? What does the error response look like? Without this, agents cannot gracefully handle failures.
Destructive operations lack confirmation or dry-run patterns. The 'create' and 'receiveIsmsChecklist' tools perform writes without documented idempotency or retry safety. An agent retrying a failed 'create' call might create a duplicate checklist. The rubric requires either idempotency guarantees or a confirmation pattern for state-modifying tools.
Generic parameter names without type suffixes. The 'analyzeIsmsChecklist' tool has an 'id' parameter described as 'ISMS Checklist ID to analyze', acceptable, but other tools like 'create' use 'checklist' as a parameter name without clarifying whether it expects an object with nested fields or a reference ID. Following the baseline pattern (user_id, user_name, user_email), parameters should be explicit about what they accept.
No pagination or result limiting documented. The 'getAll' and 'getAllIsmsChecklists' tools return lists with no stated limit, offset, or total count. If the database has 10,000 checklists, these tools could return all of them, exhausting token budgets. Best practice requires page_size/limit and total_count in the output schema.
No permission gates or audit trails documented. The 'create' and 'receiveIsmsChecklist' tools perform writes without any mention of authentication, authorization, or logging. A misconfigured agent could create or overwrite arbitrary checklists. Security patterns require explicit scope declarations and audit logging.