The dnd-oracle server is a D&D 5e SRD-powered tool covering 1,207+ entities (monsters, spells, equipment, classes, races, and more) with no internet required.
Reference & Search
Monsters — Full-text search with filters for CR, type, size, and alignment; returns full stat blocks
Spells — Filter by level, school, class, concentration, ritual, damage/save type, and components
Equipment & Magic Items — Find weapons, armor, gear, and magic items by category, cost, weight, properties, or rarity
Classes & Races — Browse class features at any level (including multiclass combinations), race traits, ability bonuses, and subraces
Rules & Conditions — Full-text search of SRD rules and condition lookups
Encounter & Adventure Planning
Build Encounter — Calculate XP budgets by difficulty and get monster combination suggestions for a given party
Plan Adventuring Day — Daily XP budget, encounter sequencing, resource pacing, and rest placement
Travel Calculator — Overland travel time with pace, terrain, mounts, and forced march rules
Character & Party Tools
Build Character — Generate a full character sheet from race, class, level, and ability scores
Analyze Party — Audit saving throw coverage, role balance, darkvision, and languages
Plan Spells — Available spells for a class/level with slot tracking, concentration flags, ritual highlights, and component costs
Rest Calculator — Determine what recovers on short vs. long rest for any class and level
Analysis & Utilities
Compare Monsters — Side-by-side stat comparison of 2–3 monsters
Check Resistances — Consolidated resistance/immunity matrix for monster groups with party damage gap warnings
Analyze Loadout — Calculate total weight, cost, AC, and encumbrance from an equipment list
Simulate Damage — Average DPR with hit probability, crit math, AC sensitivity, and turns-to-kill
Magic Item Attunement — Slot analysis with over-limit warnings and restriction checks
Roll Table — Roll on SRD random tables (madness, poisons, diseases, personality traits, etc.)
D&D 5e SRD MCP server — monster search, spell lookup, encounter building, and character tools powered by ground-truth SRD data.
Search, browse, and analyze D&D 5e System Reference Document content — no internet required, no hallucination risk. All 20 tools operate on ground-truth SRD data bundled as a SQLite database.
1,207 entities: 334 monsters, 319 spells, 237 equipment items, 239 magic items, 12 classes, 9 races, 15 conditions, 33 rule sections, 9 rollable tables.
Related MCP server: Warhammer Oracle
Tool | Description |
| Full-text search with CR, type, size, alignment filters. Returns full stat blocks. |
| Search by level, school, class, concentration, ritual, damage type, save type. |
| Search weapons, armor, gear, and magic items. Filter by properties, rarity. |
| View class features at any level. Multiclass feature combination calculator. |
| View race traits, ability bonuses, subraces. |
| Search rules text and condition references. |
Tool | Description |
| Calculate XP budgets by difficulty. Suggests monster combinations within budget. |
| Tactically interesting encounters with monster role inference and synergy notes. |
| Available spells for class/level. Slot tracking, concentration flags, ritual highlights, component costs. |
| Side-by-side stat comparison of 2-3 monsters. |
| Consolidated resistance/immunity matrix for a group of monsters. Party damage gap warnings. |
| Total weight, cost, AC breakdown, encumbrance status from equipment list. |
| Attunement slot analysis with over-limit warnings and restriction checks. |
| Full character sheet from race + class + level + ability scores. HP, saves, DC, features. |
| Party composition audit: saving throw coverage, role balance, darkvision, languages. |
| Average DPR calculator with hit probability, crit math, AC sensitivity, turns-to-kill. |
| What recovers on short vs. long rest for any class at any level. |
| Overland travel time with pace, terrain, mounts, and forced march rules. |
| Daily XP budget, encounter sequencing, resource pacing, rest placement. |
| Roll on SRD random tables: madness, poisons, diseases, Acolyte personality traits. |
Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"dnd-oracle": {
"command": "npx",
"args": ["-y", "dnd-oracle"]
}
}
}claude mcp add dnd-oracle -- npx -y dnd-oracleThis product includes material from the System Reference Document 5.1, Copyright 2016, Wizards of the Coast, Inc. Licensed under CC-BY-4.0.
Data sourced from 5e-bits/5e-database.
MIT
Analyze a D&D 5e equipment loadout. Calculates total weight, total cost, AC from armor/shield, and encumbrance status based on Strength score.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | List of equipment item names to analyze | |
| strength_score | No | Character Strength score for encumbrance calculation |
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.
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.
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.
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.
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.
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.
Analyze a D&D 5e party composition. Identifies saving throw coverage, role balance, skill gaps, and darkvision/language spread.
| Name | Required | Description | Default |
|---|---|---|---|
| members | Yes | Party members |
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.
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.
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.
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.
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.
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.
Browse D&D 5e SRD classes. List all classes, view a specific class's features at any level, or calculate multiclass feature combinations.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | No | Name of a specific class to look up | |
| level | No | Filter features to this level or below (1-20) | |
| multiclass | No | Array of class/level combos to calculate multiclass features and spell slots |
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.
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.
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.
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.
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.
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.
Browse D&D 5e SRD races. List all races or view a specific race's traits, ability bonuses, and subraces.
| Name | Required | Description | Default |
|---|---|---|---|
| race_name | No | Name of a specific race to look up |
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.
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.
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.
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.
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.
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.
Build a D&D 5e character summary. Given race, class, level, and ability scores, computes HP, proficiency bonus, saving throws, attack bonuses, spell save DC, and lists features gained.
| Name | Required | Description | Default |
|---|---|---|---|
| race_name | Yes | Race name (e.g. "Elf", "Human") | |
| class_name | Yes | Class name (e.g. "Fighter", "Wizard") | |
| level | Yes | Character level | |
| ability_scores | Yes | Ability scores in order: STR, DEX, CON, INT, WIS, CHA (before racial bonuses) |
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.
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.
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.
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.
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.
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.
Build balanced D&D 5e encounters. Given party size and level, calculates XP budgets for each difficulty and suggests monster combinations.
| Name | Required | Description | Default |
|---|---|---|---|
| party_size | Yes | Number of party members (1-10) | |
| party_level | Yes | Average party level (1-20) | |
| difficulty | No | Target difficulty. If omitted, shows budgets and suggestions for all difficulties. | |
| monster_cr_min | No | Minimum monster CR to consider (numeric, e.g. 0.25 for 1/4) | |
| monster_cr_max | No | Maximum monster CR to consider (numeric) |
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.
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.
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.
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.
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.
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.
Check resistances, immunities, and vulnerabilities for a group of monsters. Produces a consolidated defense matrix and warns about party damage type coverage gaps.
| Name | Required | Description | Default |
|---|---|---|---|
| monster_names | Yes | Names of monsters to check | |
| party_damage_types | No | Damage types your party commonly deals (e.g. ["fire", "slashing", "radiant"]). If provided, warns about gaps. |
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.
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.
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.
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.
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.
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.
Compare 2-3 D&D 5e monsters side by side. Shows AC, HP, ability scores, speeds, resistances, immunities, actions, and special abilities.
| Name | Required | Description | Default |
|---|---|---|---|
| monster_names | Yes | Names of 2-3 monsters to compare |
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.
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.
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.
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.
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.
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.
Analyze attunement requirements for a set of magic items. Reports which items require attunement, any class/alignment restrictions, and warns if the total exceeds the 3-slot limit.
| Name | Required | Description | Default |
|---|---|---|---|
| item_names | Yes | Names of magic items to check | |
| current_attunement | No | Number of attunement slots already in use (0-3) |
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.
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.
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.
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.
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.
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.
Plan a full D&D 5e adventuring day. Calculates the daily XP budget, suggests encounter difficulty distribution, and recommends short rest placement.
| Name | Required | Description | Default |
|---|---|---|---|
| party_size | Yes | Number of party members | |
| party_level | Yes | Average party level | |
| num_encounters | No | Planned number of encounters | |
| difficulty_mix | No | Specific difficulty for each encounter (length must match num_encounters). If omitted, defaults to a balanced mix. |
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.
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.
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.
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.
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.
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.
Plan spells for a D&D 5e character. Shows available spells for a class at a given level, tracks spell slots, flags concentration conflicts, highlights rituals, and sums material component costs.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | Spellcasting class name (e.g. "Wizard", "Cleric") | |
| level | Yes | Character level (1-20) | |
| prepared_spells | No | List of spell names you plan to prepare. If provided, analyzes conflicts and costs. | |
| remaining_slots | No | Remaining spell slots as an object mapping spell level (string) to count, e.g. {"1": 3, "2": 1} |
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.
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.
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.
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.
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.
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.
Show what recovers on a short rest vs. long rest for a D&D 5e character. Lists all class-specific resources and their recovery cadence.
| Name | Required | Description | Default |
|---|---|---|---|
| class_name | Yes | Class name (e.g. "Fighter", "Wizard") | |
| level | Yes | Character level |
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.
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.
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.
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.
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.
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.
Roll on or browse D&D 5e SRD random tables (madness, poisons, diseases, personality traits). Use table_name "list" to see all available tables, or provide a specific table name with an optional roll result.
| Name | Required | Description | Default |
|---|---|---|---|
| table_name | Yes | Name of the table (e.g. "Short-Term Madness", "Poisons") or "list" to see all tables | |
| roll | No | A specific die roll result. If omitted, shows the full table. |
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.
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.
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.
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.
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.
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.
Search D&D 5e SRD equipment, weapons, armor, and magic items. Filter by category, cost, weight, weapon properties, armor type, or rarity.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term for item name or description | |
| category | No | Equipment category (e.g. "Weapon", "Armor", "Adventuring Gear", "Tools") | |
| cost_min | No | Minimum cost in gold pieces | |
| cost_max | No | Maximum cost in gold pieces | |
| weight_max | No | Maximum weight in pounds | |
| weapon_property | No | Weapon property (e.g. "finesse", "heavy", "two-handed", "versatile") | |
| armor_category | No | Armor category (e.g. "Light", "Medium", "Heavy", "Shield") | |
| rarity | No | Magic item rarity (e.g. "common", "uncommon", "rare", "very rare", "legendary") | |
| limit | No | Results per page (max 50) | |
| offset | No | Offset for pagination |
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.
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.
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.
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.
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.
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.
Search D&D 5e SRD monsters by name, CR, type, size, or alignment. Returns full stat blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term for monster name or description | |
| cr | No | Exact challenge rating (e.g. "1/4", "5") | |
| cr_min | No | Minimum challenge rating (numeric, e.g. 0.25 for 1/4) | |
| cr_max | No | Maximum challenge rating (numeric) | |
| type | No | Monster type (e.g. "beast", "undead", "dragon") | |
| size | No | Size category (Tiny, Small, Medium, Large, Huge, Gargantuan) | |
| alignment | No | Alignment (e.g. "chaotic evil", "neutral") | |
| limit | No | Results per page (max 50) | |
| offset | No | Offset for pagination |
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.
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.
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.
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.
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.
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.
Search D&D 5e SRD rules and conditions. Look up specific conditions or search rules text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Full-text search query for rules | |
| condition_name | No | Name of a specific condition to look up |
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.
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.
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.
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.
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.
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.
Search D&D 5e SRD spells by name, level, school, class, concentration, ritual, components, damage type, or save type.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search term for spell name or description | |
| level | No | Spell level (0 for cantrips, 1-9 for leveled spells) | |
| school | No | School of magic (e.g. "evocation", "necromancy") | |
| class_name | No | Spellcasting class (e.g. "Wizard", "Cleric") | |
| concentration | No | Filter by concentration requirement | |
| ritual | No | Filter by ritual casting | |
| has_material | No | Filter by material component requirement | |
| damage_type | No | Damage type (e.g. "fire", "necrotic", "radiant") | |
| save_type | No | Saving throw type (e.g. "DEX", "WIS", "CON") | |
| limit | No | Results per page (max 50) | |
| offset | No | Offset for pagination |
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.
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.
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.
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.
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.
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.
Calculate average damage per round (DPR) for an attack routine. Computes hit probability, critical hit chance, average damage, and turns to kill.
| Name | Required | Description | Default |
|---|---|---|---|
| attack_bonus | Yes | Attack roll modifier (e.g. +7) | |
| damage_dice | Yes | Damage dice notation (e.g. "2d6+5", "1d8+3") | |
| num_attacks | No | Number of attacks per round | |
| target_ac | Yes | Target Armor Class | |
| crit_range | No | Minimum roll for critical hit (default 20) | |
| target_hp | No | Target hit points (for turns-to-kill calculation) | |
| advantage | No | Whether attacks have advantage | |
| disadvantage | No | Whether attacks have disadvantage |
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.
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.
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.
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.
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.
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.
Suggest tactically interesting D&D 5e encounter compositions. Goes beyond XP math to recommend monster synergies, role combinations, and tactical notes.
| Name | Required | Description | Default |
|---|---|---|---|
| party_size | Yes | Number of party members | |
| party_level | Yes | Average party level | |
| difficulty | No | Target difficulty | medium |
| theme | No | Optional theme filter (e.g. "undead", "forest", "dungeon", "ambush", "horror") | |
| num_suggestions | No | Number of encounter suggestions |
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.
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.
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.
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.
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.
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.
Calculate D&D 5e overland travel time, pace effects, and forced march consequences. Uses SRD travel rules for pace, terrain, and exhaustion.
| Name | Required | Description | Default |
|---|---|---|---|
| distance_miles | Yes | Distance to travel in miles | |
| pace | No | Travel pace | normal |
| terrain | No | Terrain type (difficult terrain halves speed) | normal |
| mounted | No | Whether the party is mounted (gallop available for 1 hour) | |
| hours_per_day | No | Hours of travel per day (forced march beyond 8) |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
D&D 5e MCP — wraps the D&D 5th Edition API (free, no auth)
Official remote MCP server for Archivist AI TTRPG campaign memory: characters, sessions, and more.
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
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
