DM20 Protocol

by Polloinfilzato

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation3/5
Most tools have distinct purposes, but there is notable overlap in some areas. For example, 'ask_books', 'search_library', and 'search_rules' all involve searching content, which could cause confusion. Similarly, 'import_character_file' and 'import_from_dndbeyond' both import characters but from different sources, potentially leading to misselection. However, descriptions help clarify differences, preventing severe ambiguity.
Naming Consistency4/5
Tool names generally follow a consistent verb_noun pattern, such as 'add_death_save', 'create_character', and 'list_campaigns'. There are minor deviations, like 'ask_books' (verb_noun but less common) and 'party_get_prefetch' (noun_verb_noun), but overall the naming is predictable and readable across the set.
Tool Count2/5
With 97 tools, the count is excessive for a D&D campaign management server, making it overwhelming and difficult to navigate. While the domain is broad, many tools could be consolidated or grouped (e.g., multiple import/export tools) to reduce complexity. This high number detracts from usability and coherence.
Completeness5/5
The tool set provides comprehensive coverage for D&D campaign management, including character creation, combat, rulebook handling, campaign administration, and multi-player features. There are no obvious gaps; it supports CRUD operations for entities like characters, NPCs, and quests, and includes advanced functionalities like AI DM sessions and party mode, ensuring agents can handle all typical workflows.
Average 3.5/5 across 97 of 97 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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 but offers nothing beyond the basic action. It doesn't mention whether this is a write operation (implied by 'Create'), what permissions are required, whether the quest becomes immediately active, what happens on failure, or any side effects. For a mutation tool with zero annotation coverage, this is critically 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 maximally concise at just three words with no wasted space. It's front-loaded with the essential action and resource. While severely under-specified, it's not verbose or poorly structured—it simply lacks necessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 completely inadequate. It doesn't explain what a 'quest' represents in this system, what happens after creation, how it relates to other entities (campaigns, characters), or what the expected outcome is. The agent must rely entirely on the parameter schema with no contextual guidance.
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 whatsoever, but the schema has 100% description coverage with clear documentation for all 6 parameters. Since the schema does all the heavy lifting, the baseline score of 3 is appropriate. The description adds zero value beyond what's already in the structured schema.
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 merely restates the tool name without adding meaningful context. It specifies the verb ('Create') and resource ('quest'), but fails to distinguish this tool from sibling tools like 'create_campaign', 'create_character', or 'create_location' that follow the same pattern. No additional purpose details are provided.
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 on when to use this tool versus alternatives. There are no mentions of prerequisites, appropriate contexts, or comparisons to sibling tools like 'update_quest' or 'list_quests'. The agent receives no help in determining when this specific creation tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Update' implies mutation, but there's no indication of permissions required, whether changes are persistent, if there are side effects, or what happens when parameters are omitted. The description doesn't address rate limits, error conditions, or response format.
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 5 words with zero wasted language. While under-specified, it's not verbose or poorly structured—it's front-loaded and doesn't contain 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 7 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what 'game state' encompasses, how updates are applied, what validation occurs, or what the tool returns. The combination of sparse description and missing structured metadata leaves significant gaps for agent understanding.
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 titles and descriptions. The tool description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation when schema coverage is complete.
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 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'.
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. There's no mention of prerequisites, appropriate contexts, or comparisons to related tools like 'get_game_state' or 'update_character' that might handle overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Load a specific campaign' is vague—it doesn't clarify if this is a read-only operation, if it modifies state, requires permissions, has side effects, or what the expected outcome is. For a tool with no annotation coverage, this leaves critical behavioral traits unspecified.
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 extremely concise—a single sentence with no wasted words. However, this conciseness comes at the cost of under-specification, as it lacks necessary detail for a tool with no annotations. It's front-loaded but overly minimal.
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 'loading' entails, the return value, or how it differs from sibling tools. For a tool in a complex server with many siblings, this minimal description fails to provide adequate context for an AI agent to use it 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 single parameter 'name' clearly documented in the schema as 'Campaign name to load'. The description doesn't add any additional meaning beyond this, such as format examples or constraints, but with high schema coverage, a baseline score of 3 is appropriate as the schema adequately handles parameter documentation.
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 'Load a specific campaign' is essentially a tautology that restates the tool name 'load_campaign' without adding meaningful specificity. It doesn't distinguish this tool from siblings like 'get_campaign_info' or 'list_campaigns' in terms of what 'loading' actually entails versus getting information or listing campaigns.
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 siblings like 'get_campaign_info', 'list_campaigns', and 'create_campaign', there's no indication whether 'load' implies opening for editing, retrieving details, or some other action, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 fails to describe any behavioral traits: it doesn't specify if this is a read-only or destructive operation, what happens to existing combat state, error conditions, or output format. The description is too vague to inform the agent about how the tool behaves beyond the basic 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, concise sentence with zero wasted words. It's front-loaded with the core action ('Start a combat encounter'), making it easy to parse quickly. No unnecessary details or redundancy are present.
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 combat (likely involving state changes and interactions with other tools), the description is incomplete. With no annotations and no output schema, it lacks crucial details: it doesn't explain what the tool returns, error handling, or how it integrates with sibling tools like 'next_turn' or 'end_combat'. This leaves significant gaps for an agent to understand the tool's role in the broader 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?
Schema description coverage is 100%, with the parameter 'participants' documented as 'Combat participants with initiative order'. The description adds no additional meaning beyond this, as it doesn't elaborate on participant structure, initiative rules, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema handles the 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 'Start a combat encounter' clearly states the verb ('Start') and resource ('combat encounter'), making the purpose understandable. However, it lacks specificity about what 'starting' entails (e.g., initializing a tracker, setting initiative) and doesn't differentiate from sibling tools like 'end_combat' or 'combat_action', which are related but distinct.
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 participants defined), exclusions (e.g., not for ongoing combat), or related tools like 'end_combat' or 'next_turn'. 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.
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 'process a player action' but doesn't explain what processing involves—e.g., whether it updates game state, requires authentication, has side effects, or handles errors. For a tool with no annotations, this leaves critical behavioral traits unspecified.
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, straightforward sentence with no wasted words, making it easy to parse. However, it's front-loaded without elaboration, which could benefit from more detail given the tool's potential complexity, but it remains appropriately sized for its minimal content.
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 for a tool that likely mutates game state or interacts with a session. It doesn't explain what happens after processing—e.g., returns a result, updates state, or triggers events. For a 4-parameter tool in a gaming context, this lacks necessary context 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?
The input schema has 100% description coverage, clearly documenting all four parameters. The description adds no additional meaning beyond the schema, such as examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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 'Process a player action in the current Claudmaster session,' which provides a verb ('process') and resource ('player action'), but it's vague about what 'process' entails—does it execute, validate, or log the action? It doesn't differentiate from siblings like 'combat_action' or 'party_resolve_action,' 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. With siblings like 'combat_action' and 'party_resolve_action,' the description lacks context on whether this is for general gameplay, specific session types, or prerequisites. It mentions 'current Claudmaster session' but doesn't clarify exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create a new location' implies a write/mutation operation, but it doesn't disclose behavioral traits such as permissions needed, whether creation is idempotent, error handling, or what happens on success (e.g., returns an ID). 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 front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place 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 complexity (a mutation tool with 7 parameters, no annotations, and no output schema), the description is incomplete. It doesn't address what the tool returns, error conditions, or how it integrates with the broader system (e.g., fantasy RPG context hinted by sibling tools). This leaves significant gaps for an agent to use it 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 parameters are well-documented in the schema. The description adds no additional meaning beyond the schema's parameter descriptions (e.g., it doesn't explain relationships between fields like 'location_type' and 'population'). Baseline 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 'Create a new location' clearly states the action (create) and resource (location), but it's vague about what constitutes a location in this context and doesn't differentiate from sibling tools like 'create_campaign' or 'create_character'. It provides basic purpose but lacks specificity about the domain (e.g., fantasy world-building).
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 doesn't mention prerequisites, dependencies, or relationships with sibling tools (e.g., 'get_location' for retrieval, 'list_locations' for listing). It leaves the agent to infer usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permissions needed, whether this is irreversible, rate limits, or what happens on success/failure. It provides minimal behavioral context beyond the basic 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 extremely concise at just 4 words. It's front-loaded with the essential action and resource. There's zero wasted verbiage or 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 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what an NPC is in this system, what happens after creation, error conditions, or relationship to other entities. The agent lacks sufficient context to use this tool 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 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.
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), but it's quite basic and doesn't differentiate from sibling tools like 'create_character' or 'create_campaign'. It's not tautological with the name, but lacks specificity about what an NPC is in this 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 like 'create_character' or 'update_character'. There's no mention of prerequisites, context, or exclusions. 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.
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 for behavioral disclosure. It states 'Get events' which implies a read-only operation, but doesn't clarify aspects like pagination, default ordering, error conditions, or rate limits. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
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 for a tool with 3 parameters. It doesn't explain what 'events' contain, how results are structured, or any behavioral constraints. For a retrieval tool in this context, more information about return values and usage patterns would be 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%, with clear documentation for all three parameters (limit, event_type, search). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline score when 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 events from the adventure log' clearly states the verb ('Get') and resource ('events from the adventure log'), making the purpose understandable. However, it doesn't differentiate this tool from potential siblings like 'get_sessions' or 'search_library' that might also retrieve event-related data, keeping it at a basic clarity 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. With siblings like 'get_sessions' and 'search_library' that might overlap in retrieving session or event data, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It doesn't indicate whether this is a read-only operation, what permissions might be required, how results are formatted, or whether there are rate limits. The description merely restates the tool's name without adding 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 at just three words, with zero wasted language. It's front-loaded with the core purpose, though this brevity comes at the cost of completeness. Every word earns its place by directly stating the tool's 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 tool with three parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'location information' includes, how results are structured, or behavioral aspects like permissions or side effects. The agent lacks context to understand the tool's full scope and limitations.
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 (name, discovery_filter, player_id). The description adds no additional parameter semantics beyond what's already in the schema, maintaining the baseline score of 3 for adequate but unenhanced parameter documentation.
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 location information' clearly states the verb ('Get') and resource ('location information'), making the basic purpose understandable. However, it's vague about what specific information is retrieved and doesn't distinguish this tool from potential siblings like 'list_locations' or 'get_campaign_info' that might also provide location-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 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, appropriate contexts, or comparison to sibling tools like 'list_locations' or 'get_campaign_info' that might serve related purposes. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Get all session notes' implies a read-only operation, but it doesn't specify permissions required, rate limits, pagination behavior, or what happens if no notes exist (e.g., returns empty list or error). For a tool with zero annotation coverage, this lack of behavioral detail is a significant gap, making it hard for an agent to predict outcomes.
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 'Get all session notes' is a single, front-loaded sentence with zero waste. It efficiently conveys the core action and resource without unnecessary words. Given the simplicity of the tool (no parameters), this conciseness is appropriate and effective.
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 simplicity (0 parameters, no output schema, no annotations), the description is minimally complete but lacks important context. It doesn't explain what 'session notes' are (e.g., text entries, metadata), how they are returned (e.g., list format, JSON structure), or any behavioral aspects like error handling. Without annotations or output schema, the description should provide more detail to be fully helpful for an agent.
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 any parameter information, which is acceptable here since there are no parameters to explain. A baseline score of 4 is appropriate as the schema fully covers the absence of parameters, and the description doesn't need to compensate.
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 all session notes' clearly states the verb ('Get') and resource ('session notes'), making the purpose understandable. However, it's somewhat vague about scope—'all' implies no filtering, but it doesn't specify if this includes archived or deleted notes, or how notes are structured. It distinguishes from siblings like 'add_session_note' by being a read operation, but lacks detail on what constitutes a 'session note' in this 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. For example, it doesn't mention if there are other tools for filtered or paginated retrieval of session notes, or if this is the primary method for accessing notes. With siblings like 'get_events' or 'summarize_session', there's no indication of how this tool fits into the workflow, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Add an event' implies a write/mutation operation, but the description doesn't disclose any behavioral traits: no information about permissions needed, whether this is idempotent, what happens on success/failure, or what the response contains. For a mutation 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 a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized and 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 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes a successful addition, what format the response takes, or any behavioral constraints. The description should provide more context about this write operation's implications and results.
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 8 parameters thoroughly. The description adds no parameter information beyond what's in the schema. According to scoring rules, when schema 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.
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 resource ('event to the adventure log'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'add_session_note' or 'add_death_save', which also add content to game logs.
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 many sibling tools that also add content (like add_session_note, add_spell, add_item_to_character), there's no indication of when this specific event-logging tool is appropriate versus other addition tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Add an item' implies a write/mutation operation, the description doesn't address permission requirements (though player_id parameter hints at this), whether duplicates are allowed, how inventory limits are handled, or what happens on success/failure. 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, efficient sentence that states the core functionality without unnecessary words. It's perfectly front-loaded with the essential action and target. Every word earns its place, making it easy to parse while conveying the fundamental 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?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after adding (e.g., returns success confirmation, updated character object, or nothing), doesn't mention error conditions or validation rules, and provides no context about inventory management system constraints. The description should do more given the tool's complexity.
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 8 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting, though the description could have explained relationships between parameters (e.g., how item_type influences other fields).
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 ('to a character's inventory'), making the purpose immediately understandable. It distinguishes from sibling tools like 'remove_item' or 'equip_item' by focusing on inventory addition. However, it doesn't specify whether this creates new items or adds existing ones, leaving some ambiguity.
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 'equip_item', 'remove_item', and 'create_character', there's no indication of prerequisites, typical workflows, or when this specific inventory addition operation is appropriate versus other item-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a write operation ('Add'), but doesn't disclose behavioral traits such as permissions needed, whether it creates or updates notes, error handling, or side effects. 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 no wasted words. It's front-loaded and appropriately sized for the tool's complexity, earning full marks for conciseness.
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 (11 parameters, no annotations, no output schema), the description is incomplete. It lacks context on behavior, output format, error cases, or integration with other tools like 'get_sessions', making it insufficient for effective use by an AI agent.
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 11 parameters. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when the schema does all the work.
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 'Add notes for a game session' clearly states the verb ('Add') and resource ('notes for a game session'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'summarize_session' or 'get_sessions', which might handle similar session-related data, so it misses 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. There's no mention of prerequisites, context (e.g., during or after a session), or comparison to siblings like 'summarize_session' or 'update_game_state', leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it updates properties 'by a given amount', implying additive changes, but doesn't clarify if this is a mutation (likely yes), what permissions are needed, whether changes are reversible, or how errors are handled (e.g., if some characters in the list don't exist). This leaves significant gaps for a tool that modifies multiple entities.
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 action ('update properties for multiple characters at once') without any fluff. Every word earns its place, 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 the complexity of updating multiple characters with various property changes, the description is inadequate. No annotations exist to clarify safety or behavior, and there's no output schema to indicate return values. The description doesn't address error handling, idempotency, or side effects, leaving 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?
Schema description coverage is 100%, so parameters are well-documented in the schema itself. The description adds marginal value by implying that changes are additive ('by a given amount'), which aligns with parameter names like 'hp_change', but doesn't provide additional context beyond what the schema already states (e.g., that 'names_or_ids' can include player names, or that changes can be positive or negative).
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') and resource ('multiple characters') with the scope 'by a given amount', making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'update_character' (singular) or 'apply_effect', leaving room for ambiguity about when to choose this bulk operation over alternatives.
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 characters) or 'apply_effect' (which might handle similar property changes). There's no mention of prerequisites, constraints, or typical use cases (e.g., after a party-wide event).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action is 'Delete,' implying a destructive mutation, but doesn't disclose critical behaviors: whether deletion is permanent/reversible, permission requirements, effects on related data (e.g., items, spells), or error handling. This leaves significant gaps for a destructive operation.
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 that front-loads the core action. There's no wasted text, but it could be slightly more structured (e.g., clarifying the parameter's purpose upfront). It earns a high score for brevity and clarity within its limited scope.
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 destructive tool with no annotations and no output schema, the description is inadequate. It lacks behavioral details (e.g., confirmation, side effects), error cases, and output expectations. Given the complexity of deletion and the absence of structured safety hints, more context is needed to guide safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'name_or_id' documented in the schema as 'Character name, ID, or player name.' The description repeats this exactly without adding further meaning (e.g., examples, precedence rules, or format details). With high schema 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('character from the current campaign'), making the purpose unambiguous. It distinguishes from sibling tools like 'delete_campaign' by specifying the target resource. However, it doesn't explicitly differentiate from similar deletion operations on other resources beyond the name.
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 character to exist), exclusions, or related tools like 'remove_item' or 'remove_spell' that might handle character components. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a 'Get' operation, implying read-only behavior, but doesn't specify permissions, rate limits, error conditions, or what the state includes (e.g., session metadata, participant info). This leaves significant gaps 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.
Conciseness4/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 unnecessary words. It's appropriately sized for a simple retrieval tool, though it could be slightly more informative (e.g., hinting at return content) without losing conciseness.
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 the 'state' includes (e.g., session status, participants, rules), how results are structured, or potential side effects. For a tool that likely returns complex session data, this leaves too much unspecified 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?
The input schema has 100% description coverage, clearly documenting all four parameters (session_id, detail_level, include_history, history_limit) with defaults and types. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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 ('current state of a Claudmaster AI DM session'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'get_game_state' or 'get_sessions', which might retrieve related but different information.
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 siblings like 'get_game_state' and 'get_sessions' available, there's no indication of what differentiates this tool (e.g., session-specific state vs. broader game state), leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for getting data, implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns structured data, or involves side effects. The description is minimal and lacks context beyond the basic 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, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose without 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 the complexity of game state (likely involving multiple entities and statuses), no annotations, and no output schema, the description is incomplete. It does not explain what the return value includes (e.g., JSON structure, fields) or behavioral aspects like error handling. For a tool with potential richness in output, more 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here. A baseline score of 4 is given as the schema fully handles parameters, and the description does not need to compensate.
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 the current game state' clearly states the verb ('Get') and resource ('current game state'), making the purpose understandable. However, it lacks specificity about what constitutes 'game state' (e.g., combat status, character positions, campaign progress) and does not differentiate from siblings like 'get_campaign_info' or 'get_party_status', which might overlap 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., requires an active game), exclusions, or comparisons to siblings such as 'update_game_state' or other get_* tools that might retrieve specific aspects of the game state. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns 'a list of quests with their basic information and status,' which gives some behavioral insight. However, it lacks details on pagination, rate limits, authentication needs, error conditions, or what constitutes 'basic information.' For a read operation with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences: one stating the purpose and optional filtering, and another describing the return. There's no wasted text, though it could be slightly more informative without losing efficiency.
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 (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return, but lacks context about the system (e.g., what a 'quest' is in this domain) and behavioral details needed for full understanding. It meets the minimum viable threshold.
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 the single optional parameter 'status' with its enum values and default. The description adds marginal value by mentioning 'optionally filtered by status,' but doesn't provide additional semantics beyond what the schema already states. Baseline 3 is appropriate when 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: 'List quests, optionally filtered by status.' It specifies the verb ('List') and resource ('quests'), and mentions the optional filtering capability. However, it doesn't explicitly differentiate from sibling tools like 'create_quest' or 'update_quest' beyond the basic verb difference.
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 usage guidance. It mentions optional filtering by status but doesn't specify when to use this tool versus alternatives like 'get_quest' (if it existed) or other list tools. No context about prerequisites, typical workflows, or exclusion criteria is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Remove' implies a destructive mutation, it doesn't specify whether this action is reversible, what permissions are required, or what happens on success/failure. The description lacks critical context about the operation'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, efficient sentence that states the tool's purpose without unnecessary words. It's front-loaded with the core action and target, making it immediately scannable and easy to understand.
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 destructive mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, what error conditions might occur, or important behavioral details (like whether removal is permanent). The agent lacks critical information to use this tool 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 already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify format requirements or provide examples). This meets the baseline for high schema coverage.
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 ('Remove') and target resource ('a spell from a character's spells known list'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'remove_item' or 'remove_effect', but the specificity of 'spell' and 'spells known list' provides adequate distinction.
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., the spell must already be known), nor does it reference related tools like 'add_spell' or 'use_spell_slot'. The agent must infer usage from the tool 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.
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 doesn't explain what happens when dice are rolled (e.g., random generation, result display, persistence), whether rolls are logged somewhere, or if there are any constraints like maximum dice count. 'Roll dice' implies a write/action operation, but details are lacking.
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 wasted words. It's front-loaded with the core purpose and uses specific terminology ('D&D notation') that experienced users will immediately understand.
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 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (e.g., individual dice results, totals, formatted output), how errors are handled, or the tool's role within the broader D&D tool ecosystem. The single sentence leaves too many behavioral questions unanswered.
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 fully documents all four parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of complex notation, no explanation of how advantage/disadvantage interact). 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 action ('Roll dice') and specifies the notation system ('D&D notation'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'combat_action' or 'player_action' that might also involve dice rolling in specific contexts, 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 no guidance on when to use this tool versus alternatives. With many sibling tools like 'combat_action', 'player_action', or 'calculate_experience' that might involve dice mechanics, there's no indication of whether this is a general-purpose dice roller or intended for specific game phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action but doesn't describe what happens during session initiation/resumption, whether this requires specific permissions, what the expected response looks like, or any side effects. For a session management 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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for the tool's function and gets straight to the point.
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 session management tool with no annotations and no output schema, the description is inadequate. It doesn't explain what constitutes a successful session start/resume, what state changes occur, or what the agent should expect after invocation. The context demands more behavioral and outcome information.
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 four parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, meeting the baseline expectation but not providing extra value.
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 ('Start or resume') and resource ('Claudmaster AI DM session'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_claudmaster_session_state' or 'end_claudmaster_session' beyond the basic verb distinction.
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. The description doesn't mention prerequisites, when to choose 'start' vs 'resume', or how this relates to other session management tools like 'end_claudmaster_session' or 'get_claudmaster_session_state'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the types of operations supported (scalar updates, ability score changes, list add/remove) and format details for list parameters, but lacks critical information: whether this is a destructive mutation, what permissions are needed (especially given the 'player_id' parameter), what happens on partial updates, error conditions, or response format. For a complex mutation tool with 36 parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with three sentences: a purpose statement, a scope overview, and format details for list parameters. Each sentence adds value without redundancy. It could be slightly more front-loaded by mentioning the key identifier parameter first, but overall it's appropriately concise for a tool with many parameters.
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 (36 parameters, mutation operation, no annotations, no output schema), the description is insufficient. It should explain more about the mutation behavior: whether updates are partial or complete, what validation occurs, how errors are handled, what the response contains, and permission requirements. The format details for list parameters are helpful but don't compensate for the missing behavioral context needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by grouping parameters into categories (scalar fields, ability scores, list operations) and providing format examples for list parameters. However, it doesn't explain parameter interactions (e.g., that changing 'name' requires using ID in 'name_or_id') or semantic constraints beyond what's in individual parameter descriptions.
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 a character's properties' with specific categories of updates (scalar fields, ability scores, list operations). It distinguishes from sibling tools like 'create_character' or 'delete_character' by focusing on modification rather than creation or deletion. However, it doesn't explicitly differentiate from 'bulk_update_characters' or 'level_up_character' which are more specific variants.
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 when to choose 'update_character' over 'bulk_update_characters' for multiple characters, or when to use 'level_up_character' for level-specific updates versus the general 'character_level' parameter here. There's also no mention of prerequisites like character existence or permission requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool updates quests, implying mutation, but doesn't describe what happens on success/failure, whether changes are reversible, permission requirements, or side effects (e.g., if completing objectives triggers other events). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that front-loads the core functionality ('Update quest status or complete objectives'). There is zero wasted text, no redundancy, and it efficiently communicates the tool's purpose 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 tool's complexity (mutation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, return values, or operational constraints. For a tool that modifies game state, more context is needed to ensure safe and correct usage by an AI agent.
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 enums. The description adds minimal value beyond the schema by mentioning 'status' and 'objectives' generally, but doesn't provide additional context like parameter interactions (e.g., if both status and completed_objective can be set simultaneously). Baseline 3 is appropriate when 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 with specific verbs ('update quest status or complete objectives'), identifying the resource ('quest') and the actions it performs. It distinguishes itself from sibling tools like 'create_quest' by focusing on modification rather than creation, though it doesn't explicitly differentiate from other update tools like 'update_character' or 'update_game_state'.
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., quest must exist), exclusions (e.g., cannot update non-existent quests), or relationships with sibling tools like 'list_quests' for reference or 'create_quest' for initial setup. Usage is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool's purpose but reveals nothing about permissions required, whether this is a destructive/write operation, what happens on success/failure, or any rate limits. For a tool that modifies character data, 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 that states the tool's core purpose without any wasted words. It's appropriately sized for a tool with a straightforward function and well-documented schema.
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?
For a mutation tool with no annotations and no output schema, the description is minimally adequate. It states what the tool does but lacks crucial context about behavioral implications, success conditions, or error handling. The 100% schema coverage helps, but the description alone doesn't provide complete guidance for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter information beyond what's already in the schema, which has 100% description coverage. The baseline score of 3 reflects that the schema adequately documents all 11 parameters, so the description doesn't need to compensate but also adds no extra value.
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 a spell') and target ('to a character's spells known list'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'remove_spell' or 'use_spell_slot', which would be needed for 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, appropriate contexts, or when other tools might be more suitable, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool calculates experience points but doesn't disclose behavioral traits like whether it modifies game state, requires specific permissions, handles edge cases (e.g., negative XP), or returns structured data. For a calculation tool with zero annotation coverage, this leaves significant 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 with zero waste. It's front-loaded with the core purpose and appropriately sized for a straightforward calculation tool.
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 moderate complexity (calculation with three inputs) and lack of annotations/output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output format. With no output schema, the description should ideally hint at return values.
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 (party_size, party_level, encounter_xp). The description adds no additional parameter semantics beyond implying these are inputs for the calculation. 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 with a specific verb ('calculate') and resource ('experience points for an encounter'). It distinguishes itself from siblings by focusing on XP calculation rather than character management, combat, or other operations. However, it doesn't explicitly differentiate from potential similar tools (none exist in the sibling 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing encounter data first), context (e.g., post-combat), or comparisons to other tools. The sibling list includes 'build_encounter_tool' which might relate, but no connection is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions state saving, which is useful, but doesn't cover critical aspects like whether this operation is reversible, what permissions are needed, if it affects other sessions, or what the response looks like. For a session termination/pausing tool, 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 front-loads the core action and outcome. Every word contributes meaning with zero waste, making it appropriately sized for the tool's complexity.
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 moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavioral implications, error conditions, or return values. The high schema coverage helps, but for a session management tool with mutation effects, more context would be beneficial.
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 four parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, such as explaining the implications of choosing 'pause' vs 'end' modes. This meets the baseline for high schema coverage.
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 ('end or pause') and resource ('Claudmaster AI DM session'), and specifies the outcome ('saving all state'). It distinguishes from sibling tools like 'start_claudmaster_session' by indicating termination/pausing rather than initiation, though it doesn't explicitly contrast with other session management tools.
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. While it's implied to be used after starting a session with 'start_claudmaster_session', there's no mention of prerequisites, timing considerations, or what happens if used incorrectly. The description lacks explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action ('End') but doesn't disclose what ending combat entails—whether it clears initiative, resets states, triggers experience calculation, or affects game state. 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, direct sentence with no wasted words. It's front-loaded with the core action and target, 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?
For a tool that likely mutates game state (ending combat), the description is incomplete. With no annotations, no output schema, and minimal behavioral disclosure, it lacks crucial context about effects, side effects, or return values. It should clarify what 'ending' entails in this system.
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 no parameter documentation is needed. The description doesn't add parameter semantics, but that's appropriate given the empty schema. Baseline is 4 for zero-parameter tools.
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 target ('current combat encounter'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'start_combat' or 'combat_action', which would require explicit comparison.
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 (e.g., combat must be active), exclusions, or related tools like 'start_combat' or 'next_turn' that might be relevant in combat contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the tool returns campaign information but lacks details on permissions, side effects, or error conditions. For a read operation in a game management context, this is a significant gap, though it's not misleading.
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 front-loaded with the core purpose in the first sentence, followed by specifics on return values. Both sentences are relevant, with no wasted words, though it could be slightly more structured (e.g., bullet points for return types).
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 no annotations and no output schema, the description provides basic purpose and return value hints but lacks depth. For a tool in a complex game system, it should clarify what 'current campaign' means or link to context, making it minimally adequate but with clear 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 with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't add parameter details, but with no parameters, a baseline of 4 is appropriate as there's nothing to compensate for.
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: 'Get information about the current campaign' specifies the verb ('Get') and resource ('campaign information'). It distinguishes from siblings like 'list_campaigns' (which lists multiple campaigns) by focusing on the current one, though it doesn't explicitly contrast them.
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 a loaded campaign) or compare to similar tools like 'get_game_state' or 'get_party_status', leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states it 'gets' information (implying read-only) but doesn't disclose permissions needed, rate limits, error conditions, or what 'detailed' means. For a 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 extremely concise with just two sentences that directly state purpose and parameter acceptance. Every word earns its place with zero waste or redundancy. It's appropriately sized for a simple lookup tool.
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?
For a simple read operation with 100% schema coverage but no annotations or output schema, the description is minimally adequate. It states what the tool does but lacks behavioral context, usage guidance, and output information. Given the tool's relative simplicity compared to more complex siblings, it's borderline viable but has clear 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 already documents the single parameter 'name_or_id' with description 'Character name, ID, or player name'. The description adds no additional parameter semantics beyond restating this same information. Baseline 3 is appropriate when 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: 'Get detailed character information' with a specific verb ('Get') and resource ('character information'). It distinguishes from siblings like 'list_characters' (which lists multiple) and 'create_character' (which creates new), but doesn't explicitly differentiate from 'get_campaign_info' or 'get_npc' which have similar 'get' patterns for other resources.
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 when to use 'get_character' versus 'list_characters' (for overview vs details) or 'get_campaign_info' (for campaign vs character data). There are no explicit when/when-not instructions or named alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get NPC information' implies a read-only operation, but it doesn't specify permissions, rate limits, or what happens with invalid inputs. The description is minimal, offering basic intent but lacking details on error handling or output format.
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 'Get NPC information'—a single, front-loaded sentence that wastes no words. It directly states the tool's purpose without unnecessary elaboration, making it efficient for quick comprehension.
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 retrieving NPC data in a game context, with no annotations and no output schema, the description is incomplete. It doesn't explain what information is returned, how NPCs are identified, or handle edge cases. This leaves significant gaps for an AI agent to understand the tool's full behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the two parameters. The description doesn't add any parameter-specific details beyond what's in the schema, but with high coverage, the baseline is 3. Since there are only 2 parameters and the schema is comprehensive, a score of 4 reflects adequate parameter understanding without extra description input.
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 doesn't distinguish this tool from sibling tools like 'list_npcs' or 'get_character', leaving ambiguity about whether this retrieves a single NPC versus a list, or how NPCs differ from 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?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention sibling tools like 'list_npcs' (which might list multiple NPCs) or 'get_character' (which might retrieve player characters), nor does it specify prerequisites or appropriate contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns 'a formatted list' including 'content filters', which adds some context about output format. However, it doesn't cover important aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error conditions. For a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences. The first sentence clearly states the purpose, and the second adds useful detail about the return format. There's no wasted text, and information is front-loaded effectively.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool returns but doesn't provide enough behavioral context (e.g., read-only status, error handling). For a list operation in a campaign management context, more guidance on usage and limitations would be helpful.
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. The description doesn't need to explain parameters, and it doesn't attempt to. Since there are no parameters to document, a baseline of 4 is appropriate—the description correctly focuses on what the tool does rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all library sources enabled for the current campaign.' It specifies the verb ('List'), resource ('library sources'), and scope ('enabled for the current campaign'). However, it doesn't explicitly differentiate from sibling tools like 'list_library' or 'get_library_toc', which prevents 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 usage guidance. It implies usage in the context of a campaign but doesn't specify when to use this tool versus alternatives like 'list_library' or 'get_library_toc'. No exclusions, prerequisites, or explicit alternatives are mentioned, leaving the agent with little contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Returns a list of all locations with their basic information,' which implies a read-only operation but lacks details on permissions, rate limits, pagination, or what 'basic information' includes. For a tool with zero annotation coverage, this is insufficient behavioral disclosure.
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 concise and front-loaded, with two sentences that directly state the purpose and return value. There's no wasted text, though it could be slightly more structured by explicitly noting the lack of parameters or usage context.
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 covers the basic purpose and return type but lacks behavioral details (e.g., permissions, data format) and usage guidelines, leaving gaps for an AI agent to infer correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't add parameter details, which is acceptable given the baseline. It implicitly confirms no parameters are needed by not mentioning any, aligning with 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 tool's purpose: 'List all locations in the current campaign' specifies the verb ('List'), resource ('locations'), and scope ('in the current campaign'). It distinguishes from siblings like 'get_location' (singular) and 'create_location', though it doesn't explicitly differentiate from other list tools like 'list_campaigns' or 'list_npcs'.
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 doesn't mention prerequisites (e.g., needing an active campaign), exclusions, or comparisons to similar tools like 'get_location' for specific location details or 'create_location' for adding new ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the action but lacks behavioral details such as what 'loading' entails (e.g., does it overwrite existing rulebooks, require specific permissions, or affect game state?), potential side effects, or error handling, leaving significant 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, clear sentence with zero waste—it directly states the tool's action and target without unnecessary words, making it highly efficient and front-loaded.
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 moderate complexity (3 parameters, no output schema, no annotations), the description is minimal but functional. It covers the basic purpose but lacks details on behavior, usage context, or output, making it adequate but incomplete for informed tool selection.
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 parameters. The description adds no additional meaning beyond implying a 'rulebook' resource, which aligns with the schema's 'source' parameter. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
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 ('load') and resource ('rulebook into the current campaign'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'unload_rulebook' or 'list_rulebooks', but the verb 'load' implies a distinct operation from those.
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 active campaign), exclusions, or comparisons to sibling tools like 'unload_rulebook' or 'enable_library_source', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('advance to the next turn') but does not disclose behavioral traits such as what happens when advanced (e.g., turn order changes, effects applied), permissions required, or side effects. This is a significant gap 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 is front-loaded and directly states the tool's purpose without unnecessary elaboration, making it 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 the tool's complexity (a mutation in combat with no annotations or output schema), the description is incomplete. It lacks details on behavior, side effects, prerequisites, or return values, which are crucial for an agent to use it correctly in a game state context.
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 no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline for 0 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 action ('advance to the next turn') and the context ('in combat'), which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'combat_action' or 'end_combat', which could be related to combat management.
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 does not mention prerequisites (e.g., whether combat must be active), exclusions, or related tools like 'end_combat' or 'combat_action', 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.
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 explains the healing mechanics but doesn't cover important aspects like whether this consumes resources permanently, requires specific character states (e.g., not in combat), affects other character attributes, or has any side effects. The description is incomplete 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences that directly explain the core functionality and mechanics. No wasted words, though it could potentially be more front-loaded by stating the primary purpose more prominently before the optional mechanics.
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 no annotations and no output schema, the description is insufficient. It explains what the tool does mechanically but doesn't cover important context like what state changes occur, what permissions are needed (beyond the player_id parameter), what the expected outcome is, or how this interacts with other character systems. The description should do more given the complexity.
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 three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but doesn't need to given the comprehensive schema coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Perform a short rest for a character') and resource ('character'), distinguishing it from sibling tools like 'long_rest' by specifying the short rest context. It goes beyond the tool name by explaining the optional hit dice spending mechanic.
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 'long_rest' or other healing/restoration tools in the sibling list. It mentions the optional hit dice spending but doesn't explain when this is appropriate versus other recovery methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action ('Remove') without disclosing behavioral traits like whether this is reversible, requires permissions, affects game state, or has side effects. It lacks details on what 'unload' entails operationally.
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 wasted words, front-loading the key action and resource. It's appropriately sized for a simple tool with one parameter.
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 one parameter with full schema coverage and no output schema, the description is minimally adequate but lacks context on behavior, alternatives, or effects. For a mutation tool with no annotations, it should provide more operational details 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?
Schema description coverage is 100%, so the schema already documents the single parameter 'source_id' with its description. The tool description adds no additional meaning about parameters beyond what the schema provides, meeting the baseline for high coverage.
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 ('Remove') and resource ('a rulebook from the current campaign'), making the purpose evident. It doesn't explicitly differentiate from sibling tools like 'disable_library_source' or 'unload_adventure', but the specificity of 'rulebook' and 'current campaign' provides reasonable distinction.
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 like 'disable_library_source' or 'unload_adventure', nor any prerequisites (e.g., requiring a loaded rulebook first). The description assumes context without stating when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It doesn't disclose if this is a read-only operation, what validation entails (e.g., returns errors, warnings), or any side effects (e.g., logs results). The term 'validate' suggests non-destructive checking, but this isn't explicitly confirmed, leaving gaps 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 action and target, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 moderate complexity (validation operation), lack of annotations, and no output schema, the description is minimally adequate. It states what the tool does but omits details on behavior, output format, or error handling. With schema coverage at 100%, it compensates partially, but more context would improve completeness for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the parameter 'name_or_id'. The description adds no additional meaning beyond implying the parameter identifies a character, which the schema already states. This meets the baseline of 3, as the schema handles parameter semantics adequately.
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 ('validate') and target ('character against loaded rulebooks'), making the purpose understandable. It distinguishes from siblings like 'get_character' or 'update_character' by focusing on validation rather than retrieval or modification. However, it doesn't specify what 'validate' entails (e.g., checking rules compliance, completeness), 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?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies it's for validation after rulebooks are loaded, but it doesn't mention prerequisites (e.g., ensure rulebooks are loaded first) or compare to tools like 'check_sheet_changes' or 'sync_all_sheets'. Usage is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'Returns the full hierarchical table of contents extracted from the PDF or Markdown source, with page numbers and content types,' which adds useful behavioral context about output format. However, it lacks details on permissions, rate limits, error conditions, or whether this is a read-only operation, which is important for a tool interacting with library sources.
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 appropriately sized and front-loaded, with the core purpose stated first. The additional details about return format and parameter guidance are useful but could be slightly more streamlined. There's no wasted text, but it's not perfectly concise.
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 moderate complexity (single parameter, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and the parameter, but without annotations or output schema, it should ideally provide more behavioral context (e.g., read-only nature, error handling). It meets minimum viability but lacks completeness for optimal agent 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 schema fully documenting the single parameter 'source_id'. The description adds minimal value beyond the schema by repeating the parameter explanation and providing an example ('e.g., 'tome-of-heroes'' is in the schema). Since the schema does the heavy lifting, 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.
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: 'Get the table of contents for a specific library source.' It specifies the verb ('Get'), resource ('table of contents'), and scope ('specific library source'). However, it doesn't explicitly differentiate from sibling tools like 'list_library' or 'search_library', which prevents 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning 'use list_library to see available sources' for the source_id parameter. This suggests when to use this tool (after identifying sources via list_library), but it doesn't explicitly state when to choose this tool over alternatives like 'extract_content' or 'search_library', nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'Get' operation which implies read-only behavior, but doesn't explicitly confirm this is non-destructive or safe. It mentions what information is returned but doesn't describe format, potential errors, rate limits, authentication requirements, or whether this requires Party Mode to be active. The description adds some context about what's included in the status but lacks comprehensive behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured. The first sentence clearly states the core purpose, and the second sentence efficiently elaborates on what information is returned. Both sentences earn their place by providing essential information without redundancy or unnecessary elaboration.
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 simplicity (0 parameters, no annotations, no output schema), the description is adequate but has clear gaps. It explains what the tool does and what information it returns, which is good for a status-checking tool. However, without annotations or output schema, it should ideally provide more behavioral context about authentication, error conditions, or format of returned data to be fully complete for agent 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 0 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. It focuses instead on what the tool returns, which is valuable context given the lack of output schema. This meets the baseline expectation for zero-parameter tools.
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: 'Get the current status of the Party Mode server' with specific details about what information is returned ('Shows server info, connected players, and action queue stats'). It distinguishes itself from siblings by focusing on Party Mode server status rather than character, campaign, or library operations. However, it doesn't explicitly differentiate from similar status-checking tools like 'get_game_state' or 'get_claudmaster_session_state'.
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. While it mentions 'Party Mode server' context, it doesn't explain when this status check is needed versus other state-checking tools like 'get_game_state' or 'get_claudmaster_session_state'. There are no prerequisites, exclusions, or comparison to sibling tools provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it lists 'all available campaigns' but doesn't clarify what 'available' means, whether there are permissions or filters, or what format the output takes. This leaves significant gaps for a tool that presumably returns data.
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 tool.
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?
For a zero-parameter tool with no output schema, the description is minimally adequate but lacks important context. It doesn't explain what 'available' means, whether the list is filtered or paginated, or what the output structure looks like. Given the complexity of sibling tools in this server, more detail would be helpful.
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 the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly implies no parameters are required by not mentioning any.
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 ('campaigns'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_campaign_info' or 'load_campaign', which might also retrieve campaign information in different ways.
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 'get_campaign_info' or 'load_campaign'. It simply states what it does without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists NPCs and returns basic information, but lacks details on permissions, rate limits, pagination, or error handling. For a read operation 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 front-loaded and efficient: two sentences with zero waste. The first sentence states the action and scope, and the second clarifies the return value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and return type, but lacks context on campaign selection, data format, or limitations, which could be helpful for an agent.
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 (empty schema). The description doesn't need to add parameter details, so it meets the baseline. It implicitly confirms no parameters are required by not mentioning any, which 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: 'List all NPCs in the current campaign' specifies the verb ('List') and resource ('NPCs'), and 'Returns a list of all non-player characters with their basic information' elaborates on the output. However, it doesn't explicitly differentiate from sibling tools like 'get_npc' or 'create_npc', which would require a 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 minimal guidance: it implies usage for retrieving NPCs in the current campaign but doesn't specify when to use this tool versus alternatives like 'get_npc' (for a single NPC) or 'create_npc' (for adding new NPCs). No explicit when/when-not instructions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'active rulebooks' and 'current campaign', which adds some context, but fails to disclose critical behavioral traits such as whether this is a read-only operation, what format the output takes (e.g., list, pagination), or any permissions required. The description is minimal and lacks operational details.
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 is front-loaded with the core action ('List all active rulebooks') and efficiently specifies the context ('in the current campaign'), making it easy to parse and understand quickly.
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 simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the basic purpose and scope but lacks details on output format, behavioral traits, or usage guidelines. For a read operation in a campaign context, more context on what 'active' means or how results are structured would enhance completeness.
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 appropriately doesn't discuss parameters, and the baseline for 0 parameters is 4, as it avoids unnecessary detail while matching the schema's completeness.
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 all active rulebooks') and the resource ('in the current campaign'), providing a specific verb+resource combination. It distinguishes from siblings like 'load_rulebook' or 'unload_rulebook' by focusing on listing rather than loading/unloading, though it doesn't explicitly contrast with them.
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 'search_rules' or 'get_library_toc', nor does it mention prerequisites (e.g., needing an active campaign). It only states the scope ('in the current campaign') without explicit usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the search is 'case-insensitive' and provides default values, which adds useful context. However, it doesn't disclose other behavioral traits like pagination, error handling, permissions needed, or what the return format looks like (especially important with no output schema).
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 well-structured with a brief overview followed by parameter details. It's appropriately sized with no redundant information, though the parameter section slightly repeats schema content. Every sentence adds value, making it efficient and front-loaded.
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 3 parameters with 100% schema coverage but no annotations and no output schema, the description is adequate but has gaps. It covers the basic purpose and parameters but lacks details on behavioral aspects (e.g., result format, error cases) and doesn't fully compensate for the missing output schema, leaving uncertainty about what the tool returns.
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 minimal value beyond the schema: it repeats that 'query' searches titles and is case-insensitive, and mentions defaults, but doesn't provide additional syntax, format details, or examples. Baseline 3 is appropriate when 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 searches 'across all indexed library content' and specifies it searches 'TOC entries by title across all indexed PDF and Markdown sources.' This provides a specific verb (search) and resource (library content/TOC entries), though it doesn't explicitly differentiate from sibling tools like 'search_rules' or 'get_library_toc' beyond mentioning content type filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching library content by title with content type filtering, but doesn't explicitly state when to use this tool versus alternatives like 'search_rules' or 'get_library_toc.' It provides some context (searching titles, filtering by content type) but lacks explicit when/when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the quantity-based removal logic (partial vs. full removal), which is useful, but fails to address critical aspects like permission requirements (implied by the 'player_id' parameter), error conditions, or whether the action is reversible. For a mutation tool, this leaves significant 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 and well-structured, with two sentences that efficiently convey the core functionality and quantity logic. Every sentence earns its place, and there is no wasted verbiage or redundancy.
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 moderate complexity (mutation with 4 parameters) and lack of annotations or output schema, the description is incomplete. It covers the basic operation but omits details on permissions, error handling, and return values. However, the high schema coverage partially compensates, making it minimally adequate but with clear 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 already documents all parameters thoroughly. The description adds minimal value by clarifying the 'quantity' behavior (default removal logic), but does not provide additional semantic context beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Remove') and resource ('item from a character's inventory'), distinguishing it from sibling tools like 'add_item_to_character' or 'unequip_item'. It precisely defines the action without being tautological.
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 'unequip_item' or 'remove_effect', nor does it mention prerequisites or contextual constraints. It lacks explicit usage instructions beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what the tool returns ('most recent changelog entries') but lacks details on behavioral traits like rate limits, authentication needs, error handling, or data format. This is inadequate for a tool with no annotation coverage, though it does specify the source ('GitHub repository').
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 front-loaded with the core action and resource, followed by additional context in a second sentence. Both sentences earn their place by specifying what's fetched and why, with zero waste or repetition, making it highly efficient.
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 complete. It explains what the tool does and its purpose but lacks behavioral details (e.g., response format, errors). This is adequate for a simple fetch tool but leaves gaps in 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's function. A baseline of 4 is applied since it avoids redundancy and adds value through purpose clarification.
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 ('Fetch', 'Returns') and resource ('latest release notes from the CHANGELOG', 'changelog entries from the GitHub repository'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_for_updates', which might have overlapping functionality, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to show users what's new'), suggesting when to use this tool. However, it lacks explicit guidance on when not to use it or alternatives (e.g., compared to 'check_for_updates'), leaving some ambiguity for the agent in selecting among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns 'a list of all player characters with their basic information,' which clarifies it's a read operation and hints at the output format. However, it lacks details on permissions, rate limits, or whether it includes inactive characters, which are important for a tool in a campaign management 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 two sentences that are front-loaded and waste no words. The first sentence states the core action, and the second adds useful context about the return value. Every part earns its place, making it highly efficient.
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 covers the purpose and output, but as a read operation in a campaign system, it could benefit from more behavioral context (e.g., access controls or data freshness). Without annotations, it leaves some gaps for an agent to infer.
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 parameter details, which is appropriate. A baseline of 4 is applied since it doesn't need to compensate for any gaps, and it correctly avoids redundancy.
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: 'List all characters in the current campaign.' It specifies the verb ('List') and resource ('characters'), and adds context about scope ('in the current campaign'). However, it doesn't explicitly differentiate from sibling tools like 'get_character' or 'bulk_update_characters', which prevents 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'current campaign,' suggesting it should be used when you want a comprehensive list of player characters in that context. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_character' for individual details or 'list_npcs' for non-player characters, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behavioral context: messages are stored in a session coordinator, retrievable by the recipient, and only visible to the specified recipient. However, it does not cover aspects like error handling, permissions beyond DM usage, or whether the operation is idempotent or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences that are front-loaded (purpose first) and avoid redundancy. Each sentence adds value: the first states the purpose, the second explains storage and retrieval, and the third clarifies visibility. No wasted words, but minor room for tighter phrasing.
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 no annotations and no output schema, the description provides basic context but lacks details on return values, error cases, or system behavior. It covers storage and visibility adequately for a simple messaging tool, but does not address potential complexities like message limits or confirmation of delivery.
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 (player_id, content, sender_id) with descriptions. The description does not add any additional meaning or syntax details beyond what the schema provides, such as format constraints or examples, meeting the baseline for high coverage.
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: 'DM can send private messages to individual players via this tool.' It specifies the verb ('send'), resource ('private messages'), and actor ('DM'), but does not explicitly differentiate it from potential sibling messaging tools (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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'DM' and 'players,' suggesting it's for private communication in a game session. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., public messaging or other communication methods) or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that SRD conditions use 'standard condition templates' and custom effects create 'new ActiveEffect with provided modifiers', but it doesn't clarify critical behaviors like whether this is a mutating operation, what permissions are required, how conflicts with existing effects are handled, or what the response looks like. For a tool that modifies character state, this leaves significant gaps in understanding its 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 efficiently structured in three sentences: a clear purpose statement, SRD condition details with examples, and custom effect explanation. Every sentence earns its place by providing essential information without redundancy. The SRD condition list is appropriately formatted for quick scanning.
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 complexity (applying effects to characters), lack of annotations, and no output schema, the description provides adequate basic information but has significant gaps. It explains what the tool does but doesn't cover behavioral aspects like mutation consequences, error conditions, or response format. For a state-modifying tool with 5 parameters, more contextual information would be helpful despite the good schema coverage.
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 5 parameters thoroughly. The description adds minimal value beyond the schema by mentioning SRD condition examples and the concept of custom modifiers, but doesn't provide additional syntax, format details, or usage examples that aren't already in the parameter descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Apply an ActiveEffect') and target ('to a character'), distinguishing it from sibling tools like 'remove_effect' or 'update_character'. It explicitly defines two distinct use cases: applying SRD conditions and creating custom effects, providing precise verb+resource+scope differentiation.
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 when to use this tool by listing SRD conditions and mentioning custom effects, but it doesn't provide explicit guidance on when to choose this over alternatives like 'update_character' for stat changes or 'remove_effect' for reversing effects. No prerequisites or exclusions are stated, leaving usage context somewhat implied rather than explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions scanning and returning data, but lacks details on permissions needed, whether it's read-only, potential errors (e.g., if directory is missing), or how results are structured (e.g., pagination, sorting). This is a significant gap 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 front-loaded with the main purpose in the first sentence, followed by a clarifying second sentence that adds useful detail without redundancy. Both sentences earn their place by explaining what the tool does and what it returns.
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 adequate but incomplete. It explains the action and output types but misses behavioral context like error handling or performance considerations. This is the minimum viable for a simple read 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 with 100% schema description coverage, so the schema fully documents the inputs. The description appropriately does not add parameter details, maintaining focus on the tool's purpose and output. A baseline of 4 is applied since no parameters are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('all available compendium packs in the packs directory'), and distinguishes it from siblings like 'list_campaigns' or 'list_characters' by specifying packs. It explains what it scans for and what information it returns.
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 does not mention any prerequisites, such as whether packs must be imported first, or compare it to similar tools like 'list_library' or 'scan_library' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the basic outcome (moves item to inventory, clears slot) but omits critical details like permission requirements (implied by 'player_id' parameter), whether the action is reversible, error conditions, or side effects on character stats.
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 front-loaded with the core purpose in the first sentence, followed by a clarifying second sentence. Both sentences earn their place by adding value—no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimally adequate. It covers the basic operation but lacks details on permissions, error handling, or return values. Given the complexity (state change with 3 parameters), it should provide more behavioral context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain slot constraints or character identification nuances). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('unequip an item'), the resource ('equipment slot'), and the outcome ('moves the equipped item back to the character's inventory and clears the slot'). It distinguishes itself from sibling tools like 'equip_item' by describing the reverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when moving an item from equipment to inventory, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'remove_item' for deleting items). It mentions a sibling tool 'equip_item' by context but doesn't provide direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. While 'regenerate' implies a write operation, it doesn't disclose critical behavioral traits like whether this is destructive (e.g., overwrites customizations), requires specific permissions, has rate limits, or what the output looks like. The description adds minimal context beyond the basic 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 perfectly concise with two sentences: the first states the purpose, the second provides usage context. Every word earns its place with zero redundancy, and it's front-loaded with the core action.
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?
For a mutation tool with no annotations and no output schema, the description is adequate but incomplete. It explains what the tool does and when to use it, but lacks details about behavioral implications (destructiveness, permissions, response format) that would help an agent understand the full impact of 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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description appropriately doesn't waste space explaining parameters, maintaining focus on the tool's purpose and usage.
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 ('regenerate all character sheets') and resource ('for the current campaign'), providing a specific purpose. It distinguishes from siblings by focusing on bulk regeneration rather than individual sheet operations like 'update_character' or 'validate_character_rules', though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('after bulk changes or to ensure all sheets are up to date'), which helps differentiate it from incremental updates. However, it doesn't explicitly state when not to use it or name specific alternative tools for partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key behaviors: automatically applies damage to HP, triggers concentration checks, returns formatted outcomes, and is additive to manual workflows. However, it lacks details on error conditions, side effects on game state, or performance characteristics like rate limits. The description doesn't contradict any annotations since none exist.
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 efficiently structured in three sentences with zero waste. The first sentence states the core purpose, the second details supported action types and automatic behaviors, and the third clarifies the additive nature relative to other workflows. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a combat resolution tool with 9 parameters and no output schema, the description provides adequate but incomplete context. It covers the purpose, supported action types, and key behaviors, but lacks details about return values, error handling, or how it integrates with the broader combat system. Without annotations or output schema, more behavioral context would be 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?
Schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions support for weapon attacks and saving throw spells which aligns with 'action_type', and implies some parameter usage context. With high schema coverage, the baseline is 3 even with limited 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 tool's purpose: 'Resolve a combat action via the pipeline, apply results, and return a formatted outcome.' It specifies support for weapon attacks and saving throw spells, and mentions automatic application of damage, concentration checks, and outcome reporting. However, it doesn't explicitly differentiate from sibling tools like 'roll_dice' beyond stating it's additive rather than a replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for resolving combat actions involving weapon attacks or saving throw spells. It explicitly mentions it's additive and doesn't replace 'roll_dice' workflows, giving some guidance on alternatives. However, it doesn't specify when NOT to use it or compare it to other combat-related siblings like 'apply_effect' or 'next_turn'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the rulebook priority behavior (global vs. campaign), which is valuable context. However, it doesn't describe what 'full class definition' includes, potential errors (e.g., if class not found), or performance characteristics like response format or limitations.
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 only two sentences, both of which add clear value. The first sentence states the purpose, and the second provides important contextual behavior. There is no wasted language or redundancy.
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 moderate complexity (retrieving structured data with two parameters) and no annotations or output schema, the description is adequate but has gaps. It explains the rulebook priority context well, but doesn't cover what the output looks like, error conditions, or limitations of the 'full class definition'—information an agent would need 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?
Schema description coverage is 100%, so the schema fully documents both parameters (name and level). The description doesn't add any parameter-specific information beyond what's in the schema, such as clarifying what 'full class definition' means in relation to the level parameter. This meets the baseline for high schema coverage.
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 ('Get full class definition') and resource ('from loaded rulebooks'), making the purpose understandable. It distinguishes this from other tools by focusing on class information retrieval, though it doesn't explicitly differentiate from similar tools like get_race_info or get_spell_info 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use it ('Works without a campaign loaded' and 'When a campaign is active, its rulebook manager takes priority'), which helps the agent understand the operational context. However, it doesn't mention when NOT to use it or name specific alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful context about rulebook manager priority, which isn't obvious from the schema. However, it lacks details on potential errors (e.g., if the spell isn't found), response format, or any rate limits or permissions needed, leaving 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 front-loaded with the core purpose in the first sentence, followed by contextual details. Both sentences are necessary and add value without redundancy. It's efficiently structured and appropriately sized for the tool's complexity.
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?
For a read-only tool with one parameter and no output schema, the description covers the basic purpose and usage context adequately. However, without annotations or output schema, it lacks details on return values, error handling, or dependencies, making it incomplete for full agent understanding.
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 'name' parameter well-documented. The description doesn't add any parameter-specific information beyond what the schema provides, such as examples or constraints. Given the high schema coverage, a 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.
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: 'Get spell details from loaded rulebooks.' It specifies the verb ('Get') and resource ('spell details'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_class_info' or 'get_monster_info', which follow a similar pattern, so it doesn't fully distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it: 'Works without a campaign loaded (uses global rulebook manager). When a campaign is active, its rulebook manager takes priority.' This explains the tool's behavior in different scenarios. However, it doesn't mention alternatives or exclusions, such as when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the positive effects (resets, restores, clears) but does not disclose behavioral traits like whether this consumes resources (e.g., time in-game), requires specific conditions (e.g., safe location), has side effects (e.g., removes temporary buffs), or permission requirements (implied by the player_id parameter but not explained). The description is functional but lacks operational 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 front-loaded with the core purpose in the first sentence, followed by a bullet-like list of effects in a single, efficient sentence. Every phrase adds value without redundancy, and it avoids unnecessary elaboration, 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.
Completeness3/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 adequately covers the tool's purpose and effects but lacks details on behavioral context (e.g., prerequisites, side effects) and return values. For a mutation tool with three parameters, it provides a solid foundation but leaves gaps in operational understanding, making it minimally complete but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds value by explaining the 'restore_hp' parameter's effect ('optionally restores HP to maximum'), which complements the schema's technical description. However, it does not elaborate on the other parameters beyond what the schema provides, keeping it at a strong but not perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Perform a long rest') and the target ('for a character'), then enumerates the concrete effects: resets spell slots, restores hit dice, clears death saves, and optionally restores HP. It distinguishes itself from the sibling 'short_rest' by specifying the longer duration and more comprehensive recovery effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a character needs full recovery (spell slots, hit dice, death saves, HP), but does not explicitly state when to choose this over 'short_rest' or other recovery tools. It mentions the optional HP restoration parameter, which hints at usage flexibility, but lacks explicit guidance on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool accesses rulebooks and prioritizes campaign rulebooks, which adds useful behavioral context. However, it doesn't mention potential errors (e.g., if the monster isn't found), rate limits, or authentication needs, leaving gaps 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 extremely concise and well-structured, with two sentences that directly address purpose and usage context. Every word contributes meaning, and it's front-loaded with the core function, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is reasonably complete. It explains what the tool does and when to use it, but lacks details on output format or error handling, which could be helpful for an agent invoking it.
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 'name' parameter clearly documented. The description doesn't add any additional semantic details about the parameter beyond what the schema provides, so it meets the baseline for high schema coverage without extra value.
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 ('Get monster stat block') and resource ('from loaded rulebooks'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_character' or 'get_spell_info' beyond the resource type, which prevents 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use it ('Works without a campaign loaded' and 'When a campaign is active, its rulebook manager takes priority'), which helps the agent understand the tool's operational scope. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient for effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It adds useful behavioral context about rulebook manager priority and campaign state dependencies, but lacks details on permissions, error handling, or return format. This is adequate but has clear gaps for a read operation.
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 two sentences that are front-loaded and zero waste. Every sentence adds value: the first states the purpose, the second provides crucial behavioral context about campaign state.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no annotations and no output schema, the description is reasonably complete. It covers purpose, usage context, and behavioral nuances, though it could benefit from mentioning return format or error cases to be fully comprehensive.
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 the single 'name' parameter. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or validation rules, meeting the baseline for high schema coverage.
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 ('Get full race definition') and resource ('from loaded rulebooks'), providing specific purpose. However, it doesn't explicitly differentiate from sibling tools like 'get_class_info' or 'get_monster_info' beyond the resource type, which prevents 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when it works ('without a campaign loaded' and 'when a campaign is active'), explaining priority rules. However, it doesn't explicitly state when to use alternatives or exclusions, such as compared to 'search_rules' or 'list_rulebooks', which would be needed for a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the source format constraint and provides practical guidance on obtaining the JSON file, which adds useful context. However, it doesn't describe what happens after import (e.g., whether the character becomes active, if validation occurs, or what errors might occur), leaving some behavioral aspects unclear.
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 appropriately sized with three sentences that each serve a purpose: stating the tool's purpose, specifying the supported format, and providing practical file acquisition guidance. It's front-loaded with the core functionality. One minor improvement could be combining the format and file guidance into a single more concise sentence.
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?
For a tool with 3 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate context about what the tool does and how to prepare input. However, it lacks information about what happens after successful import (output/result) and doesn't mention potential errors or limitations beyond format support, leaving some contextual 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 already fully documents all three parameters. The description mentions 'D&D Beyond JSON format' which aligns with the source_format parameter's default value, but doesn't add significant semantic meaning beyond what the schema provides. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Import a character from a local JSON file') and the target resource ('into the current campaign'). It distinguishes from sibling tools like 'import_from_dndbeyond' by specifying it works with local files rather than direct D&D Beyond imports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Import a character from a local JSON file into the current campaign') and specifies the supported format ('Currently supports D&D Beyond JSON format'). However, it doesn't explicitly mention when NOT to use it or name alternatives like 'import_from_dndbeyond' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it increments level, calculates HP, adds features, updates spell slots, handles ASI, manages subclass selection, and supports multiclassing. However, it lacks details on permissions (player_id hint), error handling, or what the tool returns, leaving gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action. Sentences earn their place by explaining multiclass behavior and prerequisites, but could be slightly more structured (e.g., bullet points for clarity). No wasted words, but minor room for improvement in organization.
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 complexity (7 parameters, mutation tool) and no annotations or output schema, the description is moderately complete. It covers the main actions and multiclass logic, but lacks details on return values, error cases, or interaction with other tools (e.g., 'update_character'). Adequate for basic understanding but with clear gaps for full agent guidance.
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 minimal semantics beyond the schema, mentioning multiclass behavior for 'class_name' and rulebook requirement, but does not provide additional context for parameters like 'asi_choices' or 'new_spells'. Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Level up a character by one level') and resource ('character'), distinguishing it from siblings like 'create_character' or 'update_character'. It elaborates on what the level-up entails (HP increase, class features, etc.), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for leveling up characters, with a rulebook loaded. It distinguishes between single-class and multiclass scenarios, but does not explicitly state when not to use it or name alternatives among siblings (e.g., 'update_character' might be a related tool).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral consequences: it details the three-step effect (disconnects WebSocket, revokes token, deactivates in registry) and the rejoin requirement. This goes beyond the basic 'kick' action to explain system-level impacts.
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?
Perfectly front-loaded with the core action in the first sentence, followed by consequential details in a logical flow. Every sentence earns its place by explaining what happens after the kick. No wasted words while maintaining complete clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description provides strong behavioral context about the irreversible effects. It could be more complete by mentioning error conditions or confirming successful kick, but it covers the essential consequences well given the tool's complexity.
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 one parameter clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (player_name as 'Player name or character ID to kick'), so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Kick') and target ('a player from the Party Mode session'), distinguishing it from sibling tools like 'stop_party_mode' (ends entire session) or 'remove_item' (different resource). It provides a precise verb+resource combination with clear 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 about when to use this tool versus alternatives. While the description implies it's for Party Mode sessions, it doesn't mention prerequisites (e.g., must be in Party Mode), exclusions, or what happens if the player isn't in the session. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the scanning process, file types processed, and what gets indexed (table of contents), but doesn't mention potential side effects like system load, file locking, or error handling. It adequately covers the main behavior but lacks operational details that would be helpful for an agent.
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 well-structured with three focused sentences: the core action, detailed process explanation, and return value. Each sentence adds distinct value without redundancy. While efficient, the second sentence could be slightly more concise by combining the directory and file type information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description provides adequate coverage of what the tool does and what it returns. However, it doesn't explain the format of the returned summary or potential error conditions. Given the tool's moderate complexity (file scanning and indexing), additional operational context would improve completeness.
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 operation and output. This meets the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('scan', 'extracts', 'saves') and resources ('library folder', 'PDF/Markdown files', 'indexes'). It distinguishes itself from sibling tools like 'search_library' or 'get_library_toc' by focusing on scanning and indexing new/modified files rather than querying existing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when new or modified PDF/Markdown files need indexing, but doesn't explicitly state when to use this tool versus alternatives like 'search_library' or 'get_library_toc'. No explicit exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool launches a background HTTP server, generates authentication tokens and QR codes, and returns connection URLs and file paths. However, it misses details like whether this requires specific permissions, if it affects other server processes, or potential rate limits. No contradiction with annotations exists.
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 appropriately sized with three sentences that are front-loaded: the first states the core action, the second elaborates on functionality, and the third specifies returns. Each sentence adds value without redundancy, though minor trimming could improve flow.
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 complexity (launching a server with multi-player features) and lack of annotations and output schema, the description is moderately complete. It covers what the tool does and what it returns, but gaps remain in behavioral details like error handling, server lifecycle, or integration with other tools like 'stop_party_mode'. More context would enhance completeness.
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 1 parameter with 100% coverage, providing a default and description. The description does not add any parameter-specific information beyond the schema, but since there are zero required parameters and high schema coverage, the baseline is elevated. The description's focus on server functionality indirectly complements the port parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start the Party Mode web server') and the resource ('for multi-player sessions'). It distinguishes itself from siblings like 'stop_party_mode' by indicating it launches a server rather than stopping one, and from other session-related tools by focusing on player connectivity rather than game mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when multi-player sessions are needed, as it mentions 'allows multiple players to connect.' However, it lacks explicit guidance on when to use this tool versus alternatives like 'start_claudmaster_session' or prerequisites such as requiring an active campaign. No exclusions or clear alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the calculation method ('D&D 5e encounter building rules'), output type ('encounter suggestions with monster compositions'), and a conditional behavior ('when rulebooks are loaded, suggests specific monsters'). However, it doesn't mention whether this is a read-only operation, what format the suggestions take, or any limitations like rate limits or authentication requirements.
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 perfectly concise with three sentences that each earn their place: first states the core function, second explains the calculation method, third adds important conditional behavior. No wasted words, and the most important information (what the tool does) is front-loaded.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description provides adequate but incomplete coverage. It explains what the tool does and how parameters relate, but doesn't describe the output format, error conditions, or behavioral constraints. Given the complexity of encounter building and the lack of structured output documentation, more detail about what 'suggestions' include would be helpful.
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 schema description coverage is 100%, so parameters are well-documented in the schema. The description adds value by explaining the overall purpose of the parameters ('based on party size, level, and difficulty') and mentioning the optional filters ('creature type', 'environment') in the context of monster suggestions. It doesn't provide additional syntax details beyond what's in the schema, but gives meaningful context for how parameters work together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('return encounter suggestions', 'calculate XP budgets', 'suggest balanced encounters') and resources ('monster compositions', 'D&D 5e encounter building rules'). It distinguishes itself from sibling tools by focusing specifically on encounter building rather than character management, combat actions, or other campaign operations.
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 when to use this tool (when building encounters for D&D 5e) and mentions that it 'suggests specific monsters' when rulebooks are loaded, which provides some context about prerequisites. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for related functions like calculating experience or getting monster info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that the operation is irreversible and destructive ('permanently,' 'cannot be undone'), which is critical for a deletion tool. However, it does not mention potential side effects, permissions required, or error conditions, leaving some behavioral aspects uncovered.
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 and front-loaded, consisting of two short sentences that convey the essential information without any wasted words. It directly addresses the tool's core functionality and critical warning, making it 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?
For a destructive tool with no annotations and no output schema, the description provides basic but incomplete context. It covers the irreversible nature of the action but lacks details on success/failure responses, error handling, or integration with sibling tools like 'list_campaigns.' Given the tool's complexity and missing structured data, more comprehensive guidance would improve completeness.
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 parameter 'name' clearly documented as 'Campaign name to delete.' The description does not add any additional semantic context beyond this, such as format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a campaign'), with the adverb 'permanently' emphasizing the nature of the operation. It distinguishes itself from siblings like 'list_campaigns' or 'get_campaign_info' by specifying a destructive write action, making the purpose explicit and unambiguous.
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 context through 'permanently' and 'cannot be undone,' suggesting caution, but does not explicitly state when to use this tool versus alternatives like 'delete_character' or prerequisites. It lacks direct guidance on scenarios or comparisons with sibling tools, leaving usage somewhat inferred rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the effect ('removes a library source', 'will no longer be available'), but lacks details on permissions required, whether the action is reversible, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant 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 front-loaded with the core purpose, followed by clear explanations of effects and parameter usage. Every sentence adds value without redundancy, and the structure is efficient with zero waste.
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 complexity (a mutation with no annotations or output schema), the description covers the basic purpose and parameter semantics adequately but lacks behavioral details like error handling or confirmation of success. It is minimally viable but has clear gaps in 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?
The schema description coverage is 100%, so the schema already documents the single parameter 'source_id'. The description adds value by explaining what 'source_id' represents and referencing 'list_enabled_library' to obtain valid values, providing practical guidance beyond the schema's basic definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Disable'), resource ('a library source'), and context ('for the current campaign'), distinguishing it from siblings like 'enable_library_source' and 'list_enabled_library'. It precisely explains what the tool does without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to remove a library source from a campaign's enabled content) and references 'list_enabled_library' as a prerequisite for obtaining source identifiers. However, it does not explicitly state when not to use it or compare it to alternatives like 'unload_rulebook' or 'delete_campaign'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool generates a file in a specific directory ('campaign's sheets/ directory') and mentions output format details (Markdown with YAML frontmatter, Obsidian compatibility). However, it omits critical behavioral traits like whether this is a read-only operation, if it requires specific permissions, or how errors are handled, which are important for a file-export 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 front-loaded with the core action in the first sentence, followed by additional useful details about the output. Every sentence earns its place by explaining the file format, location, and viewing options without redundancy. It is appropriately sized for the tool's complexity.
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 no annotations and no output schema, the description provides adequate context for a simple export tool—it explains what the tool does and the output format. However, it lacks details on behavioral aspects (e.g., error handling, file naming conventions) and does not fully compensate for the absence of structured metadata, leaving some gaps in understanding the tool's 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?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds no explicit parameter information, but since the tool has only 2 parameters and the schema is fully described, this is acceptable. The baseline score of 3 is exceeded because the description implicitly clarifies the purpose of 'name_or_id' (used to identify the character) and 'player_id' (related to permissions), adding slight contextual value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export a character to a Markdown sheet file') and resource ('character'), distinguishing it from siblings like 'get_character' (which retrieves data) or 'import_character_file' (which imports). It provides additional detail about the output format and location, making the purpose unambiguous.
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?
Usage is implied through context—it exports a character sheet, suggesting use when a formatted, viewable record is needed. However, it lacks explicit guidance on when to choose this over alternatives like 'get_character' (for raw data) or 'sync_all_sheets' (for batch updates). No exclusions or prerequisites are stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it extracts content, saves it to a specific directory ('library/extracted/{source_id}/') in a JSON format, and indicates it's for the rulebook system. However, it lacks details on permissions, error handling, or whether the operation is idempotent, which are important for a tool that writes files.
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 well-structured with a clear purpose statement, examples, and a returns section, making it easy to scan. However, the 'Args' section slightly repeats schema information, and some sentences could be more streamlined (e.g., combining the extraction and saving details). Overall, it's efficient but not perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does a good job covering the tool's purpose, usage, and behavioral aspects like file output. It includes examples and return information, but lacks details on error cases or system dependencies, leaving minor gaps for a tool with file operations.
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 minimal value beyond the schema, only reiterating parameter purposes in the 'Args' section without providing additional context like format constraints or interdependencies. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract content from a PDF source and save as CustomSource JSON') and resource ('PDF source'), distinguishing it from sibling tools like 'search_library' or 'get_library_toc' by focusing on extraction and file creation rather than querying or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (e.g., extracting content based on table of contents entries) and includes examples that illustrate typical use cases. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'search_library' for finding content without extraction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this tool 'broadcast[s] the response to connected players' and 'push[es] the response to the WebSocket broadcast queue,' which are important behavioral traits. However, it doesn't mention potential side effects, error conditions, or what happens if the action_id is invalid.
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 perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides essential usage context. There's zero wasted language.
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?
For a tool with no annotations and no output schema, the description provides adequate but minimal context. It explains what the tool does and when to use it, but doesn't describe the response format, error conditions, or what happens after broadcasting. Given the 4 parameters and mutation nature, more behavioral detail would be 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Resolve') and resource ('player action'), and distinguishes it from siblings by explaining it's for broadcasting responses after processing actions. It explicitly mentions its relationship with 'party_pop_action' as a follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool: 'After processing a player action (rolling dice, narrating outcome, updating state), call this tool to push the response to the WebSocket broadcast queue.' It doesn't explicitly state when NOT to use it or name specific alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing critical behavioral outcomes: stabilization at 3 successes (HP set to 1, resets) and death at 3 failures. It doesn't mention permission requirements (though player_id parameter hints at this), rate limits, or error conditions, but covers the core mutation behavior adequately.
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?
Perfectly concise with three sentences that each earn their place: states the action, explains tracking mechanics, and discloses the two critical outcomes. No wasted words, and the most important information (stabilization/death conditions) is front-loaded in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good contextual completeness by explaining the core behavioral outcomes. It could be more complete by mentioning what happens on intermediate saves (1-2 successes/failures) or clarifying if this tool can be used when character isn't at 0 HP, but covers the essential mechanics well.
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 three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline for high schema coverage without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Record a death saving throw result') and resource (death saving throw tracking system). It distinguishes this tool from siblings by focusing exclusively on death save mechanics, unlike tools for items, spells, events, or general 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the stabilization/death mechanics explanation, suggesting it should be used when tracking death save outcomes in D&D-style gameplay. However, it doesn't explicitly state when to use this versus alternatives (like general character updates) or mention prerequisites like character being at 0 HP.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It effectively discloses key behavioral traits: the outcomes of approval (changes applied to character's JSON data) and rejection (sheet regenerated from server data, overwriting edits). This covers mutation effects and data handling, though it lacks details on permissions or error cases.
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 front-loaded with the core purpose in the first sentence, followed by two concise sentences explaining outcomes. Every sentence earns its place by clarifying behavior without redundancy, making it appropriately sized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with significant side effects), no annotations, and no output schema, the description does well by explaining the two possible outcomes. However, it could be more complete by addressing error handling, permissions, or what 'pending player edits' entails, leaving minor 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 already documents both parameters ('character_name' and 'approve'). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Approve or reject pending player edits from a character sheet.' It specifies the verb ('approve or reject'), resource ('pending player edits'), and scope ('character sheet'), distinguishing it from siblings like 'update_character' or 'check_sheet_changes'.
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 context by mentioning 'pending player edits,' suggesting it should be used after changes are detected. However, it does not explicitly state when to use this tool versus alternatives like 'update_character' or 'check_sheet_changes,' nor does it provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds context about parameter behaviors (e.g., rules_version options, interaction_mode details), but does not disclose broader traits like permissions needed, rate limits, or what happens on success/failure. The description is informative but lacks operational 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 well-structured and front-loaded with the core purpose. Each sentence adds value: the first states the action, and subsequent sentences clarify parameter nuances without waste. It is appropriately sized for a tool with multiple parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description does a good job explaining key parameters and their implications. However, it lacks information on return values or error handling, which would be helpful since there's no output schema. It's mostly complete but has minor 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?
Schema description coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the significance of 'rules_version' (edition differences) and detailing the 'interaction_mode' options with clear examples. This enhances understanding without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new D&D campaign.' It specifies the exact action (create) and resource (campaign), and distinguishes it from siblings like 'list_campaigns' or 'delete_campaign' by focusing on creation rather than listing or deletion.
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 provides implied usage by explaining the parameters (rules_version and interaction_mode), but it does not explicitly state when to use this tool versus alternatives. No prerequisites, exclusions, or comparisons to similar tools (e.g., 'load_campaign') are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is an 'enable' operation (implying a write/mutation), but doesn't mention permissions needed, whether changes are reversible, or what happens if the source is already enabled. The examples add practical context but don't cover behavioral traits like error conditions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured: a clear opening statement of purpose, followed by concise explanation of filtering options, then practical examples showing increasing specificity. Every sentence earns its place, with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description does well by explaining the operation, parameters, and providing examples. However, it doesn't describe what the tool returns (success/failure indicators, confirmation messages, or error formats), which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value through examples showing how parameters interact (e.g., content_names only used with content_type), but doesn't provide additional semantic meaning beyond what's in the schema descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Enable') and resource ('library source for the current campaign'), and distinguishes it from its sibling 'disable_library_source'. It explains what the tool does: adds a library source to the campaign's enabled content, with optional filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to enable library sources in a campaign) and includes examples showing different usage scenarios. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'disable_library_source' for disabling sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it's a mutation tool (moves items), handles slot conflicts by automatically unequipping existing items, and implies state changes in inventory and equipment slots. It doesn't cover error cases, permissions, or response format, but provides essential operational 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 perfectly sized and front-loaded: the first sentence states the core purpose, and subsequent sentences add crucial behavioral details without redundancy. Every sentence earns its place by explaining the move operation and conflict resolution.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the mutation nature, 4 parameters, no annotations, and no output schema, the description is reasonably complete. It covers the core operation and conflict behavior but lacks details on permissions (player_id usage), error cases, and return values. For a tool with this complexity, it's good but not fully comprehensive.
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 doesn't add meaning beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Equip', 'Moves') and resources ('item from inventory', 'equipment slot'), distinguishing it from sibling tools like 'unequip_item' and 'add_item_to_character' by focusing on equipment slot assignment rather than inventory management or removal.
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 context through the automatic unequip behavior when a slot is occupied, suggesting when this tool is appropriate. However, it lacks explicit guidance on when to use this versus alternatives like 'unequip_item' or 'add_item_to_character', and doesn't mention prerequisites such as the item being in inventory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it creates a JSON file, saves it to a specific directory ('packs/ directory inside the data folder'), and mentions the scope of export (selected entities or full backup). However, it lacks details on permissions, rate limits, or error handling, which are important for a tool that writes files.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose and subsequent sentences adding necessary details without waste. Every sentence earns its place by clarifying scope and output location.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations, no output schema), the description is fairly complete. It explains what the tool does, the output format (JSON pack file), and where it's saved. However, it lacks details on the structure of the JSON output or potential side effects, which could be helpful for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds marginal value by mentioning 'selected campaign entities' and 'selective export by entity type, location filter, or full campaign backup', which aligns with parameters like 'entity_types' and 'full_backup', but does not provide additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export campaign content as a portable compendium pack') and resource ('campaign entities'), distinguishing it from siblings like 'export_character_sheet' or 'import_pack'. It precisely defines what the tool does beyond just the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('selective export by entity type, location filter, or full campaign backup'), but does not explicitly state when not to use it or name specific alternatives among siblings. It implies usage scenarios without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and effectively discloses key behaviors: it validates slot availability, decrements slots on success, and returns remaining count. However, it lacks details on error handling, permission implications, or side effects beyond slot reduction.
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 front-loaded with the core action, uses three concise sentences with zero waste, and each sentence adds distinct value: action, validation, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description is reasonably complete—it covers purpose, validation, and return value. However, it lacks context on failure modes, idempotency, or how it integrates with other spell-related tools, leaving minor 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 already documents all parameters thoroughly. The description adds no additional parameter semantics beyond implying slot_level validation, meeting the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('use', 'decrementing') and resources ('spell slot', 'available slots'), and distinguishes it from siblings by focusing on spell slot consumption rather than spell management (add_spell, remove_spell) or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a character needs to cast a spell requiring a slot, but provides no explicit guidance on when to use this tool versus alternatives like 'roll_dice' for casting or 'apply_effect' for spell effects, nor does it mention prerequisites like character existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the search methodology (keyword expansion with D&D synonyms, TF-IDF scoring) and data sources (indexed PDF/Markdown), which is valuable behavioral context. However, it doesn't mention performance characteristics, error conditions, or what happens with no results.
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?
Well-structured with purpose statement, technical details, examples, and parameter sections. The examples are helpful but slightly lengthy. Every sentence adds value, though the tool could be slightly more concise by integrating the default limit mention into the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations and no output schema, the description provides good context: explains methodology, sources, and includes examples. The main gap is lack of output format details beyond 'formatted search results grouped by source' - more specificity about result structure would help.
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 baseline is 3. The description adds minimal value beyond the schema: it clarifies 'query' accepts natural language questions (implied in schema's 'natural language question' description) and mentions the default limit of 10 (already in schema). No additional parameter insights are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask a natural language question across all your rulebooks' with specific details about keyword expansion and TF-IDF scoring. It distinguishes from obvious siblings like 'search_rules' by emphasizing natural language processing across multiple sources (PDF and Markdown).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance with five concrete examples showing typical query patterns. It implicitly distinguishes from other search tools by focusing on natural language questions rather than structured searches, though it doesn't explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as listing/showing changes, implying it's a read-only operation without destructive effects. However, it lacks details on permissions needed, rate limits, or output format, which would be helpful given the absence of annotations and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by additional context. Every sentence adds value without waste, making it efficient and easy to understand.
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 moderate complexity (listing pending edits) and the absence of annotations and output schema, the description is adequate but could be more complete. It explains what the tool does but lacks details on output format or behavioral constraints, which would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description does not need to add parameter information, and it appropriately avoids redundancy. A baseline of 4 is applied since no parameters are present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('List pending player edits', 'Shows changes detected') and identifies the resource ('character sheet files', 'player-edited Markdown sheets'). It distinguishes itself from siblings like 'approve_sheet_change' by focusing on listing rather than approving changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to view pending edits from character sheets that need DM approval. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as 'approve_sheet_change' for taking action on these changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the public visibility requirement (a behavioral constraint) and implies a write operation ('import'), but doesn't mention potential side effects, error conditions, or what happens on successful import (e.g., where the character appears).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first states the purpose and context, the second provides parameter guidance and prerequisites. Every word serves a clear purpose, and the most important information (what the tool does) comes first.
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?
For a mutation tool with no annotations and no output schema, the description is adequate but has gaps. It covers the what and prerequisites well, but doesn't describe what happens after import (success behavior, error cases, or where to find the imported character). Given the complexity of importing external data, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by providing concrete examples of valid inputs ('https://www.dndbeyond.com/characters/12345678' or 'just the numeric character ID'), which clarifies the parameter semantics beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Import a public D&D Beyond character') and the target ('into the current campaign'), distinguishing it from siblings like 'import_character_file' or 'create_character'. It provides a complete verb+resource+context statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (importing from D&D Beyond specifically) and includes an important prerequisite (character must be public). However, it doesn't explicitly contrast with alternatives like 'import_character_file' for other import sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('gracefully shuts down', 'closes all WebSocket connections'), which implies it's a destructive operation that terminates active connections. However, it lacks details on permissions needed, error conditions, or what happens to in-progress sessions, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The first sentence states the core action, and the second elaborates on the behavior. It is front-loaded and efficiently conveys essential information without redundancy.
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 complexity (server shutdown with connections) and lack of annotations or output schema, the description is somewhat complete but has gaps. It explains what the tool does but omits details like confirmation prompts, return values, or error handling. For a destructive operation with no structured safety hints, more context would be beneficial.
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 does not mention any parameters, which is appropriate. A baseline of 4 is applied since there are no parameters to document, and the description does not add unnecessary param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Stop the Party Mode web server and disconnect all players') and distinguishes it from its sibling tool 'start_party_mode'. It uses precise verbs ('stop', 'disconnect', 'shuts down', 'closes') and identifies the resource ('Party Mode web server').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referencing 'Party Mode web server' and 'players', suggesting it should be used when the server is running and connected. However, it does not explicitly state when to use it versus alternatives or provide exclusions, such as whether it can be used if the server is already stopped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it processes transcriptions (including file paths), leverages campaign context, automatically chunks large inputs (>200k characters), and returns a prompt for an LLM. However, it lacks details on permissions, rate limits, or error handling, which would be useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose. Sentences earn their place by explaining input types, context usage, and handling of large transcriptions. However, the 'Args' and 'Returns' sections are redundant with the schema and could be trimmed for better conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (processing transcriptions with campaign context) and no output schema, the description is mostly complete. It covers input types, automatic chunking, and the return value (a prompt for LLM). However, it lacks details on output format or error cases, which would help an agent use it correctly without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema: it reiterates the purpose of 'transcription' and 'speaker_map' but does not provide additional syntax, format details, or examples. Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate structured SessionNote from a raw session transcription.' It specifies the verb ('generate'), resource ('structured SessionNote'), and source ('raw session transcription'), distinguishing it from sibling tools like 'add_session_note' or 'get_sessions' by focusing on transcription processing and structured summarization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you have a session transcription (raw text or file) and need a structured summary. It mentions leveraging campaign context and handling large transcriptions, but does not explicitly state when not to use it or name specific alternatives among siblings, such as 'add_session_note' for manual note addition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool can be used for both viewing (no arguments) and updating (partial updates), and it explains the immediate effects of 'interaction_mode' ('Takes effect immediately') and the comprehensive nature of 'model_profile' ('Updates all model settings and CC agent files at once'). However, it lacks details on permissions, error handling, or rate limits.
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 highly concise and well-structured, with four sentences that each serve a distinct purpose: stating the tool's purpose, explaining the no-argument view mode, detailing partial updates, and describing specific parameter behaviors. There is no wasted text, and information is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, no annotations, no output schema), the description does a good job of covering essential usage scenarios and behavioral traits. It explains the dual view/update functionality and key parameter effects, but could be more complete by addressing potential side effects, error conditions, or the format of returned configuration data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters thoroughly. The description adds minimal semantic value beyond the schema, only briefly mentioning 'model_profile' and 'interaction_mode' in usage contexts. It does not explain parameter interactions or provide additional meaning, meeting the baseline for high schema coverage.
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: 'Configure the Claudmaster AI DM settings for the current campaign.' It specifies the resource (Claudmaster AI DM settings) and the action (configure), but does not explicitly differentiate from sibling tools like 'start_claudmaster_session' or 'end_claudmaster_session' that manage sessions rather than settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Call with no arguments to view current configuration. Provide specific fields to update only those settings (partial update).' It also outlines specific use cases for parameters like 'model_profile' and 'reset_to_defaults', giving clear context for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: results are 'grouped by storyline and presented without spoilers,' and it explains what happens with an empty query. It doesn't mention rate limits, authentication needs, or potential errors, but for a search/discovery tool, the described behavior is reasonably comprehensive.
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 efficiently structured: it starts with the core purpose, explains the data source and presentation format, clarifies the empty query behavior, and provides concrete keyword examples. Every sentence adds value with zero wasted words, and information is well-organized from general to specific.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search/discovery tool with no annotations and no output schema, the description provides good context about what the tool does, how results are organized, and example usage. It could be more complete by describing the format of returned results or potential error conditions, but given the tool's relatively straightforward nature, it's mostly adequate.
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 5 parameters thoroughly. The description adds some value by providing keyword mapping examples that help users understand what to put in the 'query' parameter, but doesn't add meaningful semantics beyond what the schema already provides for other parameters like level_min, level_max, storyline, or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Discover D&D adventures by theme, keyword, level range, or storyline' and specifies it searches 'official D&D 5e adventure modules from the 5etools index.' This distinguishes it from sibling tools like 'search_library' or 'search_rules' by focusing specifically on adventure modules rather than general content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'Empty query with no filters returns a summary of all available storylines' and gives keyword mapping examples that help users understand when to use specific terms. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes the import process ('handles name conflicts via chosen conflict mode'), explains side effects ('regenerates all entity IDs and re-links cross-references'), and mentions the preview option for safe testing. It doesn't cover potential error conditions or performance implications, but provides substantial operational 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 efficiently structured with three focused sentences: purpose statement, operational details, and usage tip. Every sentence adds value with zero redundancy. It's appropriately sized for a 4-parameter tool with complex behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides good coverage of what the tool does and how it behaves. It explains the import process, conflict handling, and preview option. However, it doesn't describe the return value or error responses, which would be helpful given the absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description mentions 'preview=true' as an example and implies conflict_mode usage, but adds minimal semantic value beyond what's in the schema. This meets the baseline expectation when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('import a compendium pack'), the target resource ('into the current campaign'), and the scope ('loads a CompendiumPack JSON file and imports its entities'). It distinguishes from siblings like 'import_character_file' and 'import_from_dndbeyond' by specifying it handles campaign-level entity packs rather than character data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use it ('import a compendium pack into the current campaign') and includes a specific usage tip for preview mode. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'validate_pack' for pre-import validation, which would be helpful for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a 'formatted list' of PDF and Markdown sources with 'index status and content counts,' which adds useful behavioral context beyond a basic list operation. However, it doesn't mention potential side effects, performance considerations, or error conditions, leaving some 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 two sentences, front-loaded with the core purpose and followed by additional details on return format. Every sentence adds value: the first defines the action and resource, the second specifies output details. There is zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It explains what the tool does, what it returns, and the types of sources included. For a list operation with no complex inputs or outputs, this is sufficient, though it could slightly improve by mentioning any limitations or prerequisites.
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% (since there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate—it efficiently states the tool's purpose without unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all sources in the library with their content summaries.' It specifies the resource (sources in the library), the verb (list), and the scope (all sources). It distinguishes from siblings like 'list_enabled_library' (which likely shows only enabled sources) and 'search_library' (which filters results).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need a comprehensive overview of all library sources, including their content summaries, index status, and counts. It doesn't explicitly state when not to use it or name alternatives, but the context is clear from the description's specificity about returning 'all' sources versus filtered or enabled-only lists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's function and return format ('Returns matching facts with details on how they were learned'), which is helpful. However, it lacks details on permissions, rate limits, or potential side effects, leaving gaps for a query 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 front-loaded with the core purpose, followed by specific usage instructions in a logical flow. Every sentence adds value without redundancy, making it efficient and easy to parse. The structure supports quick understanding of the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete. It explains what the tool does, when to use it, and hints at the return format. However, without annotations or an output schema, it could benefit from more details on behavioral aspects like error handling or data freshness.
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%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema by mentioning the optional filters and the default no-argument behavior, but it doesn't provide additional syntax or format details. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('query', 'searches') and resource ('party's collective knowledge'), distinguishing it from siblings like get_events or get_party_status. It explicitly defines the knowledge scope as facts learned through NPC interactions, observation, investigation, reading, etc., making its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use with no arguments to list all known facts. Provide a topic to search for specific knowledge. Optionally filter by source or acquisition method.' This covers both the default behavior and specific use cases, offering clear alternatives within the tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly describes the behavior: popping from a queue (implying mutation/consumption), returning action details and queue count, or reporting emptiness. It covers the core operation and outcomes well, though it doesn't mention side effects like permissions or rate limits.
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 efficiently structured in two sentences: the first states the action, the second details the return values. Every sentence adds value without redundancy, making it front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (queue management with potential side effects), no annotations, and no output schema, the description does well by explaining the operation and return values. It could improve by mentioning authentication needs or error cases, but it covers the essentials adequately.
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 appropriately omits parameter details, focusing on the tool's purpose and output. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Pop the next pending player action from the Party Mode queue') and the resource involved ('Party Mode queue'). It distinguishes itself from siblings like 'party_resolve_action' or 'player_action' by focusing on queue retrieval rather than action resolution or submission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to retrieve pending actions from the Party Mode queue, but does not explicitly state when to use this tool versus alternatives like 'party_resolve_action' or 'get_party_status'. It provides basic context but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the conditional behavior based on input (ID removes specific instance, name removes all matches), which is valuable. However, it lacks details on permissions needed, error handling, or what happens if no matching effect exists.
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 front-loaded with the core purpose in the first sentence, followed by a concise explanation of parameter behavior in two sentences. Every sentence adds value with zero waste, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with conditional behavior), no annotations, and no output schema, the description does well by explaining the core functionality and parameter semantics. However, it could be more complete by addressing error cases, permissions, or confirmation of removal success.
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 schema description coverage is 100%, so the schema already documents both parameters well. The description adds meaningful context by explaining the semantic difference between providing an effect ID (exact match, removes specific instance) versus an effect name (removes all with that name), which clarifies usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Remove') and resource ('an active effect from a character'), and distinguishes it from sibling tools like 'apply_effect' and 'remove_item' by focusing on effect removal rather than application or item management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use specific parameter values (effect ID vs. name), but does not explicitly state when to use this tool versus alternatives like 'remove_spell' or 'remove_item', nor does it mention prerequisites such as character existence or effect presence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: that it works globally without a campaign, respects campaign priority when active, and provides concrete examples of search patterns. It doesn't mention rate limits, authentication needs, or pagination behavior, but covers the essential operational context well.
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 perfectly structured: a clear purpose statement first, followed by important behavioral context, then practical examples. Every sentence earns its place with zero wasted words, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters, 100% schema coverage, and no output schema, the description provides excellent context about operational behavior and usage patterns. The examples effectively compensate for the lack of output schema by showing what kinds of results to expect. It could potentially mention result format or error cases, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value through examples that illustrate parameter combinations (e.g., using query with category, class_filter with category), but doesn't provide additional semantic meaning beyond what's already documented in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Search for rules content') and resource ('across all loaded rulebooks'). It distinguishes itself from sibling tools like 'search_library' by focusing specifically on rules content rather than general library content, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by explaining it works without a campaign loaded and prioritizes active campaign rulebooks. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among sibling tools, though the context implies it's for rules content specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a read-only visualization tool (implied by 'Render', 'Shows'), returns ASCII art format, and has specific error/edge case behavior ('No tactical map active'). However, it doesn't mention rate limits, authentication needs, or what happens when highlight_aoe is provided.
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?
Perfectly concise with two focused sentences. First sentence states core functionality, second covers edge cases. Zero wasted words, front-loaded with primary purpose, and every sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a visualization tool with one optional parameter, no annotations, and no output schema, the description provides adequate context. It explains what the tool does, the output format (ASCII art), and error conditions. However, it doesn't describe the grid coordinate system or how participants are represented, which could be helpful given the combat context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single optional parameter. The description doesn't add parameter information beyond what's in the schema, but with only one optional parameter and high schema coverage, this is acceptable. The baseline would be 3, but the tool has 0 required parameters which elevates the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Render', 'Shows') and resources ('current tactical map', 'positions of all combat participants on a grid'). It distinguishes itself from siblings by focusing on visual representation of combat state, unlike data retrieval or management tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('if no positions are set or no combat is active' returns specific message), but doesn't explicitly state when NOT to use it or name alternatives. It implies usage during active combat scenarios but lacks explicit exclusions or comparisons to other combat-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool does (validation checks) and what it returns (detailed report), but lacks details on error handling, performance characteristics, or permissions required. It adequately describes the core behavior but could be more comprehensive.
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 efficiently structured in two sentences: the first states the purpose and key constraint, the second enumerates validation aspects and output. Every phrase adds value with zero redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation operation), no annotations, and no output schema, the description does well by explaining the validation scope and report output. However, it could benefit from mentioning error cases or limitations to be fully complete for agent 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 description doesn't add parameter-specific details beyond what's in the schema (which has 100% coverage for the single parameter 'file_path'). However, with only one parameter and high schema coverage, the baseline is strong. The description contextually reinforces that 'file_path' refers to a 'pack JSON file' for validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('validate a compendium pack file without importing it') and distinguishes it from sibling tools like 'import_pack' by emphasizing the non-importing nature. It specifies the resource ('pack file') and the scope of validation checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('without importing it'), implying it's for pre-import validation. However, it doesn't explicitly state when not to use it or name alternatives like 'import_pack' for comparison, though the distinction is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well. It describes the auto-population behavior (saving throws, proficiencies, etc.), prerequisite requirement (rulebook must be loaded), and error behavior (returns error message if no rulebook). However, it doesn't mention mutation effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste. First states core purpose, second explains auto-population behavior and prerequisite, third describes error case. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description provides good context about behavior, prerequisites, and error handling. However, it doesn't describe what the tool returns upon success (character object, ID, confirmation) which would be helpful given no output schema exists.
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 20 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, but it does provide context about auto-population from rulebook definitions which helps understand how parameters relate to system behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new player character with specific auto-population behavior when a rulebook is loaded. It distinguishes from siblings by focusing on character creation rather than modification or retrieval operations like update_character or get_character.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'When a rulebook is loaded' and provides a clear prerequisite: 'Requires a rulebook to be loaded (use load_rulebook source="srd" first).' Also specifies what happens without a rulebook: 'Without a rulebook, returns an error message asking to load one first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it creates the directory if missing (a side effect), opens the system file manager (platform-specific behavior), and returns the absolute path with instructions. This covers the tool's operational impact beyond basic I/O.
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 efficiently structured in three sentences: purpose, behavior, and return value. Each sentence adds essential information without redundancy, making it easy to parse and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description provides good coverage: it explains what the tool does, its side effects (directory creation), platform behavior, and return value. However, it doesn't detail error cases or permissions, leaving minor gaps in completeness.
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 baseline is 4. The description appropriately doesn't discuss parameters, as none exist, and instead focuses on the tool's behavior and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open the library folder') and resource ('where users can drop PDF and Markdown rulebooks'), distinguishing it from sibling tools like 'list_library' or 'scan_library' which are read-only operations. It specifies the exact purpose: opening a specific folder for file management rather than listing or searching content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when users need to access the library folder to add rulebooks. However, it doesn't explicitly state when NOT to use it or name alternatives like 'list_rulebooks' for viewing existing content, though the purpose implies it's for file management rather than querying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively explains the tool's dual behavior: returning cached narratives when available and falling back to full generation on cache misses. It also describes the response structure ('cached' field, 'narrative' field) and how to interpret them. However, it doesn't mention potential rate limits, authentication needs, or error conditions.
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 efficiently structured with four sentences that each serve a distinct purpose: stating the tool's function, explaining cache behavior, providing usage timing, and explaining response handling. There's no wasted text, and the most critical information (what the tool does) comes first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 100% schema coverage, but no annotations or output schema, the description does an excellent job explaining the tool's purpose, behavior, and usage context. It effectively compensates for the lack of structured behavioral annotations by describing the cache mechanism and response interpretation. The main gap is the absence of output schema documentation, but the description partially addresses this by explaining key response fields.
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%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'turn' and 'outcome' generally but doesn't provide additional context about parameter usage or relationships. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve a pre-generated narrative variant for a combat turn.' It specifies the verb ('retrieve'), resource ('pre-generated narrative variant'), and context ('combat turn'), distinguishing it from sibling tools like party_thinking or combat_action. The description goes beyond the tool name to explain what it actually does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Call this right after party_thinking, before writing your own narrative.' It also explains what to do with the response ('If 'cached' is true in the response, use 'narrative' as your starting point...'). This gives clear temporal and contextual instructions that help the agent choose this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: it generates a new token and QR code while invalidating the old one, indicating a mutation with security implications. However, it lacks details on permissions, rate limits, or error conditions, leaving some behavioral aspects unclear.
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 front-loaded with the core action in the first sentence, followed by usage guidelines in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (mutation with security impact), no annotations, and no output schema, the description is fairly complete. It covers purpose, usage, and key behavior, but lacks details on output format (e.g., what the new token/QR code looks like) and error handling, which could be important for an agent.
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, so the baseline is 3. The description adds value by clarifying the parameter's purpose in context ('to refresh token for'), but it doesn't provide additional semantics beyond what the schema already states (e.g., format examples or constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('generate', 'invalidate') and resources ('token', 'QR code', 'player'). It distinguishes itself from siblings by focusing on token refresh, unlike other party-related tools (e.g., party_kick_player, party_knowledge) that handle different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidelines with 'Use when' followed by three specific scenarios: lost QR code, security concern, or after being kicked and readmitted. This clearly indicates when to invoke this tool versus alternatives, though no explicit alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: the multi-step workflow, spoiler boundaries (only Chapter 1 content revealed initially), caching behavior, and auto-population defaults. It doesn't mention error conditions or performance characteristics, but covers most operational aspects.
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 well-structured with clear sections: purpose statement, workflow steps, spoiler boundaries, examples, and common IDs. While comprehensive, it could be slightly more concise - the common adventure IDs list is helpful but lengthy. Most sentences earn their place by adding practical guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no annotations and no output schema, the description provides substantial context: workflow details, behavioral constraints, examples, and integration guidance. It doesn't describe return values or error responses, but given the complexity of the operation, it covers most aspects an agent would need to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by providing concrete examples of adventure_id values, explaining the practical meaning of populate_chapter_1 with a specific example, and showing how campaign_name parameter affects behavior (creates new vs uses current).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('load', 'integrate', 'orchestrates') and resources (D&D adventure module, campaign). It distinguishes itself from sibling tools by focusing on adventure loading workflow rather than character management, campaign creation, or other operations 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: it mentions using 'discover_adventures' to search for adventures before loading, and clarifies parameter usage with concrete examples. It also explains when to provide campaign_name parameter versus using current campaign.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes what the tool does: compares installed vs. GitHub versions, returns update status, versions, and upgrade command if needed. However, it doesn't mention potential side effects like network calls, error handling, or authentication requirements, leaving some behavioral aspects unspecified.
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 efficiently structured in three sentences with zero waste. The first sentence states the purpose, the second explains the comparison and return values, and the third provides usage timing. Each sentence earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description provides good context about what it does, when to use it, and what information it returns. However, without an output schema, it doesn't specify the exact structure of the returned data (e.g., format of versions, command syntax), leaving some ambiguity for the agent.
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. The description appropriately doesn't discuss parameters since none exist, but it does clarify the tool's scope (dm20-protocol specifically) which adds context beyond the empty schema. This justifies a score above the baseline of 3 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if a newer version of dm20-protocol is available.' It specifies the verb ('check'), resource ('dm20-protocol'), and scope ('available updates'), distinguishing it from all sibling tools which are unrelated to version checking or updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Call this at session start to notify the user about available updates.' This provides clear timing guidance and context for usage, which is not implied by 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by explaining the tool's behavior: it provides 'instant visual feedback' with animated dots and a message, and the indicator 'disappears automatically' when party_resolve_action is called. It doesn't mention potential side effects or errors, but covers the core interactive behavior adequately.
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 perfectly structured: the first sentence states the purpose, the second provides timing and visual feedback details, and the third explains the termination condition. Every sentence earns its place with zero wasted words, making it highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and no output schema, the description is complete: it explains what the tool does, when to use it, how it behaves, and how it interacts with sibling tools. No additional context is needed given the tool's straightforward role in the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the parameter's purpose ('message shown to players') and providing a concrete example ('The Dungeon Master consults the ancient scrolls…'), which helps the agent understand the semantic intent beyond the schema's technical definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to signal to players that the DM is preparing the next narrative. It specifies the exact trigger ('immediately after party_pop_action') and the visual effect ('animated dots + message'), distinguishing it from siblings like party_resolve_action which ends the indicator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use this tool ('immediately after party_pop_action') and when it ends ('automatically when you call party_resolve_action'). It clearly distinguishes from sibling tools by naming party_pop_action as the prerequisite and party_resolve_action as the termination event.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![dm20-protocol MCP server](https://glama.ai/mcp/servers/Polloinfilzato/dm20-protocol/badges/card.svg)](https://glama.ai/mcp/servers/Polloinfilzato/dm20-protocol)

Score Badge

Copy to your README.md:

[![dm20-protocol MCP server](https://glama.ai/mcp/servers/Polloinfilzato/dm20-protocol/badges/score.svg)](https://glama.ai/mcp/servers/Polloinfilzato/dm20-protocol)

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/Polloinfilzato/dm20-protocol'

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