What can you do with this server?

The D&D MCP Server is a comprehensive tool for managing AI-assisted Dungeons & Dragons campaigns, offering DMs a complete suite of campaign management tools: * Campaign Management: Create, track, and switch between campaigns with metadata (name, description, DM, setting) * Character Management: Create and update detailed D&D 5e character sheets including ability scores, combat stats, inventory, and spellcasting * NPC Management: Create and track non-player characters with descriptions, relationships, locations, and attitudes * Location/World Building: Create detailed locations with populations, governments, and notable features * Quest Management: Track quests with objectives, status, rewards, and connections to NPCs/locations * Combat Management: Run encounters with initiative tracking, turn management, and condition tracking * Session Management: Log attendance, XP awards, loot distribution, and in-world time * Adventure Log: Record and search historical campaign events by category * Game State Tracking: Monitor current party status, location, active quests, and combat status * Utility Tools: Roll dice with advantage/disadvantage and calculate XP distribution

Which integrations are available for this server?

Provides comprehensive tools for managing D&D 5e campaigns, including character sheets, NPCs, combat encounters, quests, locations, and game mechanics like dice rolling

How do I use D&D MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@D&D MCP Server add a new NPC named Elara the Enchantress to my campaign" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

D&D MCP Server

by study-flamingo

Overview Schema Related Servers Score Discussions

Python

Local

Gamemaster MCP 🐉

A comprehensive Model Context Protocol MCP server for managing AI-assisted Dungeons & Dragons campaigns, built with FastMCP 2.9.0+

Gamemaster MCP 🐉 aims to be the ultimate AI-assisted Dungeon Master for DnD 5e, providing:

For Groups: A comprehensive toolkit to help the user run campaigns more effectively
For Solo Players: A complete virtual DnD experience that facilitates immersive solo play
For Worldbuilders: Powerful tools to assist in creating rich, interconnected game worlds

Built on FastMCP, the server provides structured data models and intelligent tools to manage all aspects of a D&D campaign while enabling natural language interaction through MCP clients.

🚧 Under construction 🚧

✨ Features

🌍 Campaign Management

The foundation of your D&D world. Each campaign contains:

Core Metadata: Name, description, setting, DM name
Characters: All player characters and their sheets
NPCs: Every non-player character in your world
Locations: Cities, dungeons, and points of interest
Quests: Active and completed storylines
Game State: Current session, party location, world conditions

All data is automatically saved and can be shared between sessions.

Create and manage multiple campaigns
Switch between campaigns seamlessly
Track campaign metadata (name, description, DM, setting)

📑 Character Management

Complete D&D 5e character sheets with:

Core Attributes: Ability scores with auto-calculated modifiers
Combat Stats: HP, AC, saving throws, resistances
Inventory: Equipment with weight and value tracking
Spellcasting: Prepared spells, slots, and DCs
Progression: Level ups with automatic feature unlocks

Characters evolve as you play - taking damage, gaining items, and leveling up.

Complete character sheets with D&D 5e stats
Ability scores with automatic modifier calculation
Hit points, armor class, and combat stats
Inventory and equipment management
Spellcasting support

🧝 NPC Management

Bring your world to life with rich NPCs featuring:

Descriptions: Appearance, personality, voice notes
Relationships: Connections to other characters/factions
Locations: Where they live and frequent
Secrets: Hidden motivations and knowledge
Stats: Quick reference for combat if needed

NPCs can be linked to quests and locations for easy reference.

Create and track non-player characters
Manage relationships and locations
Store descriptions and notes

🗺️ Location/World Building

Create immersive settings with:

Detailed Descriptions: Sensory details and maps
Notable Features: Landmarks, secrets, hazards
Connections: Linked areas for travel routes
Inhabitants: NPCs and monsters present
Lore: Local history and legends

Locations update as the party explores - adding discovered areas and changing conditions.

Create detailed locations (cities, dungeons, etc.)
Track populations, governments, and notable features
Connect locations and manage geography

💎 Quest Management

Track story arcs and missions with:

Objectives: Clear steps to completion
Status Tracking: Active/Completed/Failed
Givers & Rewards: Connected NPCs and prizes
Time Sensitivity: Optional deadlines
Branching Paths: Alternate resolutions

Quest progress automatically updates the Game State and Adventure Log.

Create quests with objectives and rewards
Track quest status and completion
Link quests to NPCs and locations

⚔️ Combat Management

Track and run dynamic combat encounters with:

Initiative Order: Automatic sorting with manual override
Turn Tracking: Current actor highlight and turn reminders
Condition Management: Status effects with duration tracking
Damage/Healing: Apply with automatic HP calculation
Enemy Stats: Quick reference for monsters/NPCs

Combat data flows to:

Character sheets (HP, conditions)
Game State (current encounter)
Adventure Log (combat events)
Initiative tracking
Turn-based combat flow
Combat encounter planning

⏰ Session Management

Organize your game sessions with:

Session Notes: Key events and decisions
Attendance Tracking: Which players were present
XP Awards: Track character progression
Loot Distribution: Treasure found and claimed
Game Date: Track in-world time passage

Session data updates:

