Loading ToolBench
FastMCP server for Wazuh API operations providing comprehensive access to agent management, security operations, RBAC, rules, active response, and cluster management
This server has 32 tools with moderate-to-poor definition quality. While tool names follow verb_noun convention (get_*, create_*, delete_*), descriptions are generic and lack actionable context. Parameter schemas are present but under-specified: many lack minimum/maximum constraints, enum values, and detailed format descriptions. Most critically, output schemas are not documented, we see only input parameters. Error handling guidance is absent. The server mixes domain logic (Wazuh operations) with a single out-of-place Wikipedia tool, violating single-responsibility composition. STDIO-only transport is a hard blocker for production use.
Add a new agent to the Wazuh manager
Add an agent to a group
Analyze Wazuh security logs with detailed analysis and threat intelligence
Create a new agent group
Create a new Wazuh API user
Delete an agent from the Wazuh manager
Delete an agent group
Output schemas not documented. Rubric requires 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' No response structure is defined for any tool; only inputs are documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | - | v1 |
Delete a Wazuh API user
Search Wikipedia and fetch the introduction of the most relevant article. Always use this if the user is asking for something that is likely on wikipedia. If the user has a typo in their search query, correct it before searching.
Get active response commands
Get configuration of a specific agent
Get detailed information about a specific agent
Get a list of all agents with status and details
Get summary statistics about all agents
Get security alerts from Wazuh
Get list of nodes in the Wazuh cluster
Get the status of the Wazuh cluster
Get list of log decoders
Get file integrity monitoring data
Get list of agent groups
Get detailed information about the Wazuh manager
Get manager logs
Get the status of the Wazuh manager
Get rootkit detection data
Get a list of Wazuh detection rules
Get list of Wazuh API users
Get vulnerability detection data
Remove an agent from a group
Restart a specific agent
Run an active response action on an agent
Search alerts with filtering and pagination
Update configuration of a specific agent
Destructive tools (delete_agent, delete_group, delete_user) lack error handling guidance and confirmation mechanisms. Rubric requires: 'Error responses must tell the LLM what to do next' and 'Irreversible operations should support a dry-run or confirmation step.' None of these tools indicate how failures should be handled or provide recovery guidance.
Parameter descriptions lack actionable format specifications. Most parameters (limit, offset, agent_id, status, etc.) have minimal descriptions without constraints. E.g., 'limit' and 'offset' lack min/max bounds. 'status' for get_agents lists enum values in description as 'active, inactive, pending, never_connected' rather than using a formal enum constraint.
Inconsistent parameter naming conventions. Some tools use 'agent_id', but unclear which tools accept 'agent_name' vs 'agent_id'. Rubric states: 'When a parameter could be an ID, name, email, or position, suffix it with the type: user_id, user_name. A bare parameter leaves LLMs guessing.' Additionally, create_user accepts raw password parameter, never expose credentials as tool parameters (pattern:secret-injection).
fetch_wikipedia_content is out of scope. This tool is unrelated to Wazuh security operations and violates single-responsibility composition. Rubric: 'Each tool should do exactly one thing.' This tool must be removed or moved to a separate general-purpose server.
No error recovery guidance. None of the 32 tools include actionable error messages or recovery steps. Rubric requires: 'Error responses must tell the LLM what to do next: User not found. Try search_users() with a partial name.' A raw error code gives the agent nothing to act on.
Tool descriptions are generic and lack context for when to use each tool over similar alternatives. E.g., get_alerts and search_alerts both fetch alerts but their distinction is unclear. Rubric: 'A tool description must answer: What does it do? When should the LLM call it instead of a similar tool?' Current descriptions do not disambiguate.
No permission declarations or audit logging. Rubric requires: 'Each tool should declare what permissions it requires (e.g. read:email, write:calendar).' and 'Log who called what tool, with which parameters, at what time.' No access control model is visible.
No idempotency guarantees documented. Agents retry failed calls, if delete_agent or create_user are non-idempotent, repeated calls risk duplicate side effects (double deletion, duplicate users). Rubric: 'Make tools produce the same result on repeated calls with the same input.'
No batch variants for common loop patterns. Tools like add_agent_to_group and remove_agent_from_group likely to be called in loops. Rubric: 'Offer batch variants (e.g. add_labels taking an array vs single add_label). N sequential calls waste tokens and latency vs one batch call.'