Loading ToolBench
A Model Context Protocol server that provides Claude with access to AzerothCore MySQL databases (world, characters, auth), Wiki documentation for SmartAI and database schemas, and helper tools for understanding creature scripts and game mechanics
AzerothCore MCP server has 27 tools with consistent naming (verb_noun pattern), descriptions on every tool, and basic parameter schemas. However, definitions lack depth. Most descriptions are functional but generic (average ~120 chars, well below the 194-char production baseline). Output schemas are not documented, we cannot verify what fields queries return or what the API contract guarantees. Parameter descriptions exist but are sparse (many are 1-2 sentences). Error handling is minimal; no recovery guidance or categorization visible in definitions. Security is a concern: three tools (query_world_database, query_characters_database, query_auth_database) expose raw SQL query parameters with minimal constraint, creating injection risks. SOAP tool (soap_execute_command) accepts arbitrary command strings. Pagination is inconsistent, some tools have 'limit' params, others don't specify result bounds. The tool composition is reasonable (distinct concerns), but chaining IDs are not guaranteed in output schemas. No validation rules visible in parameter descriptions (e.g., what range of limit values are valid?).
Check and explain database conditions (loot, gossip, spell, etc.)
Execute programmatic investigation using other tools in sequence
Explain a SmartAI script in plain language
Find related entries (loot, scripts, spawns) for an entry
Generate descriptive comments for SmartAI scripts using Keira3 generator
Get reference data for condition types and source types
Get creature loot drop table and conditions
Output schemas not documented. Tools like get_creature_template, get_spell_info, get_quest_info have no visible documentation of returned fields. LLM cannot verify what data is available or plan downstream tool calls without guessing.
Raw SQL query parameters (query_world_database, query_characters_database, query_auth_database) accept untrusted LLM input with minimal validation. SQL injection risk: LLM could be tricked via prompt injection to craft malicious queries. Parameter descriptions do not document constraints or validation rules.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get complete creature template information including combat, loot, and scripting data
Get spell data from DBC files directly
Get gameobject template information
Get item template information
Get spell proc system reference data (proc flags, spell types, hit masks)
Get complete quest information including objectives and rewards
Get SmartAI action types and parameters reference data
Get SmartAI event types and triggers reference data
Get SmartAI scripts for a creature or gameobject
Get SmartAI target types and parameters reference data
Search AzerothCore source code for SmartAI implementations or configurations
Get complete spell information from database or DBC
List all creatures spawned in a zone
Parse WowPacketParser output or binary packet data
Query the AzerothCore auth database (accounts, security, etc.)
Query the AzerothCore characters database (player data, inventory, etc.)
Query the AzerothCore world database (creatures, items, spells, etc.)
Search wiki documentation for SmartAI and database schemas
Execute SOAP remote commands on running AzerothCore server
Visualize creature waypoints or patrol routes in 2D/3D
soap_execute_command accepts arbitrary command strings with no enum or validation. Parameter description does not specify valid command format, range, or examples. Injection risk: LLM could pass commands it was prompted to execute by a user.
Parameter descriptions are sparse and lack actionable guidance. E.g., 'Maximum number of rows to return' for 'limit' parameter does not specify min/max bounds (is 1 valid? 1000000?). Descriptions average ~40-60 chars; production baseline is 72 chars.
No pagination strategy documented. Some tools (list_creatures_in_zone, query_*) have limit params, but no total count or cursor returned. Large result sets could exhaust context window. Tools returning lists should offer offset/limit + total_count or next_cursor pattern.
No error recovery guidance visible. Descriptions do not explain what to do if a query fails, entry not found, or wiki not available. Error responses should include 'Try search_wiki()' or similar recovery suggestions.
Tool descriptions are functional but generic. Average length ~120 chars; production baseline is 194 chars. Many descriptions state WHAT but not WHEN to use or prerequisites. E.g., 'Get creature loot table' vs 'Get creature loot table. Use after get_creature_template to find creature_entry. Returns item_entry, drop_percent, drop_group. Useful for analyzing rewards and farming routes.'
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). All tools are marked READ_ONLY in risk field, but this is metadata, not a protocol-level annotation. LLM cannot infer safety from the definition alone.