Character sheets (XP, items)
Game State (current session #)
Adventure Log (session summary)
Session notes and summaries
Experience and treasure tracking
Character attendance

🏕️ Adventure Log

Your campaign's living history:

Event Types: Combat, Roleplay, Exploration, etc.
Timeline View: Chronological story progression
Searchable: Find key moments quickly
Tags & Importance: Highlight major plot points
Session Linking: Connect events to game sessions

The log connects to:

Quests (progress updates)
Locations (where events occurred)
NPCs (who was involved)
Comprehensive event logging
Categorized by event type (combat, roleplay, exploration, etc.)
Searchable and filterable
Importance ratings

🎮 Game State Tracking

The current snapshot of your world:

Party Status: Location, resources, conditions
Active Quests: Current objectives and progress
World Conditions: Weather, political climate
Time Tracking: In-game date and time
Combat Status: Current encounter details

The Game State connects all other models:

Updates from character actions
Drives world simulation
Informs AI DM decisions
Current location and session
Party level and funds
Combat status
In-game date tracking

🎲 Utility Tools

Dice rolling with advantage/disadvantage
Experience point calculations
D&D 5e mechanics support

Related MCP server: Writer MCP

💾 Installation

Prerequisites

Python 3.12+
uv (available in your system's PATH)

User Installation

Clone the repository:

git clone https://github.com/study-flamingo/gamemaster-mcp.git
cd gamemaster-mcp

Create a virtual environment and install dependencies:
```
uv venv
uv pip install .
```

🏁 Running the Server

From the Command Line

To run the server directly, first activate the virtual environment:

# On macOS/Linux
source .venv/bin/activate

# On Windows
.venv\Scripts\activate

Then, run the executable:

gamemaster-mcp

Alternatively, use uv to run the script without activating the environment:

uv run gamemaster-mcp

With an MCP Client (e.g., Claude Desktop)

Configure your MCP client to use uv to run the server. You only need to provide the path to your project folder as the working directory.

{
  "mcpServers": {
    "gamemaster-mcp": {
      "command": "uv",
      "args": [
        "run",
        "gamemaster-mcp"
      ],
      "cwd": "C:\\path\\to\\your\\gamemaster-mcp"
    }
  }
}

Note: Replace C:\\path\\to\\your\\gamemaster-mcp with the absolute path to the project directory.

🎛️ System Prompt Recommendation

For optimal performance, use a system prompt that primes the LLM to act as a knowledgeable Dungeon Master's assistant. This prompt should guide the model to understand the context of D&D campaign management and leverage the provided tools effectively.

📜 Example System Prompt

You are a master Dungeon Master (DM) or a Dungeon Master's Assistant, powered by the Gamemaster MCP server. Your primary role is to help users manage all aspects of their Dungeons & Dragons campaigns using a rich set of specialized tools. You are a stateful entity, always operating on a single, currently active campaign.

**Core Principles:**

1.  **Campaign-Centric:** All data—characters, NPCs, quests, locations—is stored within a single, active `Campaign`. Always be aware of the current campaign context. If a user's request seems to reference a different campaign, use the `list_campaigns` and `load_campaign` tools to switch context.
2.  **Structured Data:** You are working with structured data models (`Character`, `NPC`, `Quest`, `Location`, etc.). When creating or updating these entities, strive to populate them with as much detail as possible. If a user is vague, ask for specifics (e.g., "What is the character's class and race? What are their ability scores?").
3.  **Proactive Assistance:** Don't just execute single commands. Fulfill complex user requests by chaining tools together. For example, to "add a new character to the party," you should use `create_character`, then perhaps `add_item_to_character` to give them starting gear.
4.  **Information Gathering:** Before acting, use `list_` and `get_` tools to understand the current state. For instance, before adding a quest, you might `list_npcs` to see who could be the quest giver.
5.  **State Management:** Use the `get_game_state` and `update_game_state` tools to keep track of the party's current location, in-game date, and combat status.
6.  **Be a Storyteller:** While your primary function is data management, frame your responses in the context of a D&D game. You are not just a database; you are the keeper of the campaign's world.

**Interactive Session Zero:**

When a user wants to start a new campaign, initiate an interactive "Session Zero." Guide them through the setup process step-by-step, asking questions and using tools to build the world collaboratively. Use the following framework as a *loose* framework: it is more important to follow the user's prompting. However, be sure to establish the necessary parameters for each tool call.

1.  **Establish the Campaign:**
    *   **You:** "Welcome to the world of adventure! What shall we name our new campaign?" (Wait for user input)
    *   **You:** "Excellent! And what is the central theme or description of 'Campaign Name'?" (Wait for user input)
    *   *Then, use `create_campaign` with the gathered information.*

2.  **Build the Party:**
    *   **You:** "Now, let's assemble our heroes. How many players will be in the party?"
    *   *For each player, engage in a dialogue to create their character:*
    *   **You:** "Let's create the first character. What is their name, race, and class?"
    *   **You:** "Great. What are their ability scores (Strength, Dexterity, etc.)?"
    *   *Use `create_character` after gathering the core details for each hero.*

3.  **Flesh out the World:**
    *   **You:** "Where does our story begin? Describe the starting town or location."
    *   *Use `create_location`.*
    *   **You:** "Who is the first person the party meets? Let's create an NPC."
    *   *Use `create_npc`.*

4.  **Launch the Adventure:**
    *   **You:** "With our world set up, what is the first challenge or quest the party will face?"
    *   *Use `create_quest`.*
    *   **You:** "Session Zero is complete! I've logged the start of your first session. Are you ready to begin?"
    *   *Use `add_session_note`.*

Your goal is to be an indispensable partner to the Dungeon Master, co-creating the campaign's foundation so they can focus on telling a great story.

**In-Play Campaign Guidance:**

Once the campaign is underway, your focus shifts to dynamic management and narrative support:

1.  **Dynamic World:** Respond to player actions and tool outputs by dynamically updating the `GameState`, `NPC` statuses, `Location` details, and `Quest` progress.
2.  **Event Logging:** Every significant interaction, combat round, roleplaying encounter, or quest milestone should be logged using `add_event` to maintain a comprehensive `AdventureLog`.
3.  **Proactive DM Support:** Anticipate the DM's needs. If a character takes damage, suggest `update_character_hp`. If they enter a new area, offer `get_location` details.
4.  **Narrative Cohesion:** Maintain narrative consistency. Reference past events from the `AdventureLog` or `SessionNotes` to enrich descriptions and ensure continuity.
5.  **Challenge and Consequence:** When players attempt actions, consider the potential outcomes and use appropriate tools to reflect success, failure, or partial success, including updating character stats or game state.
6.  **Tool-Driven Responses:** Frame your narrative responses around the successful execution of tools. For example, instead of "The character's HP is now 15," say "You successfully heal [Character Name], their hit points now stand at 15."

Available Tools (25+ FastMCP Tools)

Campaign Management

create_campaign - Create a new campaign
get_campaign_info - Get current campaign information
list_campaigns - List all available campaigns
load_campaign - Switch to a different campaign

Character Management

create_character - Create a new player character
get_character - Get character sheet details
update_character - Update a character's properties (name, stats, HP, etc.).
bulk_update_characters - Update multiple characters at once (e.g., apply damage to all).
add_item_to_character - Add items to inventory
list_characters - List all characters

NPC Management

create_npc - Create a new NPC
get_npc - Get NPC details
list_npcs - List all NPCs

Location Management

create_location - Create a new location
get_location - Get location details
list_locations - List all locations

Quest Management

create_quest - Create a new quest
update_quest - Update quest status or objectives
list_quests - List quests (optionally filtered by status)

Game State Management

update_game_state - Update current game state
get_game_state - Get current game state

Combat Management

start_combat - Initialize combat with initiative order
end_combat - End combat encounter
next_turn - Advance to next participant's turn

Session Management

add_session_note - Add session notes and summary
get_sessions - Get all session notes

Adventure Log

add_event - Add event to adventure log
get_events - Get events (with filtering and search)

Utility Tools

roll_dice - Roll dice with D&D notation (e.g., "1d20", "3d6+2")
calculate_experience - Calculate XP distribution for encounters

💽 Data Structure

The Gamemaster MCP server organizes all campaign data around a central Campaign model, which acts as the primary container for the entire game world. This design ensures a cohesive and interconnected data structure, allowing for easy management and interaction with various game elements.

The system is built around a hierarchical data structure with the Campaign model at its core. All other models relate to the active campaign, as shown below:

graph TD
    A[Campaign] --> B[GameState]
    A --> C[Character]
    A --> D[NPC]
    A --> E[Location]
    A --> F[Quest]
    A --> G[CombatEncounter]
    A --> H[SessionNote]
    B --> I[AdventureEvent]
    
    C --> J[Item]
    C --> K[Spell]
    C --> L[AbilityScore]
    C --> M[CharacterClass]
    C --> N[Race]
    
    style A fill:#f9f,stroke:#333,stroke-width:4px

Here's how the core data models in src/gamemaster_mcp/models.py interact:

Campaign: The foundational model. It encapsulates all campaign-specific data, including:
- characters: A dictionary of Character models, representing player characters. Each Character is a complex model composed of CharacterClass, Race, AbilityScore (for core stats), Item (for inventory and equipment), and Spell (for known spells).
- npcs: A dictionary of NPC models, representing non-player characters. NPCs can be linked to Location models.
- locations: A dictionary of Location models, defining places within the campaign world. Locations can list associated NPCs and connections to other locations.
- quests: A dictionary of Quest models, tracking ongoing and completed missions. Quests can reference NPCs as givers.
- encounters: A dictionary of CombatEncounter models, detailing planned or active combat scenarios. Encounters can be tied to specific locations.
- sessions: A list of SessionNote models, providing summaries and details for each game session played within the campaign.
- game_state: A single GameState model, which captures the dynamic, real-time conditions of the campaign, such as the current location, active quests, and party funds. This model is crucial for understanding the immediate context of the game.
GameState: While part of the Campaign, GameState plays a pivotal role in reflecting the current state of the world. It influences and is influenced by other models:
- current_location can point to a Location model.
- active_quests references Quest titles.
- Changes in Character status (e.g., hit_points_current) or Quest status (active, completed) directly impact the GameState.
AdventureEvent: This model is used to log significant occurrences throughout the campaign. While not directly nested within Campaign (it's stored globally), AdventureEvent instances often reference elements from the Campaign's data, such as characters_involved and location. This provides a historical log for understanding past events and narrative progression.

🖥️ Development

Development Workflow

If you want to contribute to the project, the setup is slightly different.

Follow steps from the User Installation to clone the repo and set up the virtual environment.
Install in editable mode with development dependencies:
```
uv pip install -e .[dev]
```
This installs the project in a way that your code changes are immediately reflected without needing to reinstall. It also installs tools for testing and linting.

Running Tests

To run the test suite, use the following command:

uv run pytest

📜 License

MIT License

Available Tools

30 tools

add_eventC

Add an event to the adventure log.

ParametersJSON Schema

Name	Required	Description
`event_type`	Yes	Type of event
`title`	Yes	Event title
`description`	Yes	Event description
`session_number`	No	Session number
`characters_involved`	No	Characters involved in the event
`location`	No	Location where event occurred
`importance`	No	Event importance (1-5)
`tags`	No	Tags for categorizing the event

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. 'Add an event' implies a write/mutation operation, but the description doesn't mention permissions required, whether this creates permanent records, what happens on duplicate events, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.

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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point with no unnecessary elaboration.

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?

For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes an 'event' in this context, how events relate to other entities (sessions, characters, etc.), what happens after adding, or what the tool returns. The comprehensive schema helps, but the description should provide more context about the tool's role in the system.

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, providing complete documentation for all 8 parameters including their types, constraints, and purposes. The description adds no parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.

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 action ('Add') and target resource ('event to the adventure log'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'add_session_note' or 'add_item_to_character' that also add content to the system, leaving room for confusion about when to choose this specific tool.

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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'add_session_note' and 'create_quest' that might overlap in functionality, there's no indication of when this tool is appropriate versus those alternatives, nor any prerequisites or constraints mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_item_to_characterC

Add an item to a character's inventory.

ParametersJSON Schema

Name	Required	Description	Default
`character_name_or_id`	Yes	Name or ID of the character to receive the item.
`item_name`	Yes	Item name
`description`	No	Item description
`quantity`	No	Quantity
`item_type`	No	Item type	misc
`weight`	No	Item weight
`value`	No	Item value (e.g., '50 gp')

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states the action ('Add an item') but doesn't describe what happens on success/failure, whether duplicates are allowed, if inventory limits exist, or how the system handles the addition. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.

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, clear sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or verbosity detract from its clarity.

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?

Given this is a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after adding the item (e.g., returns success confirmation, updated character object, or nothing), doesn't mention error conditions, and provides minimal behavioral context. For a 7-parameter tool that modifies game state, more completeness is needed.

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 all 7 parameters thoroughly with descriptions, types, defaults, and constraints. The description adds no additional parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline score is 3 even with no param info in the description.

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 verb ('Add') and resource ('item to a character's inventory'), making the purpose immediately understandable. It distinguishes from siblings like 'update_character' or 'create_character' by focusing specifically on inventory management. However, it doesn't explicitly differentiate from potential inventory-related tools that might exist (though none are listed among siblings).

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., character must exist), whether it's for new items or existing ones, or how it relates to similar operations like 'update_character' which might also modify inventory. No explicit when/when-not statements or alternative tool references are included.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_session_noteC

Add notes for a game session.

ParametersJSON Schema

Name	Required	Description
`session_number`	Yes	Session number
`summary`	Yes	Session summary
`title`	No	Session title
`events`	No	Key events that occurred
`characters_present`	No	Characters present in session
`experience_gained`	No	Experience points gained
`treasure_found`	No	Treasure or items found
`notes`	No	Additional notes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write operation ('Add'), but doesn't disclose permissions needed, whether it creates or updates notes, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse without unnecessary elaboration.

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?

Given the complexity of an 8-parameter mutation tool with no annotations and no output schema, the description is incomplete. It lacks crucial details like behavioral traits, usage context, and return values, leaving significant gaps for an AI agent to operate effectively.

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 fully documents all 8 parameters. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., 'Session summary'), resulting in a baseline score of 3 where the schema does the heavy lifting.

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 action ('Add notes') and the resource ('for a game session'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_sessions' or 'update_game_state', which would require more specificity about what kind of notes or how they're stored.

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. It doesn't mention prerequisites (e.g., needing an existing session), exclusions, or how it relates to siblings like 'update_game_state' or 'get_sessions', leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

bulk_update_charactersC

Update properties for multiple characters at once by a given amount.

ParametersJSON Schema

Name	Required	Description
`names_or_ids`	Yes	List of character names or IDs to update.
`hp_change`	No	Amount to change current HP by (positive or negative).
`temp_hp_change`	No	Amount to change temporary HP by (positive or negative).
`strength_change`	No	Amount to change strength by.
`dexterity_change`	No	Amount to change dexterity by.
`constitution_change`	No	Amount to change constitution by.
`intelligence_change`	No	Amount to change intelligence by.
`wisdom_change`	No	Amount to change wisdom by.
`charisma_change`	No	Amount to change charisma by.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but offers minimal behavioral context. It states this is an update operation (implying mutation) but doesn't disclose whether changes are permanent/reversible, what permissions are required, how errors are handled for invalid characters, or what the response format looks like. For a batch mutation tool with 9 parameters, this is insufficient.

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, efficient sentence that front-loads the core functionality ('Update properties for multiple characters at once') and adds necessary qualification ('by a given amount'). Every word earns its place with zero redundancy or wasted space.

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?

For a batch mutation tool with 9 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens when the tool executes (e.g., partial success handling), what values are returned, or how it differs from the single-character 'update_character' sibling. The agent would have significant gaps in understanding this tool's behavior.

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 all 9 parameters thoroughly. The description adds only the concept of 'by a given amount' which is already covered in parameter descriptions like 'Amount to change current HP by'. No additional parameter semantics are provided beyond what's in the schema.

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 verb ('update'), resource ('multiple characters'), and scope ('properties... at once by a given amount'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling 'update_character' tool, which appears to be a single-character version, so it doesn't reach the highest score.

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 provides no guidance on when to use this tool versus alternatives like 'update_character' for single-character updates or other property-modifying tools. It mentions 'multiple characters at once' which implies a batch operation, but offers no explicit when/when-not criteria or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

calculate_experienceC

Calculate experience points for an encounter.

ParametersJSON Schema

Name	Required	Description
`party_size`	Yes	Number of party members
`party_level`	Yes	Average party level
`encounter_xp`	Yes	Total encounter XP value

TDQS

C2.9/5.0

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 of behavioral disclosure. It states the tool calculates experience points, implying a read-only computation, but doesn't disclose if it modifies game state (e.g., updates character XP), requires specific permissions, has rate limits, or what the output format might be. For a tool with no annotations, this is a significant gap in transparency.

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, efficient sentence: 'Calculate experience points for an encounter.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward calculation tool. Every word earns its place.

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?

Given the tool's complexity (a calculation with three parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the calculation logic, output format, or behavioral implications (e.g., whether it's idempotent or has side effects). For a tool with no structured output documentation, the description should provide more context to be fully helpful.

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, with clear parameter names and descriptions (e.g., 'Number of party members' for party_size). The description adds no additional meaning beyond the schema, such as explaining how these parameters interact in the calculation or providing examples. Given the high schema coverage, a baseline score of 3 is appropriate.

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's purpose: 'Calculate experience points for an encounter.' It specifies the verb ('calculate') and resource ('experience points'), and the context ('for an encounter') distinguishes it from sibling tools like 'roll_dice' or 'update_character'. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a 'calculate_damage' tool), so it's not a perfect 5.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an active encounter), exclusions (e.g., not for non-combat events), or related tools (e.g., 'end_combat' might be a follow-up). This leaves the agent to infer usage from the name and parameters alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_campaignC

Create a new D&D campaign.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Campaign name
`description`	Yes	Brief decription of the campaign, or a tagline
`dm_name`	No	Dungeon Master name
`setting`	No	Campaign setting - a full description of the setting of the campaign in markdown format, or the path to a `.txt` or `.md` file containing the same.

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' implies a write/mutation operation but provides no information about permissions needed, whether this is idempotent, what happens on duplicate names, or what the response contains. Significant behavioral gaps remain unaddressed.

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, clear sentence with zero waste. It's front-loaded with the essential action and resource, making it immediately understandable without unnecessary elaboration.

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?

For a creation/mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address what happens after creation, what permissions are required, how to handle errors, or what the return value contains. The description should provide more context for this write operation.

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 all parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 verb ('Create') and resource ('new D&D campaign'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'load_campaign' or 'get_campaign_info', but the creation action is distinct enough for basic understanding.

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 provides no guidance on when to use this tool versus alternatives like 'load_campaign' or 'list_campaigns'. There's no mention of prerequisites, dependencies, or typical workflow context for campaign creation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_characterC

Create a new player character.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Character name
`character_class`	Yes	Character class
`class_level`	Yes	Class level
`race`	Yes	Character race
`player_name`	No	The name of the player in control of this character
`description`	No	A brief description of the character's appearance and demeanor.
`bio`	No	The character's backstory, personality, and motivations.
`background`	No	Character background
`alignment`	No	Character alignment
`strength`	No	Strength score
`dexterity`	No	Dexterity score
`constitution`	No	Constitution score
`intelligence`	No	Intelligence score
`wisdom`	No	Wisdom score
`charisma`	No	Charisma score

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address important behavioral aspects: whether this requires specific permissions, what happens on success/failure, whether character names must be unique, if there are validation rules beyond schema constraints, or what the response contains. For a mutation tool with 15 parameters and no annotation coverage, this is a significant gap.

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 maximally concise - a single clear sentence with zero wasted words. It's appropriately sized for a tool with a straightforward purpose, though this conciseness comes at the cost of completeness. Every word earns its place by communicating the core function.

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?

Given the complexity (15 parameters, mutation operation) and lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what happens after creation, what validation occurs, whether there are side effects, or how this tool relates to the broader RPG system context. The agent would need to guess about important operational aspects despite the comprehensive parameter 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?

Schema description coverage is 100%, with each parameter well-documented in the schema itself (e.g., 'Character name', 'Character class', 'Strength score'). The description adds no parameter information beyond what's already in the schema. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new player character' clearly states the verb ('Create') and resource ('player character'), but it's quite basic and doesn't differentiate this tool from sibling tools like 'create_campaign', 'create_npc', or 'create_quest' beyond the obvious resource difference. It lacks specificity about what distinguishes character creation from other creation operations in this RPG system.

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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (like needing an existing campaign), no indication of when to use this versus 'update_character' or 'bulk_update_characters', and no reference to related tools like 'get_character' or 'list_characters' for retrieval operations. The agent must infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_locationC

Create a new location.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Location name
`location_type`	Yes	Type of location (city, town, village, dungeon, etc.)
`description`	Yes	Location description
`population`	No	Population (if applicable)
`government`	No	Government type
`notable_features`	No	Notable features
`notes`	No	Additional notes

TDQS

C2.6/5.0

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. 'Create a new location' implies a write/mutation operation, but it doesn't disclose behavioral traits such as permissions needed, whether it's idempotent, what happens on duplicate names, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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 ('Create a new location.') that is front-loaded and wastes no words. It's appropriately sized for a basic tool, though it could be more informative without losing conciseness. Every word earns its place, but it's under-specified rather than concise.

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?

Given the complexity (a mutation tool with 7 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain what a 'location' is in this system, how it fits with other tools (e.g., 'create_campaign'), or what to expect after creation. For a tool that likely integrates into a game management workflow, more context is needed.

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 all 7 parameters with clear descriptions (e.g., 'Location name', 'Type of location'). The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new location' clearly states the verb ('create') and resource ('location'), but it's vague about what a 'location' entails in this context (e.g., a geographic place, a game setting element). It doesn't distinguish from siblings like 'create_campaign' or 'create_quest', which also create resources in what appears to be a game management system.

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. It doesn't mention prerequisites (e.g., needing an existing campaign), exclusions, or how it relates to siblings like 'list_locations' or 'get_location'. The description alone offers no usage context beyond the basic action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_npcC

Create a new NPC.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	NPC name
`description`	No	A brief, public description of the NPC.
`bio`	No	A detailed, private bio for the NPC, including secrets.
`race`	No	NPC race
`occupation`	No	NPC occupation
`location`	No	Current location
`attitude`	No	Attitude towards party
`notes`	No	Additional notes

TDQS

C2.5/5.0

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 of behavioral disclosure. While 'Create a new NPC' implies a write/mutation operation, it doesn't specify permissions required, whether creation is idempotent, what happens on failure, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

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 extremely concise at just three words ('Create a new NPC'), with zero wasted language. It's front-loaded with the core action and resource, making it easy to parse quickly. This efficiency is appropriate given the tool's straightforward purpose.

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?

Given the complexity (8 parameters, mutation operation) and lack of both annotations and output schema, the description is insufficient. It doesn't explain what constitutes an NPC versus other entities, what happens after creation, or any system constraints. For a creation tool in what appears to be a game/campaign management system, more context is needed for proper use.

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 each parameter well-documented in the schema itself (e.g., 'name' as 'NPC name', 'description' as 'A brief, public description', 'bio' as 'A detailed, private bio'). The description adds no parameter information beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new NPC' clearly states the action (create) and resource (NPC), making the basic purpose understandable. However, it doesn't differentiate this tool from similar creation tools like 'create_character' or 'create_location' among the siblings, leaving ambiguity about when to use this specific creation tool versus others.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'create_character' and 'create_location' available, there's no indication whether NPCs are a subset of characters, how they differ, or any prerequisites for creation. This lack of context makes it difficult for an agent to choose correctly among similar tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_questC

Create a new quest.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Quest title
`description`	Yes	Quest description
`giver`	No	Quest giver (NPC name)
`objectives`	No	Quest objectives
`reward`	No	Quest reward
`notes`	No	Additional notes

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but only states the action ('Create a new quest'). It doesn't mention what happens after creation (e.g., where the quest appears, if it's saved to a database), permission requirements, side effects, error conditions, or whether this is a write operation (implied but not explicit). For a creation tool with zero annotation coverage, this is inadequate.

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 extremely concise at just three words. It's front-loaded with the core action and contains zero wasted words or redundant information. While under-specified, it's not verbose.

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?

For a creation tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'quest' is in this system, how it relates to other entities (campaigns, characters), what happens after creation, or what the tool returns. The context signals show significant complexity that the description doesn't address.

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 documented in the schema. The description adds no parameter information beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Create a new quest' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this from sibling tools like 'create_campaign', 'create_character', or 'create_location', nor does it specify what type of quest or in what context. The verb 'create' is clear but the resource 'quest' is too generic given the sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites, context (e.g., must be in a campaign), or comparison to sibling tools like 'update_quest' or 'list_quests'. The description offers zero usage instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

end_combatB

End the current combat encounter.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('End') but does not explain what this entails—e.g., whether it saves state, clears data, requires confirmation, or affects other game elements like experience or items. This leaves significant gaps in understanding the tool's effects and 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 is a single, direct sentence with no wasted words, making it highly efficient and easy to parse. It front-loads the key action and target, providing immediate clarity without any structural fluff or redundancy.

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?

Given the complexity of ending a combat encounter in a game system, the description is insufficient. With no annotations, no output schema, and minimal behavioral detail, it fails to address critical aspects like what data is returned, how the game state changes, or any side effects. This leaves the agent with incomplete information for safe and effective use.

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?

The tool has zero parameters, and the input schema coverage is 100%, so there is no need for parameter details in the description. The description appropriately avoids discussing parameters, focusing solely on the tool's purpose. A baseline of 4 is given as it effectively handles the lack of parameters without unnecessary information.

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 action ('End') and the target ('the current combat encounter'), making the purpose immediately understandable. It distinguishes from siblings like 'start_combat' and 'next_turn' by specifying termination rather than initiation or progression. However, it doesn't explicitly contrast with all possible alternatives, keeping it from a perfect score.

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 provides no guidance on when to use this tool versus alternatives, such as whether it should be used at the conclusion of combat or if other conditions must be met. It lacks any mention of prerequisites, exclusions, or related tools like 'update_game_state' that might affect combat, leaving usage context implied at best.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_campaign_infoC

Get information about the current campaign.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.8/5.0

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 of behavioral disclosure. It implies a read-only operation ('Get information'), but doesn't specify what information is returned, whether it requires authentication, or if there are rate limits. This is inadequate for a tool with zero annotation coverage.

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, efficient sentence with no wasted words. It's appropriately sized for a simple tool, though it could be more front-loaded with additional context if needed.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'information' includes (e.g., campaign details, state, metadata) or how it relates to other tools like 'get_game_state'. For a tool in a complex RPG server, this leaves significant gaps.

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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, earning a baseline score of 4 for this dimension.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as retrieving information about 'the current campaign', which is clear but vague. It specifies the verb 'Get' and resource 'campaign', but doesn't distinguish it from sibling tools like 'list_campaigns' or 'load_campaign' in terms of scope or detail level.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a loaded campaign), exclusions, or comparisons to siblings like 'list_campaigns' (for listing multiple campaigns) or 'load_campaign' (for loading campaign data).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_characterC

Get detailed character information.

ParametersJSON Schema

Name	Required	Description	Default
`name_or_id`	Yes	Character name or ID

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation ('Get'), but doesn't specify whether this requires authentication, what happens with invalid inputs, if there are rate limits, or the format of the returned 'detailed information'. For a tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get detailed character information'), making it easy to parse quickly. Every word earns its place, achieving maximum clarity in minimal space.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed character information' includes, how errors are handled, or any behavioral traits. For a tool that likely returns complex character data, this leaves too much unspecified, relying heavily on the agent's inference from the tool name.

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?

The input schema has 100% description coverage, with the single parameter 'name_or_id' clearly documented. The description doesn't add any parameter-specific details beyond what the schema provides, but with only one parameter and high schema coverage, the baseline is strong. A score of 4 reflects that the description doesn't need to compensate for schema gaps in this case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get detailed character information' clearly states the verb ('Get') and resource ('character information'), but it's vague about what constitutes 'detailed' information and doesn't distinguish this tool from its sibling 'list_characters' or 'update_character'. It provides a basic purpose but lacks specificity about scope or differentiation.

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 offers no guidance on when to use this tool versus alternatives like 'list_characters' (for listing multiple characters) or 'update_character' (for modifying characters). It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_eventsC

Get events from the adventure log.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of events to return
`event_type`	No	Filter by event type
`search`	No	Search events by title/description

TDQS

C2.7/5.0

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. 'Get events' implies a read operation, but it doesn't disclose behavioral traits like whether this requires authentication, returns paginated results, has rate limits, or what format the events come in. The description is too minimal to provide meaningful behavioral context.

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 extremely concise with a single sentence that gets straight to the point. There's no wasted words or unnecessary elaboration, making it easy to parse quickly.

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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'events' are, what fields they contain, how they're ordered, or what the return structure looks like. For a tool with three parameters and no structured output documentation, this leaves significant 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 the schema fully documents all three parameters (limit, event_type, search). The description adds no parameter semantics beyond what's in the schema, but since schema coverage is high, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get events from the adventure log' clearly states the action (get) and resource (events from adventure log), but it's vague about scope and doesn't distinguish from siblings like 'get_sessions' or 'get_campaign_info'. It doesn't specify whether this retrieves all events, recent events, or filtered events.

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. It doesn't mention sibling tools like 'get_sessions' (which might retrieve session-specific events) or 'list_quests' (which might overlap with quest events). There's no context about prerequisites or 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.

get_game_stateC

Get the current game state.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without detailing what the game state includes, whether it's read-only, if it requires specific permissions, or how it behaves in different contexts (e.g., during combat). This leaves significant gaps in understanding the tool's operational traits.

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, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly without unnecessary elaboration.

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?

Given the complexity implied by sibling tools (e.g., game state likely involves multiple entities like characters, locations, and combat), the description is insufficient. With no annotations, no output schema, and minimal detail, it fails to provide enough context for an agent to understand what information is retrieved or how to interpret the result, leaving critical gaps.

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?

The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add semantic value beyond the schema, but this is acceptable given the lack of parameters, aligning with the baseline for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the verb ('Get') and resource ('game state'), making the basic purpose clear. However, it lacks specificity about what constitutes the game state (e.g., campaign details, character positions, combat status) and doesn't distinguish it from sibling tools like 'get_campaign_info' or 'update_game_state', leaving ambiguity in scope.

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. It doesn't mention prerequisites, such as needing an active campaign, or clarify its role relative to siblings like 'get_campaign_info' for broader metadata or 'update_game_state' for modifications, leaving the agent to infer usage from context alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_locationC

Get location information.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Location name

TDQS

C2.4/5.0

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 of behavioral disclosure. It states 'Get location information' but doesn't explain what information is returned, if it's read-only, requires permissions, or has side effects. For a tool with no annotation coverage, this is a significant gap in transparency.

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, 'Get location information.', which is extremely concise and front-loaded. However, it may be overly brief, bordering on under-specification, as it lacks necessary details for a tool with no annotations or output schema.

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?

Given the complexity of a tool that retrieves specific data, with no annotations and no output schema, the description is incomplete. It doesn't explain what 'location information' includes, how results are structured, or error conditions, leaving gaps for an AI agent to use it correctly.

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 the parameter 'name' documented as 'Location name'. The description doesn't add any meaning beyond this, such as format examples or constraints. Since the schema provides adequate coverage, the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get location information' restates the tool name 'get_location' with minimal elaboration, making it tautological. It specifies the resource ('location') but lacks a clear verb beyond 'get' and doesn't differentiate from sibling tools like 'list_locations' or 'create_location', leaving the exact purpose vague.

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. It doesn't mention prerequisites, context, or exclusions, such as whether it retrieves a specific location by name versus listing all locations, which is handled by 'list_locations'. This absence leaves usage unclear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_npcC

Get NPC information.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	NPC name

TDQS

C2.7/5.0

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 of behavioral disclosure. It states the tool retrieves information, implying it's a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors (e.g., if the NPC doesn't exist). This leaves significant gaps for an agent to understand how to interact with it effectively.

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 extremely concise at three words, with zero wasted language. It's front-loaded with the core action ('Get NPC information'), making it easy to parse quickly. Every word earns its place by conveying the essential purpose without redundancy.

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?

Given the tool's complexity (a read operation with one parameter) and lack of annotations or output schema, the description is incomplete. It doesn't explain what information is returned (e.g., JSON structure, fields like health or alignment), error conditions, or how it fits into the broader RPG context with siblings. This leaves the agent with insufficient context for reliable use.

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, with the single parameter 'name' clearly documented as 'NPC name'. The description adds no additional meaning beyond this, such as format examples (e.g., case sensitivity) or context (e.g., must match an existing NPC). With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get NPC information' clearly states the verb ('Get') and resource ('NPC information'), making the basic purpose understandable. However, it's vague about what specific information is retrieved (e.g., stats, backstory, location) and doesn't differentiate from sibling tools like 'list_npcs' (which likely lists multiple NPCs) or 'get_character' (which might handle player characters).

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a specific NPC name), exclusions, or comparisons to siblings like 'list_npcs' (for browsing) or 'get_character' (for other character types). Usage is implied only by the tool name and basic purpose.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sessionsB

Get all session notes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is read-only, requires permissions, has rate limits, returns paginated results, or what format the notes are in. This is inadequate for a tool with zero annotation coverage.

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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse.

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?

Given no annotations, no output schema, and the description's minimalism, this is incomplete for a data retrieval tool. It lacks details on return values, error handling, or behavioral traits, leaving significant gaps for an agent to understand how to use it effectively.

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?

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable here since there are no parameters to explain, aligning with the baseline for zero parameters.

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 verb ('Get') and resource ('all session notes'), making the purpose specific and understandable. It distinguishes from siblings like 'add_session_note' (which creates) and 'get_events' (which retrieves different data), though it doesn't explicitly differentiate them in the text.

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. It doesn't mention prerequisites, context for retrieving session notes, or compare with other data-fetching tools like 'get_events' or 'get_campaign_info', leaving usage entirely implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_campaignsB

List all available campaigns.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

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 states it lists campaigns but doesn't disclose behavioral traits like whether it returns all campaigns at once, requires authentication, has rate limits, or what the output format is. This leaves significant gaps for a tool with no annotations.

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, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it highly concise and well-structured.

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?

Given the complexity (simple list operation) but lack of annotations and output schema, the description is incomplete. It doesn't explain return values, pagination, or error handling, which are needed for a tool with no structured output documentation.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 for compensating with simplicity.

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 verb ('List') and resource ('all available campaigns'), making the purpose specific and understandable. It distinguishes from siblings like 'get_campaign_info' (detailed info) and 'load_campaign' (load specific campaign), though it doesn't explicitly mention these distinctions.

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. It doesn't mention prerequisites, such as needing a loaded campaign, or differentiate from other list tools like 'list_characters' or 'list_quests' in context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_charactersB

List all characters in the current campaign.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits such as pagination, sorting, filtering, rate limits, permissions required, or response format. For a list operation with zero annotation coverage, this is inadequate, though it correctly implies a read-only action.

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, efficient sentence that directly states the tool's purpose without redundancy. It is front-loaded and wastes no words, making it highly concise and well-structured for its simple function.

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?

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is minimal but incomplete. It lacks context on output (e.g., list format, fields), behavioral details, and usage guidelines, which are needed even for simple tools to ensure correct agent invocation.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter details, which is appropriate. Baseline is 4 for zero parameters, as the description doesn't need to compensate for any schema gaps.

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 action ('List') and resource ('characters'), specifying scope with 'in the current campaign'. It distinguishes from siblings like 'get_character' (single character) and 'list_campaigns' (different resource), though not explicitly. However, it lacks explicit sibling differentiation, preventing a perfect score.

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 provides minimal guidance, implying usage when listing characters in the current campaign, but offers no explicit when-to-use rules, alternatives (e.g., vs. 'get_character'), or exclusions. It doesn't address prerequisites like needing a loaded campaign, leaving gaps in usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_locationsB

List all locations in the current campaign.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, how results are formatted, or any limitations (e.g., pagination). The description is minimal and lacks context beyond the core purpose.

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, clear sentence with no wasted words. It's front-loaded with the essential action and resource, making it highly efficient and easy to parse for an AI agent.

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 tool's low complexity (0 parameters, no output schema), the description is adequate but minimal. It states what the tool does but lacks context on usage, behavior, or output, which could be helpful since there are no annotations. It meets minimum viability but has clear gaps in guidance and transparency.

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?

There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, making a baseline score of 4 suitable as it avoids redundancy while matching the tool's simplicity.

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 action ('List') and resource ('locations'), specifying scope with 'in the current campaign'. It distinguishes from siblings like 'get_location' (singular) and 'create_location', but doesn't explicitly differentiate from other list tools like 'list_characters' or 'list_npcs' beyond resource type.

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 is provided. The description implies usage for listing all locations in a campaign, but doesn't mention prerequisites (e.g., needing a loaded campaign) or contrast with other tools like 'get_location' for specific details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_npcsB

List all NPCs in the current campaign.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

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 of behavioral disclosure. It states the action but lacks details on permissions, rate limits, pagination, return format, or whether it's read-only (implied by 'List' but not explicit). For a tool with zero annotation coverage, this is a significant gap in transparency.

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, clear sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it highly efficient and easy to parse.

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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on behavioral traits, output format, or usage guidelines. With no output schema, the agent doesn't know what data is returned, which is a notable gap for a list operation.

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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion.

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 verb ('List') and resource ('all NPCs in the current campaign'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_npc' (which likely retrieves a single NPC) or 'list_characters' (which might list player characters), so it falls short of a perfect score.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a loaded campaign), exclusions, or comparisons to similar tools like 'get_npc' or 'list_characters', leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_questsB

List quests, optionally filtered by status.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter by status

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read-only operation, it doesn't specify whether this requires authentication, what format the results come in, whether there's pagination, rate limits, or what happens when no quests match the filter. The description lacks essential behavioral context for a tool with no annotation coverage.

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, efficient sentence that communicates the core functionality without any wasted words. It's appropriately sized for a simple list tool and front-loads the essential information. Every word earns its place in this concise formulation.

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?

For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (quest objects, IDs only, metadata), how results are structured, or any behavioral constraints. Given the lack of structured data about outputs and behavior, the description should provide more context about what agents can expect when invoking this 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 description mentions 'optionally filtered by status' which aligns with the single parameter in the schema. With 100% schema description coverage and the parameter well-documented in the schema (including enum values and default), the description adds minimal value beyond what's already in structured data. The baseline of 3 is appropriate when the schema does the heavy lifting.

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 verb ('List') and resource ('quests') with the optional filtering capability. It distinguishes from other quest-related tools like 'create_quest' and 'update_quest' by focusing on retrieval rather than mutation. However, it doesn't explicitly differentiate from other list tools like 'list_campaigns' or 'list_characters' beyond the resource type.

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 retrieving quests with optional status filtering, but provides no explicit guidance on when to use this tool versus alternatives like 'get_game_state' or 'get_events' that might contain quest information. There's no mention of prerequisites, limitations, or specific scenarios where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

load_campaignC

Load a specific campaign.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Campaign name to load

TDQS

C2.7/5.0

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 of behavioral disclosure. 'Load' implies a read operation, but it doesn't specify if this retrieves data, sets state, requires permissions, or has side effects. Without annotations, this is a significant gap for understanding the tool's behavior.

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, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, earning its place without unnecessary elaboration.

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?

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'load' returns or how it differs from similar tools, leaving gaps in understanding the tool's full context and behavior for effective use.

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 the parameter 'name' documented as 'Campaign name to load.' The description adds no additional meaning beyond this, as it doesn't explain format, constraints, or examples. Baseline 3 is appropriate since the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool's purpose as 'Load a specific campaign,' which is clear but vague. It specifies the verb 'load' and resource 'campaign,' but doesn't distinguish it from sibling tools like 'get_campaign_info' or 'list_campaigns,' leaving ambiguity about what 'load' entails compared to 'get' or 'list.'

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. With siblings like 'get_campaign_info' and 'list_campaigns,' the description lacks context on use cases, prerequisites, or exclusions, leaving the agent to infer usage without explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

next_turnB

Advance to the next turn in combat.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('advance to next turn') but doesn't explain what this entails - whether it changes initiative order, triggers automatic effects, updates character states, or has side effects. For a mutation tool with zero annotation coverage, this is insufficient.

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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it immediately understandable without unnecessary elaboration.

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?

For a combat progression tool with no annotations and no output schema, the description is inadequate. It doesn't explain what 'advancing to the next turn' actually does operationally, what state changes occur, or what the agent should expect after invocation. Given the complexity of combat systems, more behavioral context is needed.

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?

The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's purpose.

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 action ('advance to') and resource ('next turn in combat'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling combat tools like 'start_combat' or 'end_combat' in terms of when each should be used in the combat flow.

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 provides no guidance on when to use this tool versus alternatives like 'end_combat' or 'update_game_state', nor does it specify prerequisites such as requiring combat to be active. It simply states what the tool does without contextual usage information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

roll_diceC

Roll dice with D&D notation.

ParametersJSON Schema

Name	Required	Description
`dice_notation`	Yes	Dice notation (e.g., '1d20', '3d6+2')
`advantage`	No	Roll with advantage
`disadvantage`	No	Roll with disadvantage

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Roll dice with D&D notation' implies a random generation operation but doesn't disclose important behavioral traits like whether results are deterministic, if there are rate limits, what the output format will be, or how advantage/disadvantage mechanics work. This leaves significant gaps for an agent to understand the tool's behavior.

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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple dice rolling tool and front-loads the essential information.

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?

For a tool with no annotations, no output schema, and three parameters, the description is insufficiently complete. It doesn't explain what the tool returns, how advantage/disadvantage affects results, or provide examples of typical use cases. The agent would need to guess about the output format and behavioral details.

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 description mentions 'D&D notation' which provides context for the dice_notation parameter, but doesn't add meaningful semantic information beyond what the schema already provides. With 100% schema description coverage, the baseline is 3, and the description doesn't significantly enhance understanding of the three parameters or their interactions.

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 action ('Roll dice') and specifies the notation system ('D&D notation'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'calculate_experience' or 'next_turn' that might also involve dice mechanics in a D&D context.

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 provides no guidance on when to use this tool versus alternatives. There's no mention of when to choose roll_dice over other tools like 'calculate_experience' or 'next_turn' that might handle dice rolling in different contexts, nor does it specify prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_combatC

Start a combat encounter.

ParametersJSON Schema

Name	Required	Description	Default
`participants`	Yes	Combat participants with initiative order

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Start') but doesn't explain what starting a combat entails—such as whether it initializes a state, requires specific permissions, affects other game elements, or has side effects. This leaves critical behavioral traits unspecified for a mutation 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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, earning a top score for brevity and clarity in structure.

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?

Given the complexity of starting a combat encounter (a mutation with potential game state impacts), no annotations, and no output schema, the description is incomplete. It fails to address what the tool returns, how it interacts with other tools like 'end_combat', or any behavioral nuances, leaving significant gaps for the agent to operate effectively.

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 description coverage is 100%, with the parameter 'participants' documented as 'Combat participants with initiative order'. The description adds no additional meaning beyond this, so it meets the baseline of 3 where the schema handles parameter documentation adequately without extra value from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Start a combat encounter' clearly states the verb ('Start') and resource ('a combat encounter'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'end_combat' or 'next_turn' beyond the obvious directional difference, leaving room for ambiguity about what specifically distinguishes this tool from related combat operations.

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. The description lacks context about prerequisites (e.g., whether a combat must not already be active), exclusions, or relationships with siblings like 'end_combat' or 'next_turn', leaving the agent to infer usage based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_characterC

Update a character's properties.

ParametersJSON Schema

Name	Required	Description
`name_or_id`	Yes	The name or ID of the character to update.
`name`	No	New character name. If you change this, you must use the character's ID to identify them.
`player_name`	No	The name of the player in control of this character
`description`	No	A brief description of the character's appearance and demeanor.
`bio`	No	The character's backstory, personality, and motivations.
`background`	No	Character background
`alignment`	No	Character alignment
`hit_points_current`	No	Current hit points
`hit_points_max`	No	Maximum hit points
`temporary_hit_points`	No	Temporary hit points
`armor_class`	No	Armor class
`inspiration`	No	Inspiration status
`notes`	No	Additional notes about the character
`strength`	No	Strength score
`dexterity`	No	Dexterity score
`constitution`	No	Constitution score
`intelligence`	No	Intelligence score
`wisdom`	No	Wisdom score
`charisma`	No	Charisma score

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention permission requirements, whether changes are reversible, error conditions, or what happens to unspecified properties. For a mutation tool with 19 parameters and no annotation coverage, this leaves significant behavioral gaps.

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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a tool with comprehensive schema documentation and is perfectly front-loaded with the essential information.

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?

For a mutation tool with 19 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens when properties are updated (e.g., partial updates, validation rules), doesn't mention the response format, and provides no behavioral context. The schema handles parameter documentation well, but the description fails to address the broader operational context.

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 each parameter well-documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter semantics.

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 'Update a character's properties' clearly states the verb ('Update') and resource ('character's properties'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'bulk_update_characters' or 'update_game_state', which would require specifying this is for individual character updates.

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 about when to use this tool versus alternatives like 'bulk_update_characters' for multiple characters or 'create_character' for new characters. The description offers no context about prerequisites, typical use cases, or exclusions, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_game_stateC

Update the current game state.

ParametersJSON Schema

Name	Required	Description
`current_location`	No	Current party location
`current_session`	No	Current session number
`current_date_in_game`	No	Current in-game date
`party_level`	No	Average party level
`party_funds`	No	Party treasure/funds
`in_combat`	No	Whether party is in combat
`notes`	No	Current situation notes

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Update' implies a mutation operation, but the description doesn't address permissions needed, whether changes are reversible, what happens when only partial parameters are provided, or how this tool interacts with related tools like 'get_game_state'. The description fails to provide meaningful behavioral context beyond the basic action implied by the name.

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 maximally concise at just 5 words. While this conciseness comes at the expense of helpful information, the description contains zero wasted words and is perfectly front-loaded with the core action. Every word serves the minimal purpose of stating the tool's basic function.

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?

For a mutation tool with 7 parameters, no annotations, and no output schema, the description is severely inadequate. It doesn't explain what 'game state' encompasses, how updates affect the system, what validation occurs, or what the tool returns. The combination of sparse description and missing structured metadata leaves significant gaps in understanding this tool's behavior and proper use.

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 description provides no parameter information, but the input schema has 100% description coverage with clear documentation for all 7 parameters. Each parameter has a descriptive title and explanation of what it represents (e.g., 'Current party location', 'Average party level', 'Whether party is in combat'). The schema does the heavy lifting, establishing a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update the current game state' is essentially a tautology that restates the tool name 'update_game_state' without adding meaningful specificity. It doesn't clarify what aspects of game state are updated or how this differs from sibling tools like 'update_character' or 'update_quest' that also modify game-related data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools that modify game data (update_character, update_quest, bulk_update_characters, etc.), there's no indication of what distinguishes this tool's purpose or appropriate context for its use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_questC

Update quest status or complete objectives.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Quest title
`status`	No	New quest status
`completed_objective`	No	Objective to mark as completed

TDQS

C2.9/5.0

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 of behavioral disclosure. It states the tool updates quests, implying mutation, but doesn't describe side effects (e.g., whether changes are reversible), permissions needed, error conditions, or what happens if multiple updates conflict. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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, efficient sentence: 'Update quest status or complete objectives.' It's front-loaded with the core action and avoids unnecessary words. However, it could be slightly more structured by separating status and objective updates for clarity, but it's still highly concise.

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?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances like whether partial updates are allowed. For a tool that modifies game state in a role-playing context, more context is needed to ensure safe and effective use.

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 fully documents all three parameters (title, status, completed_objective) with descriptions and types. The description adds no additional meaning beyond what's in the schema—it mentions 'status' and 'objectives' but doesn't clarify syntax, constraints, or interactions between parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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's purpose: 'Update quest status or complete objectives.' It specifies the verb ('update') and resource ('quest'), and indicates what can be updated (status or objectives). However, it doesn't explicitly differentiate from sibling tools like 'create_quest' or 'list_quests' beyond the update action.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing quest), exclusions, or comparisons to siblings like 'update_game_state' or 'bulk_update_characters' that might handle quest-related updates differently. Usage is implied but not explicitly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

30 tool updatesAug 15, 2025
- First observedadd_event
- First observedadd_item_to_character
- First observedadd_session_note
- First observedbulk_update_characters
- First observedcalculate_experience
- First observedcreate_campaign
- First observedcreate_character
- First observedcreate_location
- First observedcreate_npc
- First observedcreate_quest
- First observedend_combat
- First observedget_campaign_info
- First observedget_character
- First observedget_events
- First observedget_game_state
- First observedget_location
- First observedget_npc
- First observedget_sessions
- First observedlist_campaigns
- First observedlist_characters
- First observedlist_locations
- First observedlist_npcs
- First observedlist_quests
- First observedload_campaign
- First observednext_turn
- First observedroll_dice
- First observedstart_combat
- First observedupdate_character
- First observedupdate_game_state
- First observedupdate_quest

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific D&D gameplay elements like characters, campaigns, combat, and quests. There is no overlap; for example, 'add_item_to_character' and 'update_character' serve different functions, and tools like 'roll_dice' and 'start_combat' are unique in their actions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as 'create_character', 'list_campaigns', and 'update_quest'. This uniformity makes the tool set predictable and easy for agents to understand and navigate without confusion.

Tool Count3/5

With 30 tools, the count is on the higher side for a D&D server, bordering on heavy. While it covers many aspects comprehensively, it might be overwhelming for agents, as typical well-scoped servers have 3-15 tools. However, it's not extreme like 50+ tools.

Completeness5/5

The tool set provides complete CRUD/lifecycle coverage for D&D campaign management, including creation, listing, updating, and deletion (implied through updates) for characters, campaigns, NPCs, locations, and quests. It also handles combat, dice rolling, and game state, leaving no obvious gaps for core gameplay workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Archivist AIOAuth
io.github.Astrotomic
Official remote MCP server for Archivist AI TTRPG campaign memory: characters, sessions, and more.
Knowledge & Memory Games & Gamification
23
argo-mcp A
io.github.Argo-RPG-Platform
MCP server for Argo RPG Platform — connects AI assistants to campaign data via OAuth2
Games & Gamification Knowledge & Memory
6221
GrimoireOAuth
bot.ttrpg
Campaign manager for D&D and TTRPG GMs: your AI reads and writes a live typed campaign database.
Games & Gamification Knowledge & Memory
21
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

FoundryVTT MCP Server
Games & Gamification RAG Systems Autonomous Agents
laurigates
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that integrates with FoundryVTT, allowing AI assistants to interact with tabletop gaming sessions through natural language to query actors, roll dice, generate content, and manage game worlds.
Updated a day ago (2026-09-05 06:57 UTC)
239
29
MIT
Writer MCP
Knowledge & Memory Vector Databases
huangjien
A
license
Not graded
quality
F
maintenance
A Model Context Protocol server that manages character knowledge and relationships for creative writing projects, offering semantic search and AI-powered analysis.
Updated a year ago (2025-07-05 19:17 UTC)
4
MIT
DM20 Protocol
Games & Gamification RAG Systems Knowledge & Memory
Polloinfilzato
A
license
B
quality
D
maintenance
A comprehensive MCP server for managing AI-assisted Dungeons & Dragons campaigns, featuring tools for character sheets, combat tracking, and world-building. It enables players and DMs to interact with 5e game mechanics and query personal PDF rulebooks using RAG capabilities.
Updated 2 months ago (2026-06-28 23:04 UTC)
97
2
MIT
D&D Beyond MCP Server
Games & Gamification Entertainment & Media
iamjameslennon
A
license
A
quality
A
maintenance
A Model Context Protocol server that gives Claude direct access to your D\&D Beyond account for characters, campaigns, sourcebooks, spells, monsters, rules, encounters, and treasure.
Updated 13 days ago (2026-08-24 09:37 UTC)
35
25
1
MIT

Appeared in Searches

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/study-flamingo/gamemaster-mcp'

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