dnd-oracle

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct D&D 5e subsystem (character building, encounters, spells, monsters, equipment, rules, etc.) with clear, non-overlapping purposes. Even closely related tools like 'build_encounter' and 'suggest_encounter' are differentiated by focus on XP math vs. tactical synergies.
Naming Consistency4/5
Most tools follow a consistent verb_noun snake_case pattern (e.g., build_character, search_spells), but a few use noun-first or compound noun names (magic_item_attunement, rest_calculator), representing a minor deviation from the dominant pattern.
Tool Count4/5
With 20 tools, the server covers a broad range of D&D 5e mechanics comprehensively. The count is slightly above the typical 3-15 range but each tool earns its place, covering everything from character building to encounter planning and rule lookups.
Completeness4/5
The tool surface covers core D&D activities: character creation, spell/equipment/monster search, encounter building, adventuring day planning, and rule lookups. Minor gaps like treasure generation or condition search are partially addressed (search_rules includes conditions), but the set is very thorough for a reference oracle.
Average 3.7/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- Last stable release on June 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must fully disclose behavior. It lists computed outputs but does not mention side effects, permissions, or return format. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the action and lists key outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should detail return values. It names calculations but not their structure. Lacks info on error handling or edge cases. Adequate for simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds minimal context: 'for encumbrance calculation' for strength_score. Does not explain item naming conventions or expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a D&D 5e equipment loadout and lists specific calculations (weight, cost, AC, encumbrance). This distinguishes it from sibling tools like search_equipment or build_encounter, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_equipment or build_encounter. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the computations performed (HP, saving throws, etc.) but does not disclose side effects, read-only nature, prerequisites, or limitations like whether it only supports official races/classes. With no annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded. The first sentence states the purpose, the second lists inputs and outputs. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main outputs but lacks detail on the output structure (e.g., JSON format) and potential constraints (e.g., only level 1-20, ability score order). Without an output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description repeats the input list ('given race, class, level, and ability scores') but adds no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a D&D 5e character summary with specific inputs (race, class, level, ability scores) and outputs (HP, proficiency bonus, etc.). It is specific but does not explicitly differentiate from siblings like browse_classes or analyze_party.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., browse_races for race info) or when not to use it. The description assumes the user knows the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It reports requirements and warnings but omits side effects, read-only nature, or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words, front-loaded with the primary action, and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters and no output schema, the description adequately covers what the tool reports, though it could mention that it uses standard D&D 5e rules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited value beyond schema. It contextualizes item_names as a set and current_attunement as affecting the warning, but no extra syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it analyzes attunement requirements and reports restrictions, with a specific verb and resource. It is distinct from siblings like analyze_loadout, though not explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies it is used for checking attunement of magic items but provides no guidance on when to use versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavior such as whether the tool is read-only, requires authentication, or has rate limits. The description only states what the tool does, not its side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no wasted words. The primary action is front-loaded in the first sentence, and the second sentence adds relevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. It only vaguely says 'lists all class-specific resources and their recovery cadence,' without specifying structure or detail. For a tool of moderate complexity, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters adequately. The description adds no additional semantics beyond the schema's parameter descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows what recovers on short vs. long rests for a D&D 5e character, listing class-specific resources. This specific verb-resource combination distinguishes it from sibling tools like 'build_character' or 'travel_calculator'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when planning rests, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though the context of sibling tools suggests this is the sole tool for rest recovery details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It names filter options but fails to detail how filters interact, pagination behavior, or response format, leaving significant gaps for an 11-parameter search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys all key filtering dimensions without any redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 11 parameters and no output schema, the description is too brief. It omits critical context such as how filters combine, result sorting, pagination details, and error handling, which are essential for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains all parameters. The description lists the same filters but adds no new semantics or constraints beyond what is in the schema, so it is adequate but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'D&D 5e SRD spells' and lists specific filtering criteria (name, level, school, etc.), making the purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching spells but lacks explicit guidance on when to use this tool versus siblings like search_monsters or search_equipment, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It mentions using SRD rules for pace, terrain, and exhaustion, but does not disclose output format, side effects, or any limitations beyond the schema. For a read-only calculator, this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. It is front-loaded with the core action and efficiently conveys scope and rule source.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain return values or format. Given the tool's simple purpose, it partially addresses needed context but omits what the user will receive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters described in the schema. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool calculates D&D 5e overland travel time, pace effects, and forced march consequences. It specifies using SRD rules, clearly distinguishing it from sibling tools like rest_calculator or plan_adventuring_day.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as plan_adventuring_day. The description does not include any exclusions or context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool produces a consolidated defense matrix and warns about gaps, which outlines its output behavior. However, it does not disclose whether it is read-only, any side effects, or permission requirements, leaving room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the purpose, and contains no redundant or extraneous information. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the output format (consolidated defense matrix and warnings) and the input constraints (monster group up to 20). It could be more detailed about the matrix structure or limitations, but it provides sufficient context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents both parameters well. The description adds little new information beyond what is in the schema parameter descriptions; it merely restates that party_damage_types warns about gaps. Thus, it meets the baseline without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks resistances, immunities, and vulnerabilities for a group of monsters, and specifies it produces a consolidated defense matrix and warns about party damage type coverage gaps. This is a specific verb+resource combination that distinguishes it from sibling tools like compare_monsters or simulate_damage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The context is implied (checking resistances for a monster group with party damage types), but no comparisons or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool calculates, suggests, and recommends, which are non-destructive planning actions. However, it does not explicitly state whether the tool modifies any state or stores data, leaving some ambiguity about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 16 words. It is front-loaded with the main verb 'Plan' and immediately states the key outputs, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not explain the output format (e.g., a structured object with XP budget, encounter difficulties, etc.). Given the tool's complexity (4 parameters, no output schema), the description could provide more detail on the return value to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The description adds a default behavior note for 'difficulty_mix' (defaults to balanced mix), which is helpful but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: planning a full D&D adventuring day, calculating XP budget, suggesting encounter difficulty distribution, and recommending short rest placement. It distinguishes itself from siblings like 'build_encounter' and 'suggest_encounter' by focusing on the day-level planning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use the tool (for planning a full day) but provides no explicit guidance on when not to use it or how it compares to alternatives like 'build_encounter' or 'suggest_encounter'. The sibling context offers some differentiation, but the description lacks direct usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool computes hit probability, crit chance, average damage, and turns to kill, but does not explain behavioral details such as how critical hits affect damage calculation (e.g., dice doubling) or how advantage/disadvantage influences probabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences with no redundancy. Every sentence adds value: first states high-level purpose, second lists computed outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description lists several computed outputs but does not clarify the return format, assumptions (e.g., damage on hit, critical damage calculation), or how edge cases like disadvantage are handled. It is adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 8 parameters. The tool description adds no additional parameter-level information beyond the general outputs, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates average damage per round for an attack routine, listing specific outputs like hit probability, critical hit chance, average damage, and turns to kill. This distinguishes it from sibling tools that analyze broader aspects like loadouts or encounters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for computing DPR of attack routines, but provides no explicit guidance on when to use this tool vs. alternatives like analyze_loadout or compare_monsters. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the outputs (saving throws, etc.) but does not disclose behavioral traits such as whether it is read-only, requires pre-existing party data, or has any side effects. The description is honest but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no wasted words. It is front-loaded with the main purpose and then lists specific outputs, achieving maximum efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description provides a clear list of analysis outputs (saving throws, role balance, skill gaps, etc.). It is largely complete for its complexity, though missing details like error conditions or prerequisite validations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the input schema already thoroughly describes the sole parameter 'members'. The tool description lists what the analysis identifies, but adds no extra meaning to the parameter itself beyond what the schema provides. Thus, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'analyze' and the resource 'D&D 5e party composition', and lists specific aspects analyzed (saving throw coverage, role balance, skill gaps, darkvision/language spread). This distinguishes it from sibling tools like analyze_loadout or browse_classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing a party composition, but does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. Sibling tools like check_resistances or simulate_damage have overlapping contexts, so more guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose basic behavioral traits such as whether the operation is read-only, if authentication is required, or any side effects. The description implies a read-only browse operation but does not state it explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and enumerates capabilities concisely. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and optional parameters, the description covers the main use cases. It could clarify the interaction between parameters (e.g., class_name and multiclass are likely mutually exclusive), but the current level of detail is sufficient for straightforward browsing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds some context (e.g., 'view a specific class's features' for class_name, 'filter features to this level or below' for level) but does not significantly expand on the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool browses D&D 5e SRD classes and lists its capabilities: list all classes, view features by level, calculate multiclass combos. It distinguishes from sibling tools like browse_races and search_spells by focusing specifically on classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines when to use the tool (browsing classes, looking up features, multiclass calculations). It does not explicitly mention when not to use it, but the sibling tool names provide context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It mentions key internal actions (tracking slots, flagging concentration, etc.) but omits whether the tool is read-only, requires authentication, or has side effects. It suggests a safe planning utility but lacks explicit statements on mutability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. Every clause adds meaningful capability (available spells, slot tracking, concentration flags, ritual highlights, cost sums), with no redundant or extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required), no output schema, and no annotations, the description covers core functionality well. It explains what happens when optional parameters are provided. However, it could clarify the return format or confirm it is read-only, but overall it is sufficiently complete for a planning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, establishing a baseline of 3. The description adds functional context for the optional parameters (prepared_spells and remaining_slots trigger analysis) but does not elaborate on parameter formats or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'plan' and clearly identifies the resource 'spells for a D&D 5e character'. It lists concrete actions (shows spells, tracks slots, flags concentration, highlights rituals, sums costs), making it distinct from sibling tools like search_spells or browse_classes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies appropriate use for character spell planning, but does not explicitly state when to use this tool over alternatives (e.g., search_spells for general lookup, analyze_loadout for broader character analysis). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It states the tool searches and filters, but does not disclose pagination, return format, or whether it's read-only. The input schema hints at pagination via limit/offset parameters, but the description lacks explicit behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and filter options. It is front-loaded and to the point, though it could be slightly more structured to separate the action from filters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters and no output schema, the description is minimal. It covers the search action and some filters but omits details about output behavior, pagination, and typical use cases. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description lists filter categories but adds no new semantic value beyond what is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches D&D 5e SRD equipment, weapons, armor, and magic items, and lists specific filters. This distinguishes it from sibling tools like search_monsters and search_spells, which have different domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (for equipment-related searches) and the filtering options guide usage. It does not explicitly exclude other contexts, but the sibling tools cover other domains, making the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses a read-only search behavior, but lacks details on return format, pagination, or any constraints. Adequate for a simple search but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the main verb and resource, with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter search tool with no output schema, the description sufficiently covers purpose and parameter usage. It lacks details on return values but that is acceptable given the simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are fully described in the schema. The tool description adds marginal value by restating the parameter purposes (specific conditions vs general search) but does not go beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches D&D 5e SRD rules and conditions, distinguishing it from sibling tools like search_spells or search_monsters by specifying the exact resource (rules and conditions) and action (search/look up).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rules and conditions but does not explicitly state when to use this tool over others, nor does it provide exclusions or alternatives. Usage guidance is inferred from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool calculates and suggests, implying read-only behavior, but does not explicitly confirm no side effects, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. Front-loaded with the core action 'Build balanced D&D 5e encounters' followed by a concise summary of functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description provides only high-level output (XP budgets, monster suggestions). Lacks detail on return format, structure, or exact data provided, which is important for a tool that suggests concrete combinations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description reinforces the role of party_size, party_level, and difficulty, but adds minimal new meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds balanced D&D 5e encounters, calculates XP budgets, and suggests monster combinations. It distinguishes from sibling tools like search_monsters or compare_monitors by focusing on encounter creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when building an encounter with party size and level) and what the tool does, but does not explicitly mention when not to use or suggest alternatives. Sibling tool names provide implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it suggests compositions with synergies, roles, and tactical notes, but lacks details on return format, limitations, or side effects. Basic behavioral info is present but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second adds differentiating details. No fluff or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description covers core purpose but lacks details about output format, when to prefer over 'build_encounter', or how results are structured. Adequate but with noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented. The description adds the concept of 'tactical interest' but does not provide new meaning for any parameter beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it suggests encounter compositions, emphasizes 'tactically interesting' and 'goes beyond XP math', and mentions monster synergies, role combinations, and tactical notes. This distinguishes it from sibling tools like 'build_encounter' which likely constructs a specific encounter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for creative encounter ideas beyond basic math, but does not explicitly state when not to use or provide alternatives. It is clear enough for an agent to infer appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior: it returns full stat blocks. However, it omits that it queries the SRD only, no side effects, and no authentication or rate limit info. Acceptable for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with purpose and scope. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description correctly states return values ('full stat blocks'). It lacks mention of pagination (limit/offset) but is complete enough for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). The tool description summarizes filterable attributes but adds no new semantic detail. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches D&D 5e SRD monsters by specific attributes (name, CR, type, size, alignment) and returns full stat blocks. It distinguishes itself from sibling search tools (e.g., search_equipment, search_spells) by focusing on monsters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for monster lookup but does not explicitly state when to use this tool versus alternatives like compare_monsters or build_encounter. However, the sibling context makes the intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool can list all races or provide details on a specific race, including traits, ability bonuses, and subraces. It does not explicitly state it's read-only, but this is inferred. A score of 4 reflects good but not exhaustive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extraneous information. It is front-loaded with the tool's purpose and efficiently covers both modes of operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, no annotations), the description covers the core functionality adequately. It could mention that the tool is read-only, but overall it provides sufficient context for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds meaning beyond the schema by explaining that omitting the parameter lists all races while providing it yields specific details. This clarifies the dual behavior based on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool browses D&D 5e SRD races, with the ability to list all or view a specific race's details. It uses a specific verb ('browse') and resource ('races'), and distinguishes itself from sibling tools like 'browse_classes' by explicitly mentioning races.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'browse_classes' or when not to use it. The implied usage is clear from the description, but there are no exclusionary statements or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries burden. It discloses that the tool shows specific monster attributes, implying read-only behavior with no side effects. However, it lacks details on authentication, rate limits, or performance implications. Still, it is reasonably transparent for a read-only comparison tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively convey the purpose and output. Front-loaded with the action (compare) and resource (monsters), then lists displayed fields. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing output attributes. It covers the key comparison aspects for a monster tool. However, it omits potential return format, ordering, or error handling. Still, sufficient for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a parameter description. The description adds value by explaining the tool's output (AC, HP, etc.) beyond the schema, enhancing understanding of what the parameter drives. However, it does not provide additional constraints or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares 2-3 D&D 5e monsters side by side, listing specific attributes shown (AC, HP, etc.). It distinguishes itself from siblings like search_monsters (which likely finds monsters) by focusing on comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a side-by-side comparison is needed, but it does not explicitly state when to avoid this tool versus alternatives (e.g., search_monsters for single monster details or build_encounter for encounter building). No exclusions or when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool 'rolls on or browses' tables, which suggests read-only behavior. It explains that omitting the roll parameter shows the full table, and providing a roll returns a single result. No mention of error handling or side effects, but the behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no fluff, and front-loaded with the core purpose. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should describe return values. It says 'shows the full table' or shows a result, but it does not specify format (e.g., list of items, plain text). Error handling for invalid table names is not mentioned. Adequate but incomplete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds value by providing examples in the table_name description and explaining that omitting roll shows the full table. The 'list' usage for table_name is a meaningful addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rolls or browses D&D 5e SRD random tables, listing examples like madness and poisons. It distinguishes from sibling tools (e.g., search_monsters, build_character) by focusing on random tables and provides instructions for listing available tables using 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use 'list' to see all tables, or provide a table name with optional roll. It implies usage for browsing/rolling SRD tables but does not explicitly state when not to use it or name alternatives. Sibling tools cover different domains, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dnd-oracle MCP server](https://glama.ai/mcp/servers/gregario/dnd-oracle/badges/card.svg)](https://glama.ai/mcp/servers/gregario/dnd-oracle)

Score Badge

Copy to your README.md:

[![dnd-oracle MCP server](https://glama.ai/mcp/servers/gregario/dnd-oracle/badges/score.svg)](https://glama.ai/mcp/servers/gregario/dnd-oracle)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gregario/dnd-oracle'

If you have feedback or need assistance with the MCP directory API, please join our Discord server