rpg-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation2/5
The tool set has significant overlap and ambiguity, with many tools performing similar functions or having unclear boundaries. For example, multiple tools handle concentration (break_concentration, check_automatic_concentration_break, check_concentration_duration, check_concentration_save, get_concentration_state), corpse management (advance_corpse_decay, cleanup_corpses, create_corpse, get_corpse, get_corpse_by_character, get_corpse_inventory, harvest_corpse, list_corpses_in_encounter, list_corpses_nearby, loot_corpse), and terrain generation (generate_terrain_patch, generate_terrain_pattern, update_terrain), making it difficult for an agent to choose the right one without deep context. While descriptions help, the sheer number of overlapping tools creates confusion.
Naming Consistency4/5
Tool names are mostly consistent with a verb_noun pattern (e.g., create_character, update_character, delete_character, get_character), which aids predictability. However, there are minor deviations such as dice_roll (noun_verb), load_tool_schema (verb_noun_noun), and some tools using abbreviations like aoe or xp, slightly reducing uniformity. Overall, the naming is readable and follows clear conventions, with only occasional inconsistencies.
Tool Count2/5
With 196 tools, the count is excessive for an RPG server, leading to overwhelming complexity and redundancy. Many tools could be consolidated (e.g., multiple concentration or corpse tools), and the high number suggests poor scoping. While RPG domains can be broad, this magnitude exceeds typical well-scoped sets (3-15 tools) and indicates a lack of focus, making it challenging for agents to navigate efficiently.
Completeness5/5
The tool set provides comprehensive coverage for RPG domains, including character management, combat, quests, world-building, narrative notes, and item systems. It supports full CRUD operations (e.g., create_character, get_character, update_character, delete_character) and lifecycle workflows (e.g., from character creation to combat to looting). There are no obvious gaps; tools like initialize_session and spawn_preset_encounter streamline complex tasks, ensuring agents can handle most RPG scenarios without dead ends.
Average 3.1/5 across 196 of 196 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- 24 of 24 community issues answered or closed in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on February 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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 full burden for behavioral disclosure but offers none. It doesn't mention whether this is a read-only operation, what the output format might be, potential side effects, or any constraints like computational complexity or session requirements implied by the sessionId parameter.
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 no wasted language. However, this conciseness comes at the cost of being under-specified rather than efficiently informative.
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 tool with 3 parameters (one with enum values), no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't address the tool's complexity, parameter meanings, behavioral characteristics, or relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters have schema descriptions. The description provides no information about parameters beyond what's in the schema structure. It doesn't explain what 'expression' should contain, what 'exportFormat' options mean, or what 'sessionId' is for.
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 'Simplify algebraic expressions' is a tautology that essentially restates the tool name 'algebra_simplify' without adding meaningful specificity. It doesn't distinguish this tool from its sibling 'algebra_solve' or clarify what types of algebraic expressions it handles (e.g., polynomials, rational expressions).
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. It doesn't mention the sibling tool 'algebra_solve' for solving equations, nor does it specify appropriate contexts or prerequisites for simplification versus solving.
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. 'List all worlds' implies a read operation but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what the output format is (e.g., list of IDs, names, or full objects). For a tool with zero annotation coverage, this is inadequate as it leaves critical behavioral traits undefined.
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 three words, front-loaded to state the core action. There's no wasted language or unnecessary elaboration, making it efficient for quick scanning. Every word earns its place, though this brevity contributes to the lack of detail in other dimensions.
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 list operation in a multi-tool environment), no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It doesn't explain what 'worlds' are in this context, how results are returned, or any prerequisites. For a tool that likely returns multiple items, more context is needed to guide 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 one parameter 'sessionId' with 0% schema description coverage. The description 'List all worlds' doesn't mention any parameters, so it adds no semantic information beyond what the schema provides. However, with only one parameter and baseline expectations for session IDs in such systems, the gap is moderate. The description doesn't compensate for the lack of schema documentation, but the parameter count is low.
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 'List all worlds' is a tautology that essentially restates the tool name 'list_worlds'. It provides the verb 'list' and resource 'worlds', but doesn't differentiate this from sibling tools like 'get_world', 'create_world', 'delete_world', or 'get_world_state', nor does it specify scope or format. While it minimally states what the tool does, it lacks the specificity needed for clear differentiation.
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 are multiple sibling tools related to worlds (e.g., 'get_world', 'create_world', 'delete_world', 'get_world_state'), but the description doesn't indicate whether this is for retrieving a summary list versus detailed data, or when filtering might be needed. No context, exclusions, or alternatives 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation (processing decay) but doesn't detail effects like corpse state changes, permissions required, or side effects. This is inadequate for a tool that likely alters game state.
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, clear sentence with no wasted words, making it easy to parse. However, it's overly terse for a tool with two parameters and no annotations, potentially under-specifying critical details.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, return values, and error conditions, leaving significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no param details. The description mentions 'when game time advances', hinting at time-related input, but doesn't explain the 'hoursAdvanced' parameter's role or the 'sessionId' purpose. It adds minimal value beyond the bare schema.
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 action ('process corpse decay') and trigger ('when game time advances'), which clarifies the tool's purpose. However, it doesn't differentiate from sibling tools like 'advance_effect_durations' or 'advance_heat_decay', leaving ambiguity about its specific role in the system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions the trigger ('when game time advances') but doesn't specify prerequisites, exclusions, or related tools like 'cleanup_corpses' or 'harvest_corpse', leaving the agent without contextual usage cues.
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 full burden. 'Delete' implies a destructive mutation, but the description doesn't disclose whether this is permanent, reversible, requires specific permissions, or has side effects (e.g., cascading deletions). This is a critical gap 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.
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 action and resource, making it immediately scannable. Every word earns its place.
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?
This is a destructive mutation tool with no annotations, no output schema, and 2 undocumented parameters. The description fails to provide essential context about behavior, parameters, or outcomes. For a tool that permanently removes data, this level of documentation is dangerously inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions 'by ID' but doesn't explain what 'id' represents, what format it expects, or what 'sessionId' is for. With 2 undocumented parameters, the description adds minimal value beyond the tool name.
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 ('Delete') and resource ('a world by ID'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'delete_character' or 'delete_party', but the resource specificity is adequate for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites, consequences, or relationships with other tools like 'create_world' or 'list_worlds'. The agent must infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'optional filters' but doesn't disclose behavioral traits such as whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output format looks like (e.g., list of events with timestamps). The description is minimal and misses key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with a single sentence that states the core purpose. There's no wasted text, making it efficient, though it could benefit from slightly more detail 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 complexity (5 parameters with enums, no output schema, no annotations), the description is incomplete. It doesn't explain return values, error conditions, or how parameters interact, leaving significant gaps for an AI agent to understand tool behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'optional filters' generically without explaining what the parameters (limit, eventType, sourceType, includeConsumed, sessionId) mean or how they affect the query. This adds little value beyond the schema's structure, failing to clarify semantics like what 'includeConsumed' entails or how 'sessionId' is used.
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 'Get recent event history with optional filters' which provides a clear verb ('Get') and resource ('event history'), but it's vague about what 'event history' entails in this context (e.g., game events, system logs). It doesn't distinguish from siblings like 'get_recent_interactions' or 'poll_events', leaving ambiguity about 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 'get_recent_interactions' and 'poll_events', the description lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'private state' and '(LLM only)', hinting at access restrictions or specialized use, but fails to detail permissions, data sensitivity, rate limits, or response format. This leaves significant gaps for a tool handling potentially sensitive data.
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 very brief—only one sentence—which is efficient and front-loaded. However, the '(LLM only)' suffix feels tacked on and unexplained, slightly detracting from clarity. Overall, it avoids unnecessary verbosity.
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, 0% schema coverage, no output schema, and the tool's potential complexity (accessing private state), the description is inadequate. It does not cover behavioral aspects, parameter meanings, or output expectations, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with two parameters ('nationId' and 'sessionId') undocumented. The description does not explain what these parameters represent, their expected formats, or why 'sessionId' is optional. It adds no meaningful semantic information beyond the bare schema.
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 'Get private state for a specific nation' which clearly indicates a retrieval operation for nation-specific data. However, it does not differentiate from sibling tools like 'get_world_state' or 'get_narrative_context', leaving the scope vague. The addition of '(LLM only)' is ambiguous rather than clarifying.
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 is provided on when to use this tool versus alternatives such as 'get_world_state' or 'get_narrative_context'. The '(LLM only)' note might imply a restriction but does not specify conditions or exclusions, offering minimal practical usage 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 the full burden. It mentions checking resolution and getting results, but doesn't disclose behavioral traits such as whether this is a polling operation (implying potential delays or retries), what 'resolved' means (e.g., success/failure states), or the response format. This leaves gaps in understanding how the tool behaves in practice.
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 gets straight to the point without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with additional context if needed. No fluff or redundancy is 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 (a polling tool with 3 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the tool's role in a larger workflow (e.g., turn-based systems), what results to expect, or error conditions. This makes it inadequate for an agent to use effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no meaning beyond the parameter names (worldId, turnNumber, sessionId)—it doesn't explain what these IDs represent, their formats, or how they relate to checking turn results. This fails to compensate for the low schema coverage, leaving parameters largely undocumented.
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 'Check if turn has resolved and get results' states the purpose with a verb ('Check') and resource ('turn'), but it's somewhat vague about what 'turn' refers to in this context and doesn't distinguish from sibling tools like 'get_turn_status' or 'resolve_turn'. It's functional but lacks specificity about the domain (e.g., game turns, workflow turns).
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., after submitting turn actions), exclusions, or how it differs from similar tools like 'get_turn_status' or 'poll_events'. Without this context, an agent might struggle to choose correctly 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 full burden. It mentions 'process a full turn cycle' but doesn't disclose behavioral traits such as whether it's read-only or mutative, what side effects occur, permissions needed, or response format. This leaves critical gaps for a tool that likely performs significant game-state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple statement, though it could be more front-loaded with critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'full turn cycle', lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't address what the tool returns, error conditions, or behavioral nuances, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the schema, failing to explain parameters like 'worldId', 'turnNumber', or 'sessionId'. With 3 parameters and no schema descriptions, this is a significant shortfall.
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 'Process a full turn cycle (economy, conflicts, etc.)' states a vague purpose with a verb ('process') and resource ('turn cycle'), but lacks specificity about what 'process' entails or what domains are involved beyond the parenthetical examples. It doesn't clearly distinguish from siblings like 'advance_turn' or 'submit_turn_actions', leaving ambiguity about its unique role.
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 'advance_turn' and 'submit_turn_actions', the description fails to indicate prerequisites, timing, or exclusions, offering no help in tool selection.
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 ('submit'), but doesn't disclose behavioral traits like whether it's idempotent, requires specific permissions, has side effects, or how errors are handled. The mention of 'batched' hints at bulk processing, but lacks details on limits or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with just one phrase, which is appropriately sized. However, it's under-specified rather than efficiently informative, lacking necessary details for a tool with 4 parameters and complex nested objects in 'actions'.
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 (4 parameters, nested 'actions' array with multiple properties, no output schema, and no annotations), the description is incomplete. It doesn't explain the tool's role in a turn-based system, what 'actions' are valid, or the expected outcome, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain any parameters, leaving 'worldId', 'nationId', 'actions', and 'sessionId' undocumented. The description mentions 'actions' but doesn't clarify their structure or the 'batched' nature, failing to add meaningful semantics beyond the bare schema.
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 'Submit actions for this turn (batched)' states a verb ('submit') and resource ('actions'), but is vague about what 'actions' entail or what 'this turn' refers to. It doesn't distinguish from siblings like 'advance_turn' or 'resolve_turn', leaving the specific purpose unclear.
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 mentions 'this turn' and 'batched', but doesn't explain prerequisites, timing, or what happens after submission. Without context, an agent cannot determine appropriate usage.
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. 'Unequip' implies a mutation (removing an equipped item), but the description doesn't specify what happens after unequipping (e.g., item goes to inventory, effects are removed), whether it requires specific permissions, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Unequip an item.') with no wasted words, making it front-loaded and easy to parse. However, it borders on under-specification, which slightly reduces its effectiveness despite the brevity.
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 affecting character state), lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't cover behavioral aspects, parameter meanings, or expected outcomes, leaving critical gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (characterId, itemId, sessionId) are documented in the schema. The description adds no information about these parameters—it doesn't explain what they represent, their format, or why sessionId is optional. This fails to compensate for the schema's lack of 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 'Unequip an item' clearly states the verb ('unequip') and resource ('an item'), making the basic purpose understandable. However, it doesn't specify what system or context this applies to (e.g., character equipment system), nor does it distinguish from the sibling tool 'equip_item' beyond the obvious opposite action. This makes it somewhat vague compared to what a 4 or 5 would require.
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 item must be equipped first), related tools like 'equip_item', or any context-specific rules. This leaves the agent with minimal direction beyond 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 'solve' but doesn't clarify if this is a read-only calculation or a write operation, what permissions might be needed, how errors are handled, or any rate limits. The description is too vague to inform the agent about behavioral traits 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 with a single sentence 'Solve algebraic equations.' It is front-loaded and wastes no words, making it easy to parse quickly. However, this conciseness comes at the cost of completeness, as noted in other dimensions.
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 solving algebraic equations (which can involve multiple parameters and potential outputs), the description is incomplete. With no annotations, 0% schema description coverage, and no output schema, it doesn't provide enough context for the agent to understand how to use the tool effectively, what to expect in return, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the parameters are documented in the schema. The description 'Solve algebraic equations' adds no meaning about the parameters (equation, variable, exportFormat, sessionId), such as what formats the equation should be in, what the variable represents, or how sessionId is used. It fails to compensate for the lack of schema 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 'Solve algebraic equations' clearly states the verb ('solve') and resource ('algebraic equations'), providing a basic purpose. However, it lacks specificity about what types of equations (e.g., linear, polynomial) or solving methods it supports, and it doesn't differentiate from the sibling tool 'algebra_simplify', which might handle related but distinct operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention the sibling 'algebra_simplify' or other potential tools for mathematical operations, nor does it provide context like prerequisites or when not to use it. This leaves the agent without usage 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?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a mutation (likely), what permissions are needed, whether it's idempotent, or what happens on success/failure. This is inadequate for a tool that presumably modifies state.
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 appropriately front-loaded and efficiently conveys the core action, though this brevity contributes to gaps in other dimensions.
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, 0% schema coverage, no output schema, and a likely state-mutating tool, the description is incomplete. It lacks essential context like behavioral effects, parameter meanings, and expected outcomes, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'characterId', 'questId', or 'sessionId' represent, their formats, or relationships. This leaves all three parameters semantically undefined.
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 action ('Assign') and target ('a quest to a character'), which clarifies the tool's purpose. However, it doesn't differentiate from sibling tools like 'complete_quest' or 'create_quest', leaving the specific role within the quest lifecycle ambiguous.
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., quest and character must exist), exclusions, or related tools like 'complete_quest' or 'list_quests', 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?
With no annotations, the description carries full burden but only states 'Define a new quest' without disclosing behavioral traits like permissions needed, whether it's idempotent, how it interacts with existing quests, or error handling. It lacks critical context for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, though it sacrifices detail for brevity.
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 complex creation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavior, parameters, or output, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. With 9 parameters including complex nested objects, the description fails to explain any semantics, leaving inputs undocumented beyond the schema.
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 'Define a new quest in the world' clearly states the action (define) and resource (quest), but it's vague about scope and lacks differentiation from siblings like 'assign_quest' or 'complete_quest'. It doesn't specify what 'define' entails operationally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'assign_quest' or 'complete_quest'. The description doesn't mention prerequisites, context, or exclusions, leaving usage ambiguous.
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 without disclosing behavioral traits like permanence, permissions required, or effects on related data (e.g., if secrets are referenced elsewhere). It mentions 'from the world' but doesn't clarify if this is irreversible 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, front-loading the key action. It's appropriately sized for a simple tool, though this brevity contributes to gaps in other dimensions.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavior, parameters, and outcomes, making it inadequate for safe and 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'secretId' or 'sessionId' represent, their formats, or relationships, leaving both parameters undocumented beyond the schema's basic types.
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 action ('Delete') and resource ('a secret'), but is vague about scope ('from the world') and lacks specificity compared to siblings like 'delete_character' or 'delete_world'. It distinguishes minimally by naming 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_secret' or 'reveal_secret', nor prerequisites such as needing a valid secretId. The description provides only the basic action without 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 the full burden of behavioral disclosure. It states it 'gets information,' implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with no annotations, this is insufficient to inform safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with no wasted content, 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 (a read operation with two parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what information is returned, how to interpret parameters, or behavioral traits, leaving significant gaps for effective tool use in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, with two parameters (npcId and sessionId) undocumented. The description doesn't add any meaning beyond the schema, such as explaining what npcId refers to (e.g., a unique identifier for a fence NPC) or when sessionId is required. With low schema coverage, the description fails to compensate, leaving parameters unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get information about a fence NPC'), which is clear but vague. It specifies the resource (fence NPC) and verb (get information), but doesn't distinguish it from sibling tools like 'get_npc_context' or 'list_fences', nor does it clarify what type of information is retrieved. This meets the minimum viable threshold.
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_npc_context', 'list_fences', and 'get_character', there's no indication of when this specific tool is appropriate, such as for detailed vs. summary data or specific NPC types. This lack of context leaves 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions initialization and a one-time call, but doesn't explain what 'turn management' involves, whether it's idempotent, what permissions are needed, or what happens if called multiple times. For a tool with no annotations, 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 with no wasted words. It's front-loaded with the main action and includes a brief usage note, making it appropriately concise and well-structured for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that initializes turn management, with no annotations, no output schema, and undocumented parameters, the description is incomplete. It doesn't cover what the tool returns, error conditions, or detailed behavior, making it inadequate for the agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the tool description provides no information about parameters. It doesn't explain what 'worldId' or 'sessionId' represent, their formats, or how they relate to the initialization. With low schema coverage, the description fails to compensate, leaving parameters undocumented.
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 action ('Initialize turn management') and resource ('for a world'), which provides a basic purpose. However, it's vague about what 'turn management' entails and doesn't distinguish this tool from sibling tools like 'advance_turn' or 'get_turn_status', which are related to turn operations. The phrase 'call once per world' adds some scope but doesn't fully clarify the tool's unique role.
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 includes 'call once per world', which implies a one-time initialization per world, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'initialize_session' or other turn-related tools. No prerequisites, exclusions, or clear context for usage are mentioned, leaving the agent with minimal guidance.
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 'hearing range, stealth vs perception, and memory recording', which hints at behavioral traits like spatial constraints and persistence. However, it doesn't disclose critical details: whether this is a read or write operation, what permissions are needed, how errors are handled, or what the output looks like. For a 6-parameter tool 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 brief and front-loaded with key concepts. It uses a single sentence efficiently, though it could be more structured (e.g., separating purpose from mechanics). No wasted words, but slightly dense.
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 complexity (social interaction with spatial mechanics), no annotations, no output schema, and 6 parameters, the description is incomplete. It hints at mechanics but lacks details on behavior, output, error handling, or integration with siblings. Should provide more 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?
Schema description coverage is 83% (high), so the baseline is 3 even without parameter info in the description. The description doesn't add meaning beyond the schema, which already documents parameters like speakerId, targetId, content, volume, intent, and sessionId. No additional context or examples are provided.
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 handles 'social interaction with spatial awareness', which gives a vague purpose. It mentions specific mechanics like 'hearing range, stealth vs perception, and memory recording', but doesn't clearly state what the tool actually does (e.g., initiate conversation, process social actions). It doesn't distinguish from siblings like 'record_conversation_memory' or 'get_conversation_history'.
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. The description mentions mechanics but doesn't specify use cases, prerequisites, or exclusions. Sibling tools like 'record_conversation_memory' exist, but no comparison 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool updates an item template, implying mutation, but fails to mention critical details like required permissions, whether changes are reversible, or potential side effects (e.g., affecting existing items). 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 that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
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, low schema coverage (13%), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameter meanings, and expected outcomes, making it inadequate for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 13%, with only 'itemId' having a description. The tool description does not add any parameter semantics beyond what the schema provides, such as explaining the purpose of 'properties' or 'sessionId'. Given the low coverage, the description fails to compensate, leaving most parameters undocumented.
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 'Update an existing item template' clearly states the verb ('Update') and resource ('item template'), distinguishing it from tools like 'create_item_template' or 'delete_item'. However, it lacks specificity about what aspects of the item template are updated, making it somewhat vague compared to more detailed descriptions.
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. For example, it doesn't specify if this is for modifying item properties during gameplay or setup, or differentiate it from similar tools like 'update_character' or 'give_item'. The absence of context leaves 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?
No annotations are provided, so the description carries full burden. 'Update progress' implies a mutation operation, but it doesn't disclose behavioral traits like whether this requires specific permissions, if progress can be decreased, what happens when objectives are already complete, or what the response looks like. The description is minimal and lacks necessary context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration, making it front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain parameter meanings, behavioral implications, or usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The description mentions 'progress' but doesn't explain what the parameters mean (e.g., what characterId, questId, objectiveId refer to, what sessionId is for, or how progress values work). It adds minimal value beyond the schema's structural information.
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 updates progress on a quest objective, which is a clear verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'complete_objective' or 'complete_quest,' leaving ambiguity about how it differs from those completion-focused 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'complete_objective' and 'complete_quest' available, there's no indication whether this is for incremental progress updates versus final completion, nor any prerequisites or context for usage.
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. 'Update' implies a mutation operation, but the description doesn't state whether this requires specific permissions, what happens if the secret doesn't exist, whether changes are reversible, or what the response looks like. 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 at just one sentence with no wasted words. It's front-loaded with the core action ('update') and resource ('secret'), making it easy to scan. Every word earns its place, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters with nested objects in revealConditions), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the purpose of parameters like 'leakPatterns' or 'revealConditions', nor does it cover behavioral aspects like error handling or return values. For a mutation tool in a game/secret-management context, this leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 8 parameters are documented in the schema. The description only vaguely mentions 'properties' without specifying any of the actual parameters (e.g., secretId, sensitivity, leakPatterns). It fails to compensate for the schema's lack of descriptions, leaving most parameters semantically unclear.
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 'Update a secret's properties' clearly states the verb ('update') and resource ('secret'), but it's vague about what specific properties can be updated. It doesn't distinguish this tool from sibling tools like 'update_character' or 'update_item', which follow the same pattern. However, it avoids tautology by not just restating the tool 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 an existing secret), exclusions, or sibling tools like 'create_secret' or 'delete_secret'. The agent must infer usage from the tool name alone, which is insufficient for effective tool selection.
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 clarify permissions, rate limits, error conditions, or what 'active character info' entails. For a tool with no annotations, 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.
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 purpose without unnecessary words. It could be slightly improved by structuring it to highlight key details, but it's appropriately sized and avoids 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 (retrieving detailed party data), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain the return format, error handling, or dependencies, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (partyId, sessionId) with 0% description coverage, meaning the schema provides no semantic details. The description adds no information about these parameters—it doesn't explain what 'partyId' or 'sessionId' are, their formats, or why 'sessionId' is optional. This fails to compensate for the low 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: 'Get a party with all member details, leader, and active character info.' It specifies the verb ('Get') and resource ('party') along with what data is retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get_party_context' or 'get_party_members', which might retrieve similar or overlapping 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. With many sibling tools (e.g., 'get_party_context', 'get_party_members', 'list_parties'), there's no indication of how this tool differs in scope or context, leaving the agent to guess based on 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?
No annotations are provided, so the description carries full burden. It mentions signaling completion but doesn't disclose behavioral traits like whether this is a read-only or mutative operation, what permissions are required, whether it triggers turn advancement automatically, or what the response looks like. For a tool with no annotation coverage, this leaves critical 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 a single, clear sentence that gets straight to the point with zero wasted words. It's appropriately sized for a simple signaling operation and front-loads the essential information effectively.
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 turn-based systems and the complete lack of annotations, schema descriptions, and output schema, the description is insufficient. It doesn't explain what 'signaling' entails operationally, what happens after signaling, or how this interacts with other turn-related tools. For a tool that likely affects game state, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (worldId, nationId, sessionId) are documented in the schema. The description provides no information about what these parameters mean, their expected formats, or why sessionId is optional. This fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Signal that your nation is done planning') and the resource ('for this turn'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'submit_turn_actions' or 'advance_turn' that might also relate to turn completion, 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 implies usage at the end of planning phases ('done planning for this turn'), but provides no explicit guidance on when to use this versus alternatives like 'submit_turn_actions' or what happens if used prematurely. No prerequisites or exclusions are mentioned, leaving significant gaps in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates location data, implying a mutation, but lacks details on permissions, side effects (e.g., if movement triggers events), rate limits, or error conditions. This is inadequate for a tool with multiple parameters and no structured safety hints.
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 brief and front-loaded, consisting of a single sentence that directly states the tool's function. There is no wasted verbiage, though it could be more structured with separate clauses for context or usage.
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 (6 parameters, mutation tool), lack of annotations, and no output schema, the description is insufficient. It omits critical details like return values, error handling, interaction with game state, and how it differs from similar tools, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'world map coordinates or POI' and 'location name and optional POI reference', which loosely maps to targetX/targetY, locationName, and poiId, but fails to explain partyId or sessionId, leaving 2 of 6 parameters without semantic context.
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 ('Move') and resource ('a party'), specifying the action of relocating a party to coordinates or a POI. It distinguishes from siblings like 'move_character_to_room' by focusing on party-level movement on a world map, though it doesn't explicitly compare to alternatives like 'travel_to_location'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'travel_to_location' or 'update_party'. The description mentions the action but offers no context about prerequisites, constraints, or typical scenarios for invocation.
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 mentions 'distributions and expected values,' hinting at output types, but doesn't describe the return format, error conditions, computational limits, or whether it's a read-only vs. state-changing operation. For a tool with 6 parameters and no annotation coverage, this is insufficient, warranting a score of 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Calculate probabilities for dice rolls, including distributions and expected values.' It's front-loaded with the core purpose and adds a brief elaboration without waste. Every word earns its place, making it highly concise and well-structured for its length.
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 (6 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It states the purpose but fails to cover parameter meanings, behavioral traits, output details, or usage context. For a calculation tool with multiple inputs and no structured documentation, this minimal description is inadequate, resulting in a score of 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters are documented in the schema. The description doesn't add any parameter-specific information beyond the general purpose. It doesn't explain what 'expression', 'target', 'comparison', 'modifiers', 'exportFormat', or 'sessionId' mean or how they interact. This complete lack of parameter semantics results in a score of 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate probabilities for dice rolls, including distributions and expected values.' It specifies the verb ('calculate') and resource ('probabilities for dice rolls'), and distinguishes it from siblings like 'dice_roll' (which likely performs actual rolls rather than calculations). However, it doesn't explicitly differentiate from all statistical tools in the sibling list, keeping it at a 4 rather than 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or compare it to other probability or dice-related tools in the sibling list (e.g., 'dice_roll', 'calculate_aoe'). This lack of contextual usage information results in a score of 2.
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 'reduced price' and 'clears stolen flag after cooldown', which are useful behavioral details. However, it lacks critical information: whether this is a mutation (likely yes), what permissions are needed, error conditions, or what the output looks like. For a tool with 5 parameters and 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 two concise sentences with zero waste. It front-loads the core action and follows with a key behavioral detail. Every word earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and one behavioral trait but misses parameter details, error handling, output format, and usage context. For a mutation tool in a game system with many siblings, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), with only 'itemValue' having a description. The tool description adds no parameter-specific information beyond implying 'itemId' refers to a stolen item and 'fenceId' to an NPC. It doesn't explain 'sellerId' or 'sessionId', or provide format examples. With low schema coverage, the description fails to compensate 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 ('sell stolen item') and target ('to a fence NPC'), with the outcome ('for reduced price' and 'clears stolen flag after cooldown'). It distinguishes from obvious siblings like 'steal_item' or 'give_item' by focusing on fencing stolen goods, but doesn't explicitly differentiate from all potential alternatives in the extensive 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., the item must be stolen, the fence must be available), nor does it compare to tools like 'transfer_item' or 'sell_item' if they exist. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks if an item is stolen and gets provenance details, but doesn't cover critical aspects like whether this is a read-only operation, if it requires authentication, rate limits, or what happens if the item isn't found. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. There is no wasted verbiage or redundancy, making it appropriately concise and well-structured for its length.
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 check operation with provenance details), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving the agent with insufficient context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'item' and 'provenance details', which loosely relates to 'itemId', but doesn't explain what 'itemId' represents, the purpose of 'sessionId', or any format constraints. With 2 parameters and no schema descriptions, the description adds minimal semantic 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 tool's purpose with a specific verb ('check') and resource ('item'), and specifies the outcome ('get its provenance details'). However, it doesn't explicitly differentiate from sibling tools like 'check_stolen_items_on_character' or 'check_item_recognition', which reduces the score from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as how it differs from 'check_stolen_items_on_character' or 'check_item_recognition' in the sibling list. This leaves the agent without clear usage 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 must fully disclose behavioral traits. It only states what the tool does ('check if any secrets should be revealed'), but doesn't explain how it works—e.g., whether it's a read-only check, if it has side effects like updating game state, what permissions are needed, or what the output looks like. For a tool with no annotations, this is insufficient to inform safe or effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly. This is an example of effective brevity in tool descriptions.
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 (3 parameters, nested 'event' object with multiple properties, no annotations, no output schema), the description is incomplete. It doesn't address how the tool behaves, what it returns, or the meaning of its inputs. For a tool that likely influences game narrative or state, more context is needed to use it correctly without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, meaning none are documented in the schema. The description adds no parameter semantics—it doesn't explain what 'worldId', 'event', or 'sessionId' mean, their formats, or how they affect the check. With low schema coverage, the description fails to compensate, leaving parameters largely unexplained.
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: 'Check if any secrets should be revealed based on a game event.' It specifies the verb ('check') and resource ('secrets'), and the condition ('based on a game event'). However, it doesn't explicitly differentiate from sibling tools like 'reveal_secret' or 'get_secrets_for_context', which could provide similar functionality.
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, timing, or compare it to sibling tools such as 'reveal_secret' (which might directly reveal a secret) or 'get_secrets_for_context' (which might list secrets). This leaves the agent guessing about appropriate usage 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?
No annotations are provided, so the description carries full burden. 'Assert a territorial claim' implies a write/mutation operation, but the description doesn't disclose behavioral aspects like permissions needed, whether claims are reversible, conflict resolution with existing claims, or what happens after claiming. This leaves critical behavioral context 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a simple action and front-loaded with the core 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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or important behavioral constraints. The context demands more completeness for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 4 parameters and 0% schema description coverage, the schema provides no parameter documentation. The description mentions 'region' (mapping to regionId) but doesn't explain nationId, justification, or sessionId parameters. It adds minimal semantic value beyond what's implied by the tool name.
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 ('assert a territorial claim') and the target ('on a region'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'create_nation' or 'update_world_environment' that might involve territorial changes, so it doesn't reach the highest 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, prerequisites, or exclusions. With many sibling tools involving world/territory management (e.g., 'create_nation', 'update_terrain'), the lack of contextual usage information is a significant gap.
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 marks objectives as 'fully completed,' implying a mutation, but doesn't disclose behavioral traits like whether this is irreversible, requires specific permissions, affects quest state, or has side effects. The description is minimal and lacks necessary context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's apparent simplicity, though this conciseness may contribute to gaps in other dimensions.
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, 0% schema coverage, no output schema, and three parameters, the description is incomplete. It lacks details on behavior, parameters, and context, making it inadequate for a mutation tool in a complex system with many siblings. More information is needed to understand usage and effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'objective' but doesn't explain the three parameters (questId, objectiveId, sessionId) or their relationships. No additional meaning is provided beyond the schema's property names, leaving parameters undocumented.
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 ('Mark') and resource ('an objective'), specifying it's about completion. It distinguishes from sibling 'complete_quest' by focusing on objectives rather than quests, but doesn't explicitly contrast with 'update_objective' which might handle partial progress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_objective' (which might handle partial completion) or 'complete_quest' (for broader quest completion). The description implies usage for finalizing objectives but lacks explicit context 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool marks a quest as completed and grants rewards, implying a mutation operation, but lacks details on permissions required, whether it's idempotent, error conditions (e.g., invalid quest state), or what 'rewards' entail. 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 wasted words. It is front-loaded with the core action and outcome, 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 tool's complexity (a mutation operation with three parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral nuances, parameter details, or expected outcomes, leaving significant gaps for the agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It mentions 'quest' and implies 'character' via 'grant rewards', but doesn't explain parameter meanings (e.g., characterId identifies who completes the quest, questId specifies which quest, sessionId's purpose is unclear). The description adds minimal value beyond the parameter names themselves.
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 ('Mark as completed') and outcome ('grant rewards'), specifying both verb and resource. It distinguishes from siblings like 'assign_quest' or 'update_objective' by focusing on completion rather than assignment or modification, 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., quest must be assigned, objectives must be met), exclusions, or related tools like 'complete_objective' or 'update_quest', 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'manually create,' implying a write operation, but does not specify permissions, side effects (e.g., if it affects game state or loot tables), or response format. For a mutation tool with 10 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action and resource. It avoids unnecessary words and gets straight to the point, making it highly concise and well-structured for quick understanding.
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 (10 parameters, nested objects, no output schema, and no annotations), the description is inadequate. It does not explain the tool's behavior, return values, or how parameters interact (e.g., the relationship between 'characterId' and 'characterName'). For a tool with rich input schema and no structured support, more descriptive context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 20%, with only 'creatureType' and 'cr' having descriptions. The description does not add any parameter-specific information beyond the schema, failing to compensate for the coverage gap. For example, it does not explain the purpose of 'position', 'worldId', or other parameters, leaving their semantics unclear.
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 ('Manually create') and the resource ('a corpse for a dead character'), making the purpose specific and understandable. However, it does not explicitly differentiate this tool from sibling tools like 'create_character' or 'advance_corpse_decay', which would require more context about when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'create_character' for living characters or 'harvest_corpse' for interacting with existing corpses. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Define a new type of item' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether this requires specific permissions, if templates are reusable across sessions, what happens on duplicate names, or any rate limits. The example adds minimal 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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes a helpful example. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (7 parameters, no annotations, no output schema, 0% schema coverage), the description is incomplete. It lacks essential details for a mutation tool: parameter meanings, behavioral constraints, output expectations, and differentiation from siblings. The example is insufficient to bridge these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no parameter semantics beyond the example 'Iron Sword' hinting at the 'name' parameter. The 7 parameters (name, description, type, weight, value, properties, sessionId) are undocumented in the description, leaving key details like 'type' enum values or 'sessionId' purpose unexplained.
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 ('Define') and resource ('new type of item'), with an example ('Iron Sword') that clarifies it's about creating templates rather than instances. However, it doesn't explicitly differentiate from sibling tools like 'create_item' or 'create_character' which might create actual items/characters versus templates.
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., session context), when not to use it, or how it relates to sibling tools like 'create_item' or 'list_templates'.
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 only states the basic action. It doesn't mention whether this is a persistent creation, if it requires specific permissions, what happens on conflicts (e.g., duplicate names), or what the return value might be. For a creation tool with complex 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a tool name that already hints at the purpose, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters (including complex nested objects), no annotations, and no output schema, the description is severely incomplete. It doesn't address behavioral aspects, parameter meanings, or expected outcomes, leaving the agent with insufficient context to use the tool effectively beyond the basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, meaning most parameters are undocumented in the schema. The description adds no parameter information beyond implying 'creatureTypes' is involved, failing to compensate for the coverage gap. It doesn't explain what 'loot table' entails or how parameters like 'guaranteedDrops' versus 'randomDrops' differ.
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 ('Create') and resource ('loot table for a creature type'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'generate_loot' or 'list_loot_tables' beyond the basic verb, missing explicit 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 'generate_loot' (which might apply loot tables) or 'list_loot_tables' (which retrieves them). The description only states what it does, not when it's appropriate or what prerequisites might exist.
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 'Create' implies a write/mutation operation, it doesn't address permission requirements, whether the creation is permanent or reversible, rate limits, or what happens on success/failure. This leaves significant behavioral gaps for a tool that creates persistent game 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 gets straight to the point with zero wasted words. It's appropriately sized for a tool name that already indicates the core function, though this conciseness comes at the expense of providing necessary details.
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 complex creation tool with 9 parameters, no annotations, no output schema, and 0% schema description coverage, the description is severely inadequate. It doesn't explain parameter meanings, behavioral implications, return values, or usage context, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 9 parameters (7 required), the description provides no information about any parameters. It doesn't explain what 'worldId', 'aggression', 'startingResources', or other parameters mean or how they affect nation creation, failing to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new nation in the world'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'create_world' or 'create_character', but the specificity of 'nation' provides reasonable differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_world' or 'create_character', nor does it mention prerequisites such as needing an existing world. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 generates loot, implying a write operation, but doesn't disclose behavioral traits such as whether it modifies existing data, requires specific permissions, has side effects (e.g., updating inventory), or what the output looks like (e.g., item list, loot table). 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, target, and key parameters, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the purpose but lacks details on behavior, parameter meanings, usage context, and expected results. For a tool that likely generates items or loot data, this leaves critical gaps for an agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'creature type and CR', which maps to two of the four parameters, but doesn't explain 'corpseId' or 'sessionId', nor does it provide meaning for the mentioned parameters (e.g., what CR values are valid, examples of creature types). With low coverage, the description fails to compensate 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 ('Generate loot') and target ('for a corpse'), specifying it's based on 'creature type and CR'. It distinguishes from sibling tools like 'loot_corpse' or 'harvest_corpse' by focusing on generation rather than direct looting or harvesting. However, it doesn't explicitly differentiate from 'create_loot_table', which might be a related sibling.
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 'loot_corpse', 'harvest_corpse', or 'create_loot_table'. It mentions the parameters but doesn't specify prerequisites, context (e.g., after combat, for DM planning), or exclusions. This leaves the agent with minimal usage 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, what happens with invalid IDs, if authentication is needed via sessionId, or the format of returned data. 'Retrieve' implies a fetch, but lacks details on error handling 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 a single, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
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 2 parameters (0% schema coverage), no annotations, and no output schema, the description is inadequate. It doesn't explain what a 'character' entails in this context, how results are structured, or error conditions, leaving the agent with insufficient information for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'by ID' which hints at the 'id' parameter, but ignores 'sessionId' entirely. No information on parameter formats, constraints, or interdependencies is provided, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieve') and resource ('a character'), making the purpose unambiguous. It distinguishes from siblings like 'list_characters' by specifying retrieval by ID, but doesn't explicitly contrast with 'get_character' alternatives that might exist in other contexts.
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 'list_characters' or 'get_party_members'. The description doesn't mention prerequisites (e.g., needing a valid character ID) or contextual constraints, leaving usage unclear beyond the basic function.
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 this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication needs, rate limits, error conditions, or what happens if the corpse doesn't exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant information. It's appropriately sized for a simple retrieval tool.
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 (2 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter meanings, return values, error handling, or behavioral constraints. For a tool that likely returns structured corpse data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'corpse' but doesn't explain the 'corpseId' parameter's format or semantics, nor does it mention the optional 'sessionId' parameter at all. The description adds minimal value beyond what's implied by the tool name.
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 details about a corpse, including loot and harvestable resources.' It specifies the verb ('Get details') and resource ('corpse'), and mentions what details are included. However, it doesn't explicitly differentiate from sibling tools like 'get_corpse_by_character' or 'get_corpse_inventory', 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_corpse_by_character' or 'get_corpse_inventory', nor does it specify prerequisites or context for usage. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, side effects (e.g., if viewing inventory triggers events), rate limits, or response format. This is inadequate for a tool with potential game-state implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal 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 complexity (game inventory tool), lack of annotations, 0% schema coverage, and no output schema, the description is insufficient. It doesn't cover behavioral traits, parameter meanings, or return values, leaving critical gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'corpse' but doesn't explain 'corpseId' or 'sessionId' parameters, their formats, or relationships. It adds minimal value beyond the tool name, failing to compensate for the coverage gap.
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 ('inventory of a corpse'), making the purpose understandable. However, it doesn't differentiate from potential sibling tools like 'get_inventory' or 'loot_corpse' that 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 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 valid corpse), exclusions, or how it differs from related tools like 'get_inventory' or 'loot_corpse' in the sibling list, leaving usage ambiguous.
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 it's a read operation ('List'), but doesn't clarify if it returns all items or is paginated, what format the output takes, or any permissions needed. For a tool with zero annotation coverage, 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, 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 lack of annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't explain return values, parameter meanings, or behavioral nuances like pagination or permissions, leaving the agent with insufficient information to use the tool effectively in a complex gaming context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the tool description adds no information about what 'characterId' or 'sessionId' represent, their formats, or why 'sessionId' is optional. Without this, the agent lacks context to use the parameters correctly, failing to compensate for the schema's deficiencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('items in a character's inventory'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_inventory_detailed' or 'list_items', which appear to serve similar purposes, 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 like 'get_inventory_detailed' or 'list_items', nor does it mention prerequisites such as requiring a character to exist. It only states what it does, not when or why to use it.
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 retrieval by ID or creature type but lacks details on permissions, error handling, rate limits, or what happens if multiple parameters are provided. This is a significant gap for a tool with four parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and immediately specifies the key parameters, 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 complexity (4 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error conditions, or the interplay between parameters like 'id' and 'creatureType', leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'ID or creature type', covering two of the four parameters (id, creatureType) but ignoring 'cr' and 'sessionId'. This partial coverage leaves key parameters undocumented.
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 ('loot table'), specifying it can be retrieved by 'ID or creature type'. It doesn't explicitly differentiate from sibling tools like 'list_loot_tables' or 'generate_loot', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_loot_tables' for browsing or 'generate_loot' for applying a loot table. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Get all members' but doesn't clarify if this is a read-only operation, what permissions are needed, how data is returned (e.g., pagination, format), or any rate limits. This leaves significant gaps in understanding the tool's behavior 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 that efficiently conveys the core action without unnecessary words. It is front-loaded and wastes no space, 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 tool has no annotations, no output schema, and low parameter schema coverage, the description is insufficiently complete. It doesn't address behavioral aspects like safety, return format, or error handling, leaving the agent with inadequate information to use the tool effectively in a complex environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, so the schema provides no semantic context. The description mentions 'a party' which implies the 'partyId' parameter, but doesn't explain what 'partyId' is or the purpose of 'sessionId'. It adds minimal value beyond the schema, failing to compensate for the low 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 the resource 'all members of a party with their character details', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_party' or 'get_character', which might retrieve related but different data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_party' for party-level details or 'list_characters' for broader character listings. It lacks any context about prerequisites, exclusions, or typical scenarios for its application.
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 retrieves position data, implying a read-only operation, but does not specify if it requires authentication, has rate limits, returns real-time or cached data, or handles errors. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and wastes no words. It efficiently conveys the core functionality without unnecessary elaboration, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that retrieves positional data in a game/world context, with no annotations, no output schema, and low parameter documentation, the description is insufficient. It does not cover return values, error conditions, or interaction with other tools, leaving the agent with incomplete context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, with two parameters (partyId and sessionId) undocumented in the schema. The description mentions 'a party' but does not explain what partyId represents, the format of sessionId, or why sessionId is optional. It adds minimal semantic value beyond the parameter names, failing to compensate for the low 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 with a specific verb ('Get') and resource ('current position of a party on the world map'), making it immediately understandable. However, it does not explicitly differentiate from sibling tools like 'get_party' or 'get_party_context', which might also provide positional information, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_party' or 'get_region_map', which might offer related information. It lacks context on prerequisites, timing, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't cover aspects like permissions needed, rate limits, response format, or whether it returns active/completed quests. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, 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 (2 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter meanings, and return values, making it inadequate for reliable tool invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'for a character', which hints at the 'characterId' parameter but doesn't explain its format or purpose. It doesn't address the optional 'sessionId' parameter at all, failing to compensate for the low 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 'Get the quest log for a character' clearly states the verb ('Get') and resource ('quest log'), specifying it's for a character. It distinguishes from siblings like 'get_quest' (which likely retrieves quest details) or 'list_quests' (which lists all quests), but doesn't explicitly differentiate 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., character must exist), exclusions, or compare to similar tools like 'get_quest' or 'list_quests', leaving usage context implied.
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 'DM view only', hinting at permission requirements, but fails to disclose other behavioral traits such as whether this is a read-only operation, potential rate limits, error handling, or what the output looks like. This leaves significant gaps for a tool that retrieves sensitive 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, efficient sentence with no wasted words. It is front-loaded with the core action and includes a contextual note ('DM view only'), making it appropriately sized and well-structured for quick understanding.
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 a secret (a sensitive operation), lack of annotations, 0% schema description coverage, and no output schema, the description is insufficient. It misses critical details like authentication needs, response format, and error conditions, making it incomplete for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID', which clarifies the purpose of 'secretId', but does not explain the semantics of 'sessionId' or provide any details on parameter formats, constraints, or interactions. This incomplete coverage results in a low score.
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 ('a single secret by ID'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_secrets' or 'get_secrets_for_context', which is why it doesn't reach a score of 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 includes 'DM view only', which provides some context about usage restrictions, but it lacks explicit guidance on when to use this tool versus alternatives like 'list_secrets' or 'get_secrets_for_context'. No exclusions or prerequisites are mentioned, leaving gaps in usage guidance.
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 hints at sensitive handling ('DO NOT REVEAL instructions') but doesn't disclose critical behavioral traits: whether this is a read-only operation, what permissions are needed, how secrets are formatted, or what the output looks like. For a tool handling secrets 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 front-loads the key information: action, resource, and formatting purpose. Every word earns its place with no redundancy or fluff.
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 (handling secrets for LLM context), lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't explain return values, error conditions, security implications, or how the 'DO NOT REVEAL' instruction is implemented. The agent lacks sufficient context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It provides no information about 'worldId' or 'sessionId'—their meaning, format, or how they affect the query. The description adds no parameter semantics beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'active secrets', and specifies the purpose 'formatted for LLM context injection with DO NOT REVEAL instructions'. It distinguishes from siblings like 'get_secret' (singular) and 'list_secrets' by focusing on active secrets for LLM context. However, it doesn't explicitly differentiate from all possible secret-related 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_secret' or 'list_secrets'. It mentions the formatting purpose but doesn't specify prerequisites, appropriate contexts, or exclusions. The agent must infer usage from the purpose 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 the full burden. It states the tool checks status but doesn't disclose behavioral traits like whether it's read-only, if it triggers side effects, response format, or error conditions. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, 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 (turn management in a game/world context), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what 'turn state' entails, what 'ready' means, or provide enough context for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the two parameters (worldId, sessionId), such as their purpose, format, or examples. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('current turn state and which nations are ready'). It distinguishes itself from siblings by focusing on turn status, though it doesn't explicitly differentiate from tools like 'get_turn_results' or 'poll_turn_results' which might have related functions.
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, timing (e.g., during turn resolution), or compare to siblings like 'poll_turn_results' or 'get_world_state', 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('Retrieve') without mentioning permissions, rate limits, response format, or any side effects. For a tool with zero annotation coverage, this is insufficient to inform the agent about how the tool behaves beyond its minimal purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it front-loaded and 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 implied by sibling tools (e.g., multiple world-related retrieval tools), the lack of annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't provide enough context to help an agent understand how this tool fits into the broader system or what to expect from its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, meaning neither 'id' nor 'sessionId' are documented in the schema. The description mentions 'by ID' which hints at the 'id' parameter, but it doesn't explain what a 'world ID' is, what format it uses, or what 'sessionId' is for. This leaves significant gaps in parameter understanding.
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 ('Retrieve') and resource ('a world by ID'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_world_state' or 'get_world_map_overview', which also retrieve world-related information, so it doesn't fully distinguish itself from 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. With many sibling tools like 'get_world_state' and 'get_world_map_overview', there's no indication of what makes this tool unique or when it should be preferred over other world-retrieval 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Add' implies a write operation, it doesn't specify whether this requires specific permissions, what happens if the character doesn't exist or the item is invalid, whether the addition is permanent or reversible, or any rate limits. 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, direct sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core action, 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 tool's mutation nature, 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't cover parameter meanings, behavioral implications like error conditions or side effects, or what the tool returns. For a tool that modifies game state, this leaves too much undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 4 parameters are documented in the schema. The description mentions 'character's inventory' and 'item', which loosely maps to 'characterId' and 'itemId', but doesn't explain what these IDs represent, what 'sessionId' is for, or the meaning of 'quantity' beyond its numeric constraint. It adds minimal semantic value beyond the bare 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 action ('Add') and target ('to a character's inventory'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'transfer_item' or 'batch_distribute_items' that might also add items to inventories, so it doesn't reach the highest 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 like 'transfer_item' or 'batch_distribute_items'. It also doesn't mention prerequisites such as needing a valid character or item, or whether the character must be alive/accessible. This leaves significant gaps in usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 a read operation ('List'), but doesn't disclose behavioral traits such as permissions needed, pagination, rate limits, or what happens if the encounter has no corpses. The description is minimal and lacks crucial 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 a single, efficient sentence with zero wasted words. It is front-loaded and appropriately sized for the tool's apparent simplicity.
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, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameters, return values, error conditions, and behavioral context, making it inadequate for a tool with two parameters in a complex gaming environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'from a combat encounter', which hints at the 'encounterId' parameter but doesn't explain its format or purpose. It ignores the 'sessionId' parameter entirely, failing to compensate for the low 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 ('List') and resource ('corpses'), specifying the scope ('from a combat encounter'). It distinguishes from sibling tools like 'list_corpses_nearby' by focusing on encounter-specific corpses, 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 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 'list_corpses_nearby' or 'get_corpse'. The description implies usage for encounter contexts but lacks explicit when/when-not instructions 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify whether it returns paginated results, the format of output (e.g., list of corpse IDs or full details), or any rate limits. For a tool with 5 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every part of the sentence earns its place by specifying the key elements of the operation.
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 (5 parameters, no schema descriptions, no annotations, no output schema), the description is incomplete. It doesn't address output format, error conditions, or dependencies like session validity. For a spatial query tool in a game/world context, more detail on what 'corpses' entails (e.g., decay state, inventory) and how results are structured would be necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal value. It mentions 'near a position' which loosely relates to 'x', 'y', and 'radius' parameters, but doesn't explain units (e.g., grid coordinates), the meaning of 'worldId' or 'sessionId', or default behaviors like the radius default of 3. With 5 parameters entirely undocumented in the schema, the description fails to provide adequate semantic context.
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 ('corpses near a position in the world'), making the purpose specific and understandable. It distinguishes from siblings like 'list_corpses_in_encounter' by specifying a spatial search around coordinates rather than encounter-based listing. However, it doesn't explicitly mention the world context or differentiate from other corpse-related tools like 'get_corpse' or 'cleanup_corpses' beyond the 'nearby' aspect.
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 like needing a valid world session, nor does it compare with siblings such as 'list_corpses_in_encounter' for encounter-specific searches or 'get_corpse' for single corpse retrieval. The lack of context leaves the agent to infer usage based on parameter names 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 trajectory, implying a read-only computation, but doesn't disclose behavioral traits like whether it's deterministic, has side effects, requires specific units, or handles errors. For a calculation 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 with zero waste. It's appropriately sized and front-loaded, directly stating the core 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 complexity (6 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how parameters interact, or any constraints, leaving significant gaps for a calculation tool with multiple inputs and options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 6 parameters. It mentions 'projectile motion' which hints at parameters like velocity and angle, but doesn't explain any parameters explicitly (e.g., what 'exportFormat' does, what 'sessionId' is for, or units for inputs). This fails to add meaningful semantics beyond the bare 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 'Calculate projectile motion trajectory' clearly states the verb ('calculate') and resource ('projectile motion trajectory'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'calculate_aoe' or 'measure_distance' that might involve similar calculations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context (e.g., physics simulations vs. game mechanics), or comparison to sibling tools like 'probability_calculate' or 'algebra_solve' that might handle related calculations.
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 'Propose' implies a diplomatic action, it doesn't specify whether this is a read-only or mutating operation, what permissions are required, what happens if an alliance already exists, or what the expected outcome/response might be. The description 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 6 words, with zero wasted language. It's front-loaded with the core action and target, making it immediately understandable despite its brevity.
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 diplomatic/mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain the tool's behavior, parameter meanings, expected outcomes, or error conditions. The description provides only the most basic functional statement without necessary contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters (2 required), the description provides no information about parameter meanings. It doesn't explain what 'fromNationId', 'toNationId', or 'sessionId' represent, their expected formats, or relationships between them. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Propose an alliance') and target ('to another nation'), providing a specific verb and resource. However, it doesn't distinguish this tool from potential sibling alliance-related tools (none are listed among siblings, but the description doesn't explicitly address this).
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, prerequisites, or constraints. It simply states what the tool does without context about appropriate usage scenarios or relationships to other tools in the system.
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 that the tool registers an NPC 'as a fence (buys stolen goods)', implying a write operation that modifies game state, but lacks details on permissions, side effects (e.g., NPC behavior changes), error conditions, or response format. This is insufficient for a mutation tool with 8 parameters.
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 is appropriately sized and front-loaded, directly stating 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 complexity (8 parameters, mutation operation, no annotations, no output schema), the description is incomplete. It lacks essential context such as parameter meanings, behavioral traits, usage scenarios, and expected outcomes, making it inadequate for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It adds no semantic context for any of the 8 parameters (e.g., what 'buyRate' means, how 'maxHeatLevel' affects gameplay). The baseline for high schema coverage would be 3, but here the description fails to provide any parameter insights.
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 ('register') and target resource ('an NPC as a fence'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'list_fences' or 'sell_to_fence', which would require explicit comparison to achieve a score of 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 offers no guidance on when to use this tool versus alternatives like 'list_fences' or 'sell_to_fence', nor does it mention prerequisites (e.g., NPC must exist, session must be active). It only states what the tool does, not when or why to invoke it.
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 performs a removal operation, implying it's destructive, but doesn't disclose behavioral traits such as permissions required, whether removal is permanent, error handling (e.g., if effect doesn't exist), or side effects (e.g., affecting target state). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to scan. Every word earns its place by specifying the removal method.
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 (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter interactions, return values, error conditions, or behavioral context needed for safe invocation. For a tool that likely modifies game state, this leaves critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by ID or by name,' hinting at parameters like effect_id and effect_name, but doesn't explain the other three parameters (target_id, target_type, sessionId) or their relationships (e.g., whether target_type is required with target_id). The description adds minimal value beyond 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 action ('Remove') and resource ('custom effect'), specifying it can be done 'by ID or by name.' It distinguishes from siblings like 'remove_aura' or 'remove_item' by focusing on custom effects, but doesn't explicitly differentiate from tools like 'advance_effect_durations' or 'process_effect_triggers' that might handle effects differently.
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 sessionId), when not to use it (e.g., for built-in effects), or refer to sibling tools like 'get_custom_effects' for listing effects first. The description is purely functional without 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. 'Remove' implies a destructive mutation, but the description doesn't specify whether this is reversible, what permissions are required, what happens to the character's items/status, or whether it triggers side effects. This leaves significant behavioral 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.
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 front-loaded with the core action and target, making it immediately understandable at a high level.
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 3 parameters (0% documented), no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after removal, what the tool returns, error conditions, or parameter requirements beyond the basic action statement. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 3 parameters, the description provides no information about what 'partyId', 'characterId', or 'sessionId' represent, their formats, or relationships. The description mentions 'party' and 'character' but doesn't map these to the actual parameters, leaving them completely undocumented.
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 ('a character from a party'), providing a specific verb+resource combination. It distinguishes from sibling 'add_party_member' by being the inverse operation, though this distinction isn't explicitly stated in the description itself.
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, prerequisites, or contextual considerations. It doesn't mention when removal is appropriate versus other character management operations like 'delete_character' or 'update_party_member'.
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 outcomes ('setting bounty and increasing detection chance') but lacks critical behavioral details: whether this is a read-only or mutating operation, if it requires specific permissions, what the response looks like, or any side effects (e.g., alerting NPCs). For a tool that likely modifies game state, 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 with zero waste. It front-loads the core action ('Report a theft to guards') and succinctly adds key outcomes. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a state-modifying tool with 4 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances, leaving the agent with insufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all four parameters. It only implies 'bountyOffered' via 'setting bounty' but doesn't explain 'reporterId', 'itemId', or 'sessionId'. The description adds minimal value beyond the schema, failing to clarify parameter meanings or usage context.
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 ('Report a theft') and the target ('to guards'), with specific outcomes ('setting bounty and increasing detection chance'). It distinguishes itself from siblings like 'check_item_stolen' or 'steal_item' by focusing on reporting rather than checking or performing theft. However, it doesn't explicitly differentiate from all possible siblings in the large list, keeping it at 4 instead of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after confirming a theft via 'check_item_stolen'), exclusions, or related tools like 'record_conversation_memory' for logging. With many siblings present, the lack of contextual usage advice is a significant gap.
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 states the tool performs a 'roll' but doesn't explain what happens during the roll (e.g., dice mechanics, modifiers applied), whether it's read-only or mutative, or any side effects. The mention of 'raw ability check' and 'uses only the ability modifier' adds some context but is insufficient for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and includes clarifying details ('no skill proficiency', 'uses only the ability modifier') that earn their place by adding specificity.
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 (7 parameters, no annotations, no output schema, low schema coverage), the description is inadequate. It lacks details on behavior, parameter usage, return values, and how it integrates with the system (e.g., what 'characterId' references). For a tool that likely involves game mechanics and multiple inputs, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 29%, with only 2 out of 7 parameters described in the schema. The description adds no parameter-specific information beyond the general 'ability modifier' hint, failing to compensate for the coverage gap. Parameters like 'advantage', 'disadvantage', 'dc', 'bonusModifier', and 'sessionId' remain unexplained in both schema and 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 ('Roll a raw ability check') and specifies the scope ('no skill proficiency', 'uses only the ability modifier'), which distinguishes it from general dice rolling. However, it doesn't explicitly differentiate from sibling tools like 'roll_skill_check' or 'roll_saving_throw', though the 'raw' and 'no skill proficiency' hints at this 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 minimal guidance by implying when to use it ('no skill proficiency'), but lacks explicit alternatives, prerequisites, or context for when to choose this over similar tools like 'roll_skill_check'. No when-not-to-use scenarios or comparisons to siblings 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 of behavioral disclosure. It states the tool sets the active character, implying a mutation, but fails to describe key behavioral traits such as permissions required, whether the change is reversible, effects on gameplay or other tools, or error handling. The prerequisite about membership is helpful but insufficient for a mutation 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 two sentences, front-loaded with the core purpose and followed by a key constraint. Every word earns its place with no redundancy or fluff, making it highly efficient and 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 a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameters, behavioral outcomes, error cases, and return values, leaving significant gaps for an AI agent to understand how to invoke and interpret results effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description does not explain any of the three parameters (partyId, characterId, sessionId), their meanings, or how they relate to the tool's purpose. It mentions 'character' and implies 'party' context but adds no specific semantics beyond what the parameter names suggest, failing to compensate for the low 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 ('Set the active character') and specifies the resource ('player's POV'), which is a character. It distinguishes the purpose from siblings like 'set_party_leader' or 'update_character' by focusing on viewpoint selection rather than leadership or character modification. However, it doesn't explicitly differentiate from all siblings, such as those managing character states, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('The character must already be a member'), which gives some context for when to use it. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., vs. 'set_party_leader' or 'update_character'), does not mention when not to use it, and offers no comparison to sibling tools. This results in minimal usage guidance.
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 a prerequisite but fails to disclose critical behavioral traits: whether this is a mutation (implied by 'Set'), permission requirements, side effects (e.g., on party dynamics), or error handling. This is inadequate for a tool that likely modifies state.
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—two short sentences with no wasted words. It is front-loaded with the core action, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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 state-mutating tool with 3 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is insufficient. It misses details on behavior, parameters, returns, and error cases, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any parameters (partyId, characterId, sessionId), their formats, or relationships. The prerequisite hint relates to characterId but lacks specifics. This leaves parameters largely undocumented.
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 ('Set') and the resource ('party leader'), making the purpose understandable. It distinguishes from siblings like 'add_party_member' or 'update_party' by focusing on leadership assignment. However, it doesn't specify the system context (e.g., RPG party management), 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 a prerequisite ('character must already be a member'), which offers some guidance. However, it lacks explicit when-to-use scenarios, alternatives (e.g., vs. 'update_party'), or exclusions, leaving the agent to infer context from sibling 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Create[s] a typed narrative note' implying a write operation, but doesn't describe permissions needed, whether creation is idempotent, error conditions, or what happens on success. For a mutation tool with 10 parameters, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently convey core functionality. The first sentence states the action and note types, while the second explains the purpose. No wasted words, though it could be more structured with explicit parameter guidance.
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 complex creation tool with 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation, how notes integrate with the narrative system, or provide examples of proper usage. The gap between what's needed and what's provided is significant.
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 60%, so the description must compensate but adds minimal parameter context. It mentions 'typed narrative note' and lists the five enum types, which aligns with the 'type' parameter, but doesn't explain other parameters like 'metadata', 'entityId', or 'sessionId'. The description provides some value but doesn't fully address the coverage gap.
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: 'Create a typed narrative note' with specific types listed (plot thread, canonical moment, NPC voice, foreshadowing, session log). It distinguishes the note's function for 'long-term narrative memory' but doesn't explicitly differentiate from sibling tools like 'update_narrative_note' or 'search_narrative_notes'.
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_narrative_note' or 'delete_narrative_note'. It mentions the tool is 'Used to build long-term narrative memory' but lacks explicit when/when-not instructions or prerequisites for creation.
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 is an 'Add' operation (implying mutation), but doesn't describe what happens on success/failure, whether duplicates are allowed, if position affects ordering, or any permission requirements. The description mentions the role parameter but doesn't explain behavioral differences between roles (e.g., leader privileges).
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 purpose. Every word earns its place - 'Add a character to a party' establishes the action, and the parenthetical role details provide necessary parameter context without redundancy. No wasted words or structural issues.
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 6 parameters (0% schema coverage), no annotations, and no output schema, the description is insufficient. It covers the basic purpose and one parameter's semantics but misses behavioral context, usage guidelines, and documentation for most parameters. The agent would struggle to use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly mentions the 'role' parameter with its enum values, adding semantic meaning beyond the bare schema. However, it doesn't explain the other 5 parameters (partyId, characterId, position, notes, sessionId), leaving them completely undocumented. The partial coverage of one parameter justifies a baseline score.
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 character to a party') and specifies the resource ('party') with the role parameter details. It distinguishes this tool from general character management tools like 'create_character' or 'update_character', but doesn't explicitly differentiate it from the sibling tool 'remove_party_member' or other party-related tools like 'update_party_member'.
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., party and character must exist), when not to use it (e.g., for updating existing members), or refer to related tools like 'update_party_member' or 'remove_party_member' that handle different party member 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 mentions 'Checks for level-up thresholds,' hinting at side effects, but doesn't disclose whether this triggers automatic level-ups, requires permissions, has rate limits, or what happens on 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?
Two concise sentences with zero waste: the first states the core action, the second adds key behavioral context. It's front-loaded 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.
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 incomplete. It lacks details on behavioral traits (e.g., side effects, error handling), parameter usage for 'sessionId,' and expected return values. The level-up check hint is helpful but insufficient for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (2 out of 3 parameters have descriptions). The description adds no parameter-specific details beyond the schema, which already documents 'characterId' and 'amount.' 'sessionId' lacks a schema description, and the tool description doesn't compensate, so baseline 3 is appropriate given partial 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 ('Add experience points') and target ('to a character'), with an additional function ('Checks for level-up thresholds'). It distinguishes from siblings like 'update_character' or 'level_up' by focusing specifically on XP addition with level-up checking, 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 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 like 'level_up' or 'update_character' (which might handle XP). The description implies usage for XP addition with level-up checks, but lacks context on prerequisites, timing, 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 for behavioral disclosure. It indicates a processing action that likely mutates game state (heat decay), but doesn't specify whether this is destructive, reversible, has side effects, requires permissions, or what the outcome looks like. 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 purpose without unnecessary 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 no annotations, no output schema, and 2 undocumented parameters, the description is inadequate. It doesn't explain what heat decay entails, how it affects stolen items, what the tool returns, or error conditions. Given the complexity implied by 'process' and sibling tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'when game time advances' which loosely relates to the 'daysAdvanced' parameter, but doesn't explain what 'daysAdvanced' means or the purpose of 'sessionId'. With 0% schema description coverage and 2 parameters, the description adds minimal value beyond what's implied by the tool name and context.
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 ('process heat decay') and target resource ('all stolen items') with a specific trigger ('when game time advances'). It distinguishes itself from sibling tools like 'advance_corpse_decay' by focusing on stolen items rather than corpses, but doesn't explicitly differentiate from other time-advancement 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?
The description implies usage when game time advances, but provides no guidance on when to use this versus alternatives like 'advance_turn' or 'advance_effect_durations', nor any prerequisites or exclusions. The context is clear but lacks comparative guidance.
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 states the action but fails to explain what 'advance' entails—whether it triggers combat actions, updates game state, requires specific conditions, or has side effects. This leaves significant gaps for a mutation tool in a combat 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 a single, clear sentence with no wasted words. It is front-loaded and efficiently conveys the core action, 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.
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 (advancing turns in combat), the description is inadequate given no annotations, no output schema, and incomplete parameter documentation. It lacks details on behavior, effects, or return values, leaving the agent with insufficient context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'encounterId' has a description). The tool description does not mention parameters at all, so it adds no semantic value beyond the schema. Since coverage is moderate, the baseline score of 3 applies, as the schema partially documents the parameters without description compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Advance to') and the target ('next combatant's turn'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'resolve_turn' or 'poll_turn_results', which prevents a score of 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?
No guidance is provided on when to use this tool versus alternatives such as 'resolve_turn' or 'poll_turn_results'. The description lacks context about prerequisites, timing, or exclusions, leaving the agent without usage 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 the full burden of behavioral disclosure. It states what the tool checks but doesn't describe how it behaves: whether it's a read-only check, what the output format is, if it has side effects (e.g., automatically breaking concentration), or any error conditions. 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.
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 purpose without unnecessary words. Every part of the sentence contributes directly to understanding what the tool does, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (checking concentration break conditions), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a boolean, detailed status), how to interpret results, or any dependencies on game state. For a tool that likely informs critical gameplay decisions, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (one of two parameters has a description). The description doesn't add any parameter-specific information beyond what's in the schema—it doesn't explain the semantics of 'characterId' or 'sessionId', their relationships, or provide examples. With partial schema coverage, the description doesn't compensate, so it meets the baseline for minimal 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 tool's purpose: to check if concentration should automatically break due to specific conditions (death, unconscious, stunned, paralyzed, petrified). It uses a specific verb ('check') and identifies the resource (concentration). However, it doesn't explicitly differentiate from sibling tools like 'break_concentration' or 'check_concentration_duration', which would be needed for a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a character in a concentration state), exclusions, or comparisons to related tools like 'break_concentration' or 'check_concentration_save'. The agent must infer usage from the purpose 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 the full burden of behavioral disclosure. It states the tool checks for 'potential secret leaks based on leak patterns,' implying a read-only analysis, but doesn't specify whether it requires authentication, has rate limits, what the output format is, or if it logs or stores the text. This leaves significant gaps for a tool handling sensitive 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, efficient sentence that front-loads the core purpose without unnecessary details. It earns its place by clearly stating what the tool does, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (handling sensitive text analysis), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain what constitutes a 'leak pattern', how results are returned, or any error handling, leaving the agent with inadequate context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only the 'text' parameter has a description). The tool description adds no additional parameter semantics beyond what the schema provides. It mentions 'text' implicitly but doesn't explain 'worldId' or 'sessionId'. With low schema coverage, the description fails to compensate, resulting in a baseline score.
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: 'Check if text contains potential secret leaks based on leak patterns.' It specifies the verb ('check'), resource ('text'), and criteria ('potential secret leaks based on leak patterns'). However, it doesn't explicitly differentiate from sibling tools, as no obvious sibling performs similar text analysis for leaks.
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 lacks context about prerequisites, such as when text should be checked (e.g., before sharing or storing), and doesn't mention any sibling tools that might handle related tasks like data validation or security scanning.
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 states this is a creation operation, implying it's a write/mutation tool, but doesn't mention permissions, side effects, or what happens on failure. It provides an example but no details on response format, error handling, or whether it's idempotent. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a helpful example. Both sentences are relevant and add value, with no wasted words. However, it could be slightly more structured by explicitly separating the purpose from the example.
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 (6 parameters including a nested object, no annotations, no output schema), the description is incomplete. It doesn't cover all parameters, lacks behavioral context for a mutation tool, and provides no information on return values or error conditions. This is inadequate for a tool with this level of 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?
The description lists 'name, seed, and dimensions' as parameters, which partially maps to the 6 parameters in the schema (name, seed, width, height, environment, sessionId). With 0% schema description coverage, the description adds some value by highlighting key fields, but it doesn't explain the optional 'environment' object or 'sessionId', leaving significant gaps. The example shows usage but lacks detailed semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new world') and specifies the resource ('in the database'), along with key attributes (name, seed, dimensions). It distinguishes from siblings like 'generate_world' or 'get_world' by focusing on database creation. However, it doesn't explicitly differentiate from 'generate_world' which might be a similar sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'generate_world' or 'update_world_environment'. It lacks context about prerequisites, such as whether a session must be initialized first, or any constraints on world creation. The example shows usage but doesn't explain 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 provided, the description carries full burden for behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't specify whether this is permanent, reversible, requires specific permissions, or what happens to related entities (items, quests, etc.). For a destructive operation 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 maximally concise - a single sentence with no wasted words. It's front-loaded with the core action and immediately states the required parameter. Every word serves a purpose in this minimal description.
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 deletion tool with no annotations, no output schema, and 2 parameters (one undocumented), the description is insufficient. It doesn't explain what 'delete' entails operationally, what validation occurs, what the response contains, or error conditions. The minimal description leaves too many questions unanswered for safe 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 0%, so the schema provides no parameter documentation. The description mentions 'by ID' which clarifies the purpose of the 'id' parameter, but doesn't address the 'sessionId' parameter at all. It adds some value for one of two parameters, but leaves the other completely unexplained.
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 target resource ('a character by ID'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'delete_item' or 'delete_world' which follow the same pattern, but the verb+resource combination is specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There's no mention of prerequisites (e.g., character must exist), consequences (e.g., what happens to associated data), or when not to use it. The description is purely functional without contextual guidance.
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. While 'Delete' implies a destructive mutation, the description doesn't disclose critical behavioral traits such as whether deletion is permanent, requires specific permissions, affects related data, or what happens on success/failure. This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It's appropriately sized and front-loaded, 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?
For a destructive tool with no annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It lacks details on behavior, error conditions, and output, leaving significant gaps for an AI agent to understand how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'itemId' has a description). The description adds no parameter semantics beyond what the schema provides—it doesn't explain 'itemId' further or clarify the purpose of 'sessionId'. With partial schema coverage, the description fails to compensate for the undocumented parameter.
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 ('item template'), making the purpose understandable. However, it doesn't distinguish this tool from other deletion tools like 'delete_character', 'delete_narrative_note', 'delete_party', 'delete_secret', or 'delete_world' that exist among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing item template), exclusions, or how it differs from similar tools like 'remove_item' or 'delete_character' in 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. 'End' implies a destructive/mutative action, but the description doesn't specify what 'ending' entails (e.g., does it archive data, trigger cleanup, or change state permanently?), nor does it mention permissions, side effects, or error conditions. This leaves significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero 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 mutation tool with no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is inadequate. It lacks details on behavior, outcomes, error handling, and usage context, leaving too much ambiguity for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'encounterId' has a description). The tool description adds no parameter information beyond what's in the schema—it doesn't explain the purpose of 'encounterId' or 'sessionId', their formats, or relationships. With moderate schema coverage but no compensatory details in the description, this meets the baseline.
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 ('the current combat encounter'), providing a specific verb+resource combination. However, it doesn't differentiate from potential siblings like 'resolve_encounter' or 'complete_encounter' that might exist in similar systems, though none are explicitly listed among the provided siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether an encounter must be active), exclusions, or related tools like 'create_encounter' or 'get_encounter_state' 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 implies a mutation (equipping changes state) but doesn't specify permissions, side effects (e.g., unequipping previous items), or error conditions. This leaves significant gaps for a tool that likely modifies character inventory.
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 without unnecessary words. It's appropriately sized for the tool's complexity, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters with 0% schema coverage, the description is incomplete. It doesn't address return values, error handling, or behavioral nuances needed for a mutation tool in a game context, leaving the agent under-informed.
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 0%, so the description must compensate, but it only mentions 'slot' implicitly without explaining parameters like 'characterId' or 'itemId'. It adds minimal meaning beyond the schema, which already defines enums for 'slot'. Baseline is adjusted due to low coverage, but the description doesn't fully compensate.
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 ('equip') and resource ('item') with the constraint 'in a specific slot', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'use_item' or 'give_item', which might involve items in different contexts, so it misses full sibling 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, such as 'unequip_item' or 'use_item', nor does it mention prerequisites like character ownership or item compatibility. It lacks explicit context or exclusions for usage.
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. It indicates a mutation operation ('remove') but doesn't disclose permissions needed, whether removal is reversible, what happens to associated effects, or error conditions. The behavioral context is minimal 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, efficient sentence that front-loads the core action. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and two parameters (one undocumented), the description is incomplete. It lacks details on permissions, side effects, return values, and error handling, which are crucial for safe invocation in a game management context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'currentRound' has a description). The tool description adds no parameter-specific information beyond what the schema provides. With two parameters and partial schema coverage, the description doesn't compensate for the gap, meeting the baseline for moderate 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 with a specific verb ('check for and remove') and resource ('auras that have exceeded their duration'). It distinguishes from siblings like 'get_active_auras' (read-only) and 'remove_aura' (manual removal), but doesn't explicitly name these 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 'remove_aura' or 'advance_effect_durations', nor does it mention prerequisites such as needing an active session or combat round tracking. Usage context is implied but not 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the description is 'immutable once created,' which is a crucial behavioral trait. However, it doesn't address other important aspects like what 'persistent' means in practice, whether this requires specific permissions, what happens on failure, or what the output looks like (since there's no output schema). For a creation 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 extremely concise—just one sentence with two clauses. It front-loads the core purpose and includes the optional feature without any wasted words. Every element 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.
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 (7 parameters, creation operation) and the lack of both annotations and an output schema, the description is insufficiently complete. It doesn't explain what 'persistent' entails, how rooms fit into the broader system (e.g., world or session context), what the tool returns, or error conditions. For a creation tool in what appears to be a game/world-building context, more contextual information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what's already in the schema. With 86% schema description coverage (high), the schema already documents most parameters well. The description's mention of 'immutable description' aligns with the 'baseDescription' parameter's schema description, but doesn't provide additional context. This meets the baseline of 3 when schema coverage is high.
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: 'Create a persistent room with immutable description. Optionally links to previous room.' It specifies the verb ('create') and resource ('persistent room'), and mentions the optional linking feature. However, it doesn't explicitly differentiate from sibling tools like 'create_world' or 'generate_terrain_patch', which might also create spatial elements.
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 that linking to a previous room is optional, but doesn't specify when to use this tool versus alternatives (e.g., 'create_world' for broader world-building or 'generate_terrain_patch' for terrain generation). No explicit when-not-to-use or prerequisite information 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates a world but doesn't explain what 'procedural' entails, whether this is a creation or modification operation, if it requires a session to be initialized, what the output looks like, or any side effects (e.g., overwriting existing worlds). For a tool with 7 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and key parameters, and one providing an example. It's front-loaded with the core functionality. However, the example could be more efficiently integrated, and it lacks structural elements like bullet points for clarity with multiple 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 complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior in context (e.g., how it relates to 'create_world' or session management), misses key parameter semantics, and provides no output information. For a world-generation tool in an RPG system, this leaves too many unknowns for effective 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?
The description mentions 'seed, width, and height parameters' and provides an example, adding some context beyond the schema. However, with high schema description coverage (86%), the schema already documents most parameters well. The description doesn't explain the purpose of 'landRatio', 'temperatureOffset', or 'moistureOffset', nor does it clarify the role of 'sessionId', leaving gaps for the 14% of parameters not covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate a new procedural RPG world' with specific parameters. It uses a specific verb ('generate') and resource ('RPG world'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'create_world' or 'generate_terrain_patch', leaving some ambiguity about when to choose this 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. It doesn't mention prerequisites, context (e.g., whether this initializes a session or modifies an existing world), or compare it to sibling tools like 'create_world' or 'generate_terrain_patch'. The example helps with syntax but doesn't address usage scenarios.
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 'based on their position', which adds some behavioral context about how auras are determined, but does not disclose other traits such as read-only vs. destructive, authentication needs, rate limits, or what the output looks like. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for the complexity of the tool.
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 has no annotations, no output schema, and incomplete parameter documentation (67% coverage), the description is insufficient. It lacks details on behavioral traits, output format, and does not fully address the gaps in parameter semantics, making it inadequate for a tool with three parameters in a complex 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 67% (two out of three parameters have descriptions). The description does not add any parameter-specific information beyond what the schema provides, such as explaining the meaning of 'position' or how 'sessionId' might be used. With moderate schema coverage, the baseline score of 3 is appropriate as the description does not compensate for the undocumented parameter.
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: 'Check which auras are currently affecting a specific character based on their position.' It uses a specific verb ('Check') and resource ('auras affecting a character'), but does not explicitly differentiate from sibling tools like 'get_active_auras' or 'get_character', which might provide overlapping or related 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 minimal usage guidance, mentioning 'based on their position' which implies context but does not specify when to use this tool versus alternatives like 'get_active_auras' or 'get_character'. No explicit when-not-to-use or prerequisite information is included.
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 mentions filtering by importance level but doesn't cover critical aspects like whether this is a read-only operation, what permissions are needed, how results are ordered, or if there's pagination beyond the 'limit' parameter. For a tool with 5 parameters and no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and key filtering capability. There's no wasted verbiage, and it directly communicates the essential information in a compact form.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the return format, error conditions, or behavioral traits like read/write nature. For a data retrieval tool in a rich sibling environment, more context is needed to guide the agent 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 80%, providing a baseline of 3. The description adds minimal value by mentioning 'Filter by minimum importance level,' which corresponds to the 'minImportance' parameter but doesn't elaborate beyond what the schema's enum already specifies. It doesn't explain the semantics of other parameters like 'sessionId' or 'characterId'/'npcId' relationships.
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 ('conversation history between PC and NPC'), making the purpose understandable. However, it doesn't distinguish this tool from potential siblings like 'get_recent_interactions' or 'get_event_history' that might also retrieve conversation-related data, 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 'get_recent_interactions' and 'get_event_history' that might overlap in functionality, there's no explicit or implied context for choosing this specific tool, leaving the agent without usage 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 the full burden. It mentions 'active effects' and 'optional filtering', but fails to disclose critical behavioral traits such as whether this is a read-only operation, what permissions are needed, how results are formatted, or any rate limits. This is inadequate for a tool with 6 parameters and 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.
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 purpose ('Get all active effects on a target') and adds a key detail ('with optional filtering'). There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 0% schema coverage, no annotations, no output schema), the description is insufficient. It doesn't explain return values, behavioral constraints, or parameter details, leaving significant gaps for an AI agent to understand how to use this tool effectively in context with many siblings.
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 some context by implying filtering based on effect activity and category/source, but with 0% schema description coverage, it doesn't fully compensate. It hints at 'optional filtering' which relates to parameters like 'category' and 'source_type', but doesn't explain their enums or the meaning of 'target_type' and 'include_inactive'. Baseline 3 is appropriate as the schema lacks descriptions, and the description provides only partial semantic 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') and resource ('all active effects on a target'), making the purpose evident. However, it doesn't explicitly differentiate from potential siblings like 'get_active_auras' or 'get_auras_affecting_character', which might handle similar effect/aura concepts, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'optional filtering' but lacks explicit when-to-use instructions, prerequisites, or alternatives. Given the many sibling tools, there's no mention of when to choose this over others like 'get_active_auras' or 'get_auras_affecting_character', 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves the 'current state' but doesn't specify what that state includes (e.g., character positions, health, effects), whether it's read-only or has side effects, or any performance considerations like caching. For a tool with no annotations, this leaves significant gaps in understanding its behavior and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core purpose, making it easy to parse quickly. There's no redundancy or fluff, and every word serves to convey essential information efficiently.
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 combat encounters in this system and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'state' entails (e.g., JSON structure, included fields like health or effects), how it relates to other encounter tools, or any error conditions. For a tool that likely returns detailed data, this minimal description 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?
Schema description coverage is 50%, with 'encounterId' documented but 'sessionId' not described. The description doesn't add any parameter-specific information beyond the schema, such as explaining the relationship between 'encounterId' and 'sessionId' or clarifying what 'active combat encounter' means in this context. Since the schema covers half the parameters adequately, the baseline score of 3 is appropriate, but the description doesn't compensate for the undocumented 'sessionId'.
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 state of the active combat encounter.' It specifies the verb ('Get') and resource ('current state of the active combat encounter'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_turn_status' or 'get_strategy_state', which might provide related encounter information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as requiring an active encounter, or compare it to siblings like 'get_turn_status' for turn-based details or 'get_strategy_state' for broader tactical context. This lack of context leaves the agent to infer usage, which is insufficient for effective tool selection.
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 mentions that the inventory is 'detailed' and sorted, but does not explain what 'detailed' entails (e.g., item stats, quantities, conditions), whether this is a read-only operation, if it requires specific permissions, or how errors are handled. For a tool with no annotations, 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 a single, efficient sentence: 'Get detailed inventory with full item info, sorted by equipped/type/name.' It is front-loaded with the core purpose and includes additional details without unnecessary words. Every part of the sentence contributes to understanding 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?
Given the complexity (inventory retrieval with sorting), lack of annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It does not explain what 'detailed' means, how sorting works, what the output format is, or any error conditions. For a tool that likely returns structured 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 two parameters (characterId and sessionId) with 0% description coverage, meaning the schema provides no semantic details. The description does not mention or explain these parameters at all, failing to compensate for the schema's lack of coverage. However, since there are only two parameters and the tool name implies character context, a baseline score of 3 is assigned, but the description adds no value beyond 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: 'Get detailed inventory with full item info, sorted by equipped/type/name.' It specifies the verb ('Get'), resource ('detailed inventory'), and scope ('full item info, sorted by equipped/type/name'). However, it does not explicitly differentiate from sibling tools like 'get_inventory' or 'get_corpse_inventory', which might offer different inventory views.
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 sibling tools such as 'get_inventory' or 'get_corpse_inventory', nor does it specify prerequisites like requiring a character to be loaded or in a specific state. Usage is implied by the name and parameters but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 retrieves details but doesn't disclose behavioral traits like permissions needed, error handling (e.g., if item doesn't exist), rate limits, or whether it's idempotent. For a read operation with no 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 action and resource, making it easy to parse quickly. Every word 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what 'details' include, error cases, or dependencies like session context. For a tool with 2 parameters and likely complex item data, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (itemId is described, sessionId is not). The description adds that retrieval is 'by ID,' which aligns with the itemId parameter but doesn't explain sessionId or provide additional context like ID format or examples. It partially compensates but doesn't fully address the coverage gap.
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 ('details of a specific item'), making the purpose unambiguous. It specifies retrieval by ID, which distinguishes it from list/search tools. However, it doesn't explicitly differentiate from similar 'get' tools like get_character or get_template, though the resource specificity helps.
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 a valid item ID), exclusions, or sibling tools like get_inventory or get_item_template that might be relevant. 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 the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover critical aspects like authentication needs, rate limits, error conditions, or what the output format looks like. This is a significant gap for a tool with potential dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place, with no redundant or vague phrasing, making it easy for an agent 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 (a read operation with dependencies like sessionId), lack of annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or how the tool integrates with other operations (e.g., session management), 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 50% (only 'level' has a description). The description adds that it retrieves 'XP needed for next level', which clarifies the purpose of the 'level' parameter but doesn't explain the 'sessionId' parameter or provide additional syntax details. This meets the baseline for partial schema coverage without fully compensating for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('level progression details'), specifying what information is retrieved. However, it doesn't differentiate from potential siblings like 'get_character' or 'get_party_context' that might also provide level-related data, 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., session initialization), exclusions, or related tools for similar data, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 what the tool returns but doesn't address important behavioral aspects like whether this is a read-only operation, permission requirements, rate limits, or how the aggregation works. The description is insufficient for a tool with 6 parameters and 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 efficiently structured in a single sentence that front-loads the core purpose. Every word contributes to understanding what the tool does, though it could potentially benefit from slightly more detail given the tool's complexity.
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 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the aggregation methodology, return format, error conditions, or how the various filtering parameters interact. The description leaves too many behavioral questions unanswered for effective 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?
The schema description coverage is 67%, and the description doesn't add any parameter-specific information beyond what's in the schema. It mentions the types of content returned (which maps to the 'includeTypes' parameter), but doesn't explain parameter interactions, defaults, or usage patterns. With moderate schema coverage, the baseline 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 verb ('Retrieve') and resource ('aggregated narrative context for LLM prompt injection'), and specifies the types of content returned (plot threads, canonical moments, NPC voices, foreshadowing). However, it doesn't explicitly differentiate from sibling tools like 'get_narrative_context' or 'search_narrative_notes'.
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_narrative_context' or 'search_narrative_notes'. There's no mention of prerequisites, appropriate contexts, or exclusions for usage.
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 'Retrieve' but doesn't clarify if this is a read-only operation, what permissions are needed, error handling, or response format. For a retrieval tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. There's no wasted verbiage, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't address behavioral aspects like safety, response structure, or error cases, 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 50% (only 'noteId' has a description). The description adds no parameter semantics beyond the schema, not explaining 'sessionId' or providing context like note ID format. With partial schema coverage, the description doesn't compensate for the undocumented parameter.
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 ('Retrieve') and resource ('a single narrative note'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get_narrative_context_notes' or 'search_narrative_notes', which also retrieve notes but with different scopes or filters.
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 sibling tools like 'search_narrative_notes' for broader queries or 'get_narrative_context_notes' for contextual retrieval, leaving the agent without 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves relationship status, implying a read-only operation, but doesn't clarify if it requires specific permissions, has side effects, or details the return format (e.g., structured data, error handling). For a 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, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 lack of annotations and output schema, the description is insufficient for a tool that likely returns complex relationship data. It doesn't explain what 'familiarity' and 'disposition' entail, how the data is structured, or potential error conditions. For a read operation in a rich gaming context, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add any parameter-specific information beyond what the input schema provides. Schema description coverage is 67% (two parameters described, one not), but the description doesn't compensate by explaining the purpose of 'sessionId' or clarifying the semantics of 'characterId' and 'npcId'. With moderate 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 tool's purpose: 'Get relationship status (familiarity, disposition) between a PC and NPC.' It specifies the verb ('Get'), resource ('relationship status'), and key attributes ('familiarity, disposition'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_npc_context' or 'update_npc_relationship', 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 no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, context (e.g., during gameplay, for narrative purposes), or exclusions. Given the many sibling tools, including 'get_npc_context' and 'update_npc_relationship', this lack of differentiation is a significant gap.
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 mentions verbosity levels and token ranges, which adds some context about output size. However, it doesn't describe what 'party context' includes (e.g., members, status, location), how the data is formatted, whether it's real-time or cached, or any permissions required. For a read operation with no annotations, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that directly state the purpose and key parameter details. Every word earns its place, with no wasted information or redundancy, 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 (a read operation with 3 parameters and no output schema) and the lack of annotations, the description is incomplete. It doesn't explain what 'party context' entails, how the output is structured, or any behavioral nuances like error handling or data freshness. Without an output schema, the description should ideally provide more details about the return values, but it fails to do so, leaving the tool's functionality ambiguous.
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 0%, so the schema provides no parameter descriptions. The description adds some value by explaining the 'verbosity' parameter with token ranges for each enum value ('minimal (~150 tokens), standard (~400), or detailed (~800)'). However, it doesn't clarify the semantics of 'partyId' or 'sessionId', leaving two of the three parameters poorly explained. This partial compensation results in a baseline score.
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 party context for LLM prompts.' It specifies the verb ('Get') and resource ('party context'), and mentions the target use case ('for LLM prompts'). However, it doesn't distinguish this tool from its many siblings, such as 'get_party' or 'get_party_members', leaving some ambiguity about what specific context is provided.
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 mentions verbosity levels but doesn't explain why one would choose this tool over other party-related tools like 'get_party' or 'get_party_members', nor does it specify any prerequisites or exclusions for its 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'unread events' but doesn't clarify what constitutes an event, how counts are calculated, if this is a read-only operation, or any performance considerations. This leaves significant gaps for a tool that likely interacts with event systems.
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 appropriately sized for a simple counting tool and front-loads the core functionality effectively.
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 event systems and the lack of annotations or output schema, the description is insufficient. It doesn't explain what 'events' are, how they're categorized as 'unread', what the return format looks like, or any error conditions, leaving the agent with incomplete context for proper tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (sessionId) with 0% description coverage. The tool description doesn't mention this parameter at all, failing to explain its purpose or necessity. However, with only one parameter and a baseline of 3 when schema coverage is low, the score reflects minimal but not helpful parameter context.
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 ('Get') and resource ('count of unread events in the inbox'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools, as there are no obvious counting or inbox-related siblings in the provided list, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or context. It simply states what the tool does without indicating if it's for monitoring, triggering actions, or other use cases, leaving the agent with no usage 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 the full burden of behavioral disclosure. It states the tool retrieves 'full details' but does not specify what those details include, whether it's a read-only operation, error handling for invalid IDs, or any performance considerations. The description is too vague to inform the agent about the tool's behavior beyond basic retrieval, leaving significant gaps in understanding.
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: 'Get a single quest by ID with full details.' It is front-loaded with the core purpose, has no redundant words, and every part of the sentence contributes essential information. This makes it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with 2 parameters (one required), 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It does not explain what 'full details' entails, how to handle the optional 'sessionId', or what the return format looks like. For a tool in a rich context with many siblings, more completeness is needed to guide 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 description mentions 'by ID', which aligns with the 'questId' parameter in the input schema, but does not explain the 'sessionId' parameter or provide any additional context beyond what the schema implies. With 0% schema description coverage, the description adds minimal value—it hints at the primary parameter but fails to compensate for the lack of schema documentation, resulting in a baseline score.
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 a single quest by ID with full details.' It specifies the verb ('Get'), resource ('quest'), and scope ('single quest by ID with full details'), which distinguishes it from sibling tools like 'list_quests' or 'get_quest_log'. However, it does not explicitly differentiate from similar retrieval tools like 'get_character' or 'get_world', which follow the same pattern, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid quest ID), exclusions, or comparisons to sibling tools like 'list_quests' for browsing or 'complete_quest' for updates. Without such context, the agent must infer usage from the tool name alone, which is insufficient for optimal selection.
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 implies a read-only operation ('Get'), but does not disclose behavioral traits such as permissions needed, rate limits, pagination, or what constitutes 'recent' (e.g., time-based or count-based). The description is minimal and lacks essential context for safe and effective use.
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 purpose without unnecessary words. It is appropriately sized for the tool's complexity, though it could benefit from additional context to improve completeness.
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 has no annotations, no output schema, and incomplete parameter documentation (67% coverage), the description is inadequate. It lacks details on return values, behavioral constraints, and usage guidelines, making it insufficient for a tool with 3 parameters in a complex server environment.
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 67% (2 out of 3 parameters have descriptions). The description does not add any meaning beyond the schema, as it does not explain parameters like 'characterId' or 'sessionId'. With moderate schema coverage, the baseline is 3, as the schema provides some documentation but the description does not compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('recent conversation memories across all NPCs') with a specific purpose ('for context building'). It distinguishes itself from siblings like 'get_conversation_history' by focusing on memories across NPCs rather than a specific conversation history, though the distinction could be more explicit.
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_conversation_history' or 'get_narrative_context'. It mentions 'for context building', but this is vague and does not specify prerequisites, exclusions, or comparative scenarios with sibling 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 the full burden of behavioral disclosure. It mentions the tool 'returns detailed information,' which implies a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or what 'detailed information' entails (e.g., format, pagination). For a tool with no annotations, 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.
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 purpose. It avoids unnecessary words and gets straight to the point. However, it could be slightly more structured by explicitly mentioning the parameters or usage context, but it's appropriately concise for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool retrieving detailed region data with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are formatted, or any prerequisites (e.g., session requirements). For a tool in a rich sibling set with no structured support, more context is needed 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 67% (2 out of 3 parameters have descriptions). The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain the meaning of 'regionId' or 'worldId' in context, nor does it clarify the optional 'sessionId'. With moderate schema coverage, the description doesn't compensate for gaps, resulting in a baseline score.
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: 'Returns detailed information about a specific region including its tiles and structures.' It specifies the verb ('returns'), resource ('region'), and scope ('tiles and structures'). However, it doesn't explicitly differentiate from sibling tools like 'get_world_map_overview' or 'get_world_tiles' that might provide similar map-related data, 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 related to maps and regions (e.g., 'get_world_map_overview', 'get_world_tiles', 'get_parties_in_region'), there's no indication of what makes this tool distinct or when it should be preferred over others. It only states what it does, not when to use it.
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 it's a read operation ('Get'), implying it's likely non-destructive, but doesn't specify permissions, rate limits, error conditions, or what the output includes (e.g., scroll properties, usability status). This leaves significant gaps for a tool with potential complexity.
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 efficiently conveys the essential information without 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.
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 detailed scroll information in a game context, the description is insufficient. With no annotations, no output schema, and incomplete parameter documentation, it fails to address key aspects like return values (e.g., scroll stats, effects), error handling, or how it differs from similar tools. This leaves the agent with inadequate 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?
Schema description coverage is 50%, with 'scrollItemId' documented but 'sessionId' lacking a description. The tool description doesn't add any parameter details beyond what the schema provides, such as explaining the format of 'scrollItemId' or the purpose of 'sessionId'. Since schema coverage is moderate, the baseline score of 3 is appropriate, but no extra value is added.
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 ('detailed information about a spell scroll item'), making the purpose explicit. However, it doesn't differentiate from sibling tools like 'get_item' or 'identify_scroll' which might also retrieve scroll information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_item' or 'check_scroll_usability'. It lacks context about prerequisites, such as needing a valid scroll ID or session, and doesn't mention any exclusions or specific scenarios for its 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read-only operation ('Get') but doesn't disclose permissions, rate limits, pagination, or response format. The mention of 'permanently learned' adds some context about data persistence, but overall behavioral traits are inadequately covered.
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 front-loads the core purpose ('Get all spells') and adds qualifying details ('permanently learned through Arcane Synthesis') without unnecessary elaboration, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema, no annotations), the description is incomplete. It lacks details on parameters, behavioral constraints, and return values, leaving significant gaps for an AI agent to understand how to invoke and interpret results 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 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'character_id', 'school', or 'sessionId' represent or how they affect results. The baseline is 3 because the schema provides structure (e.g., enum for 'school'), but the description fails to enhance understanding beyond this minimal schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('spells a character has permanently learned through Arcane Synthesis'), making the purpose specific and understandable. It distinguishes from general spell-related tools like 'get_spell_scroll' or 'use_spell_scroll' by focusing on synthesized spells, though it doesn't explicitly differentiate from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., character must exist), exclusions (e.g., not for temporary spells), or related tools like 'attempt_arcane_synthesis' for learning spells, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 this is a retrieval operation, implying read-only behavior, but doesn't disclose any behavioral traits like whether it requires authentication, has rate limits, returns structured data, or what 'current state' specifically includes. For a tool with no 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 with no 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, no output schema, and incomplete parameter documentation, the description is inadequate. It doesn't explain what 'current state' includes (e.g., narrative state, character positions, environmental conditions), leaving the agent guessing about the tool's full scope and return value.
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 50% (worldId has a description, sessionId does not). The description adds no parameter-specific information beyond what's in the schema. It doesn't explain what 'worldId' refers to in context or what 'sessionId' is used for. With moderate schema coverage, the baseline 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 ('Retrieves') and resource ('current state of the generated world'), making the purpose understandable. However, it doesn't distinguish this from similar sibling tools like 'get_world' or 'get_world_map_overview', which appear to retrieve different aspects of world 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. With many sibling tools that retrieve world-related information (e.g., get_world, get_world_map_overview, get_world_tiles), there's no indication of what makes this tool distinct or when it should be preferred.
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 'increment character level' and 'optionally update stats', implying a mutation, but doesn't disclose critical behaviors: whether this requires specific permissions, if it's irreversible, what happens to other stats (e.g., ability scores), or if it triggers side effects (e.g., level-up bonuses). The description is minimal and lacks necessary context for safe use.
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 ('Increment character level') and adds optional details. There's no wasted text, and it's appropriately sized for the tool's complexity. However, it could be slightly more structured by explicitly listing key parameters or outcomes.
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 with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., updated character object), error conditions, or behavioral nuances. For a level-up operation in a game context, more detail is needed to ensure correct 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 75%, with three parameters well-described (characterId, hpIncrease, targetLevel) and one undocumented (sessionId). The description adds minimal value beyond the schema by mentioning 'optionally update stats like HP', which loosely maps to hpIncrease, but doesn't explain sessionId or provide additional context (e.g., default behavior for targetLevel). Baseline 3 is appropriate given the 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 ('Increment character level') and the resource ('character'), and mentions optional stat updates ('optionally update stats like HP'). It distinguishes from siblings like 'add_xp' or 'update_character' by focusing specifically on level progression. However, it doesn't explicitly differentiate from all siblings, such as 'get_level_progression', which might be related.
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., requiring XP or meeting conditions), exclusions (e.g., not for NPCs), or compare to siblings like 'add_xp' or 'update_character' for stat adjustments. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 list operation with optional filtering, but doesn't mention whether this returns all characters in the system or is limited by permissions, whether results are paginated, what format the output takes, or any rate limits. For a list 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 functionality upfront. There's no wasted language or unnecessary elaboration - every word 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with 2 parameters (one undocumented), no annotations, and no output schema, the description is insufficient. It doesn't explain what the output looks like, whether there are limitations on what's returned, or how the 'sessionId' parameter affects results. The description provides basic functionality but 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 description mentions optional filtering by type, which corresponds to the 'characterType' parameter with its enum values. However, it doesn't mention the 'sessionId' parameter at all. With 0% schema description coverage (neither parameter has descriptions in the schema), the description adds some value but doesn't fully compensate for the undocumented 'sessionId' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('characters'), making the purpose immediately understandable. However, it doesn't differentiate this from similar sibling tools like 'get_character' (singular retrieval) or 'get_unassigned_characters' (filtered by assignment status), so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions optional filtering by type, but doesn't explain when filtering is appropriate or how this tool compares to other list/retrieval tools in the sibling set (e.g., 'list_corpses_in_encounter', 'list_parties').
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 a read operation ('List'), implying non-destructive behavior, but doesn't disclose any behavioral traits like pagination, rate limits, permissions required, or what 'all' entails (e.g., if it returns everything at once). This leaves significant gaps for an agent to understand how the tool behaves beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes to stating the tool's purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a listing tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior (e.g., return format, limitations), parameter usage, and differentiation from siblings, making it insufficient for an agent to fully understand the tool's context and operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with one parameter ('type') well-described and another ('sessionId') undocumented. The description adds no parameter semantics beyond what the schema provides, such as explaining the filter's effect or the purpose of 'sessionId'. Since schema coverage is moderate, the baseline is 3, as the description doesn't compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all item templates in the database'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_templates' or 'list_characters', which follow a similar pattern, so it doesn't fully distinguish itself from 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, such as 'list_templates' or 'search_items', nor does it mention prerequisites or exclusions. It lacks context for selection among similar listing tools in the server.
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 it's a list operation, implying read-only behavior, but doesn't cover aspects like pagination, return format, error conditions, or session requirements. For a tool with no annotations, 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, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently conveys the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address behavioral traits, return values, or parameter usage, making it inadequate for a tool that likely interacts with game data in a session context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('sessionId') with 0% schema description coverage. The description doesn't mention any parameters, so it adds no semantic value beyond the schema. With low coverage, the description fails to compensate, but the baseline is 3 since it doesn't mislead about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all registered loot tables'), making the purpose specific and understandable. It doesn't explicitly differentiate from siblings like 'get_loot_table' (which likely retrieves a specific table), but the scope distinction ('all' vs. specific) is implied.
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 siblings like 'get_loot_table' or 'generate_loot', nor does it specify prerequisites or contexts for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'DM view - shows hidden information,' which hints at permission requirements, but doesn't specify authentication needs, rate limits, pagination, or what 'hidden information' entails. For a read operation with sensitive data, 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?
Two concise sentences with zero waste. The first states the core purpose, and the second adds critical context about permissions and scope. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on authentication, return format, pagination, error handling, and how parameters interact. The 'DM view' hint is useful but insufficient for a tool handling sensitive 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?
Schema description coverage is 60% (3 of 5 parameters have descriptions). The description adds no parameter-specific details beyond what the schema provides (e.g., it doesn't explain 'worldId' format or 'type' filter options). With moderate schema coverage, the baseline 3 is appropriate as the description doesn't compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all secrets') and resource ('for a world'), with additional context about scope ('DM view - shows hidden information'). It doesn't explicitly differentiate from sibling tools like 'get_secret' or 'get_secrets_for_context', but the purpose is unambiguous.
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 'get_secret' (for a single secret) or 'get_secrets_for_context' (which might filter differently). The description mentions 'DM view' but doesn't clarify 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?
No annotations are provided, so the description carries the full burden. It states the tool lists templates and returns specific data, but does not disclose behavioral traits such as whether it's read-only (implied by 'List'), pagination, rate limits, authentication needs, or error handling. The description is minimal and lacks critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two clear sentences that state the purpose and return values without unnecessary details. However, it could be slightly more structured by explicitly separating purpose from output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter documentation (50% coverage), the description is insufficient. It lacks details on behavioral traits, error cases, and full parameter semantics, making it inadequate for a tool in a complex server with many siblings. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (one of two parameters has a description). The description does not add any parameter-specific information beyond what the schema provides (e.g., it does not explain 'category' filtering or 'sessionId' usage). With moderate schema coverage, the baseline score of 3 is appropriate as the description does not compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('workflow templates'), specifying what information is returned ('template names, descriptions, and required parameters'). It distinguishes from many siblings that perform different actions (e.g., 'create_template', 'execute_workflow'), but does not explicitly differentiate from other list tools like 'list_characters' or 'list_worlds' in terms of scope or filtering.
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, context for filtering (e.g., when to use the 'category' parameter), or compare it to other list tools (e.g., 'list_characters' for characters). Usage is implied only by the tool name and description.
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 loads an encounter but does not clarify whether this is a read-only operation, what data is returned, potential errors (e.g., if the encounter doesn't exist), or side effects. This leaves significant gaps for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficiently communicates the core purpose without redundancy or fluff, 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 a tool that loads data (likely with structured output), the lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It does not explain what 'loading' entails, the format of the returned data, or error conditions, leaving the AI agent with critical gaps in 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 50% (only 'encounterId' has a description). The tool description does not add any parameter-specific information beyond what the schema provides. With two parameters and partial schema coverage, the baseline score of 3 reflects that the description does not compensate for the undocumented 'sessionId' parameter.
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 ('a combat encounter from the database'), making the purpose immediately understandable. However, it does not differentiate this tool from potential siblings like 'get_encounter_state' or 'create_encounter', which would require more specific scope or 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. With many sibling tools related to encounters (e.g., 'create_encounter', 'end_encounter', 'get_encounter_state'), there is no indication of prerequisites, typical use cases, or distinctions from similar 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 the full burden. It mentions filtering for 'darkness, fog, and perception' and that it 'returns exits and entities', which adds some behavioral context. However, it lacks details on permissions, rate limits, error conditions, or whether this is a read-only operation (though 'Get' implies reading). For a tool 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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words. However, it could be slightly more structured by separating filtering details from return values.
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, no output schema, and 2 parameters with 50% schema coverage, the description is minimally adequate. It covers the tool's purpose and basic behavior but lacks details on usage, error handling, or output format. For a tool in a complex server with many siblings, this leaves gaps in contextual 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 50% (only 'observerId' has a description). The description doesn't add any parameter-specific information beyond what the schema provides. It implies context about observation but doesn't explain 'observerId' or 'sessionId' further. With partial schema coverage, the description doesn't compensate, so baseline 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 filtered room description accounting for darkness, fog, and perception. Returns exits and entities.' It specifies the verb ('Get'), resource ('room description'), and key filters. However, it doesn't explicitly distinguish this from sibling tools like 'get_room_exits' or 'get_narrative_context', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires an active session), exclusions, or compare it to siblings like 'get_room_exits' or 'get_narrative_context_notes'. The agent must infer usage from the purpose 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 the full burden of behavioral disclosure. It mentions the action ('move') and a side effect ('increment its visit count'), but fails to describe critical behaviors such as permission requirements, whether the move is reversible, error conditions (e.g., invalid IDs), or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 includes a secondary effect. There is no wasted verbiage or redundancy, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (moving a character and updating state) with no annotations, no output schema, and incomplete parameter documentation (67% coverage), the description is inadequate. It lacks details on behavioral traits, error handling, return values, and usage context, which are essential for an AI agent to invoke the tool correctly and safely.
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 67% (2 out of 3 parameters have descriptions), with 'characterId' and 'roomId' documented as UUIDs for the character and destination room. The description does not add meaning beyond this, as it does not explain the purpose of 'sessionId' (which lacks a schema description) or provide additional context like format examples or constraints. With moderate 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 ('Move a character to a room') and an additional effect ('increment its visit count'), which specifies what the tool does. However, it does not explicitly differentiate from sibling tools like 'move_party' or 'travel_to_location', which might involve similar movement concepts but for different entities or contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'move_party' for group movement or 'travel_to_location' for party-based travel. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is appropriate, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool 'Returns all effects that were triggered', which hints at read-only output, but doesn't clarify if it's a read operation, mutation, or has side effects like modifying game state. It lacks details on permissions, rate limits, or error handling, making behavioral traits insufficiently transparent.
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 purpose and includes a return value note. It avoids redundancy and waste, though it could be slightly more structured with separate usage or parameter hints to improve clarity 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 no annotations, no output schema, and 75% schema coverage, the description is incomplete. It doesn't explain the return format beyond 'all effects that were triggered', leaving output semantics vague. For a tool with 4 parameters and potential game-state implications, more context on behavior, errors, and output structure is needed 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 75%, with three parameters well-described and one ('sessionId') lacking a description. The tool description adds minimal value beyond the schema, mentioning 'target' and 'trigger' examples but not explaining parameter interactions or semantics. Baseline 3 is appropriate as the schema does most of the work, but the description doesn't compensate for the 25% coverage gap.
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: 'Process aura effects for a target at a specific trigger' with the verb 'process' and resource 'aura effects'. It specifies the action and resource but doesn't explicitly differentiate from siblings like 'process_effect_triggers' or 'get_auras_affecting_character', 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 no guidance on when to use this tool versus alternatives. It mentions triggers like 'start of turn, entering an aura' but doesn't specify prerequisites, exclusions, or compare it to sibling tools such as 'process_effect_triggers' or 'get_auras_affecting_character', 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fires triggers and returns activated effects, but lacks details on permissions needed, side effects (e.g., state changes), error handling, or rate limits. This is inadequate for a tool with 5 parameters and no output schema, leaving 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 a single, efficient sentence that front-loads the core purpose and includes a concise list of event examples. There is no wasted verbiage, 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.
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 (5 parameters, no annotations, no output schema), the description is insufficient. It lacks details on behavioral traits, parameter meanings beyond basic examples, and output expectations, failing to provide a complete picture for effective 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 low at 20%, with only the 'context' parameter having a description. The tool description adds minimal value by listing example events (e.g., 'start_of_turn', 'on_attack'), which partially clarifies the 'event' parameter but doesn't explain 'target_id', 'target_type', or 'sessionId'. This compensates slightly but not fully for the coverage gap.
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 ('Fire effect triggers') and the resource ('at specific events'), with examples provided. It distinguishes from many siblings by focusing on effect processing rather than creation, deletion, or state retrieval, though it doesn't explicitly differentiate from similar tools like 'process_aura_effects' or 'advance_effect_durations'.
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 mentions event types but doesn't specify prerequisites, timing constraints, or compare it to related tools like 'process_aura_effects' or 'apply_custom_effect', leaving usage context implied 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 the full burden of behavioral disclosure. It implies a write operation ('Record') but doesn't state whether this requires permissions, if it's idempotent, what happens on failure, or how the memory is stored/retrieved. The importance levels add some context, but critical behavioral traits like side effects or error handling are missing.
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 ('Record a significant conversation/interaction') and adds brief elaboration on importance. There's no wasted text, but it could be slightly more structured (e.g., separating usage hints). Overall, it's appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with 6 parameters), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'recording' entails (e.g., storage format, retrieval methods), error conditions, or return values. For a tool that likely modifies game state, more behavioral and contextual details are needed to guide the agent 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 83% (high), so the baseline is 3 even without parameter details in the description. The description only mentions 'importance' with examples ('low (chat), medium, high (plot), critical'), which adds minimal value beyond the schema's enum and description. It doesn't explain other parameters like 'characterId' or 'topics', but the schema adequately covers them.
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 ('Record') and resource ('significant conversation/interaction'), making the purpose understandable. It distinguishes from siblings like 'add_narrative_note' by focusing on conversations rather than general notes, but doesn't explicitly contrast with tools like 'get_conversation_history' or 'get_recent_interactions', which are read operations. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions importance levels (e.g., 'low (chat), medium, high (plot), critical') but doesn't specify scenarios or prerequisites, nor does it reference sibling tools like 'add_narrative_note' for non-conversation contexts. Without explicit usage context, the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 operation, it doesn't specify whether this is permanent deletion, transfer to another location, or temporary removal. No information about permissions, side effects, or what happens when quantity exceeds inventory count 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?
The description is a single, efficient sentence that immediately communicates the core function. There's no wasted verbiage or unnecessary elaboration, making it easy to parse while conveying the essential action.
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 operation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't address critical questions about the nature of the removal, error conditions, return values, or how it differs from similar inventory management tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description doesn't add any parameter-specific information beyond what's implied by the tool name. The baseline is 3 since the description doesn't compensate for the schema gap, but it doesn't actively mislead about parameters either.
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 ('an item from a character's inventory'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'delete_item' or 'steal_item', but the specific context of character inventory provides some 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 like 'delete_item', 'transfer_item', or 'steal_item'. There's no mention of prerequisites, appropriate contexts, or what distinguishes this removal operation from other inventory modifications.
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 mentions the output requirement ('Include the spoilerMarkdown field'), which is useful, but does not cover critical aspects like whether this action is read-only or mutative, if it requires specific permissions, or what happens to the secret after revelation (e.g., is it marked as revealed?). For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action ('Reveal a secret to the player') and adds a necessary output instruction. There is no wasted text, but it could be slightly more structured by separating usage from output requirements.
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 tool that reveals secrets, likely involving game state changes), no annotations, no output schema, and only 50% schema coverage, the description is incomplete. It lacks details on behavioral traits, error conditions, or what the tool returns beyond the spoilerMarkdown hint. For a tool with four parameters and potential mutative effects, this is inadequate.
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 50% (two of four parameters have descriptions: 'triggeredBy' and 'partial'), so the baseline is 3. The description does not add any parameter-specific details beyond what the schema provides, such as explaining 'secretId' or 'sessionId' usage. It compensates minimally by implying parameters are needed for the reveal, but no extra semantics are given.
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 ('reveal a secret to the player') and resource ('secret'), making the purpose understandable. However, it does not explicitly differentiate from sibling tools like 'get_secret' or 'check_reveal_conditions', which might retrieve or verify secrets without revealing them to players, so it lacks full sibling 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 such as 'get_secret' or 'check_reveal_conditions'. It mentions including 'spoilerMarkdown field in your response', but this is an output instruction, not usage context. No exclusions or prerequisites are 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions applying proficiency bonus, it doesn't describe the actual rolling mechanics (e.g., d20 roll plus modifiers), doesn't specify what the output looks like (success/failure, total roll), and doesn't mention any side effects or constraints. For a tool with 7 parameters and no 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 extremely concise - just two sentences that directly state the tool's purpose and key behavior. Every word earns its place, and the information is front-loaded with no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, no output schema, and only 43% schema description coverage, the description is inadequate. It doesn't explain the rolling mechanics, output format, parameter interactions (e.g., how advantage/disadvantage work together), or provide usage context. The conciseness comes at the expense of 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?
Schema description coverage is only 43%, meaning most parameters lack documentation in the schema. The description mentions 'character' and 'save proficiency' which relates to characterId and ability parameters, but doesn't explain the other 5 parameters (advantage, disadvantage, dc, bonusModifier, sessionId). The description adds minimal value beyond what the sparse schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Roll a saving throw') and specifies that it applies proficiency bonus if the character has save proficiency. It distinguishes from generic dice rolling tools like 'dice_roll' by focusing on saving throws specifically, though it doesn't explicitly differentiate from similar ability/check tools like 'roll_ability_check' or 'roll_skill_check'.
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 are several related rolling tools in the sibling list (roll_ability_check, roll_skill_check, roll_death_save, check_concentration_save), but the description doesn't indicate when this specific saving throw tool is appropriate versus those other options.
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 describes the search functionality but does not cover important traits such as whether the search is paginated, what the output format looks like (no output schema), if there are rate limits, or authentication requirements. The description is minimal and misses key 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 extremely concise—a single sentence that directly states the tool's function without unnecessary words. It is front-loaded and efficient, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavior, output format, and usage context. While concise, it does not provide enough information for an agent to fully understand how to invoke the tool effectively or interpret 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?
The description adds some semantic context by mentioning searchable attributes ('name, type, or value range'), which aligns with the input schema parameters. However, with 80% schema description coverage, the schema already documents most parameters well. The description does not explain the 'sessionId' parameter or provide additional details beyond what the schema offers, 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: 'Search for items by name, type, or value range.' It specifies the verb ('search') and resource ('items'), and mentions the searchable attributes. However, it does not explicitly differentiate from sibling tools like 'list_items' or 'get_item', which might offer alternative ways to retrieve items.
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 sibling tools like 'list_items' (which might list all items without filtering) or 'get_item' (which might retrieve a specific item by ID), nor does it specify prerequisites such as requiring a sessionId or other context. Usage is implied by the search functionality but lacks explicit 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 mentions 'Returns matching notes for context building,' which hints at read-only behavior and output purpose, but lacks critical details: whether it's paginated (limit parameter exists but not explained), if it requires specific permissions, rate limits, or error conditions. For a search tool with 10 parameters, 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 a single, efficient sentence that front-loads the core functionality. It avoids redundancy and wastes no words, though it could be slightly more structured (e.g., separating search from return purpose). Overall, it's appropriately concise for a search tool.
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 (10 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like pagination, permissions, or error handling, and while the schema covers parameters, the description lacks context on when and how to use the tool effectively. For a search operation in a narrative system, more guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema documents most parameters well. The description adds minimal value beyond the schema: it lists filtering criteria (type, status, tags, text content) that align with parameters, but doesn't explain semantics like AND logic for tags (covered in schema) or how query interacts with other filters. Baseline 3 is appropriate as the schema does 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: 'Search and filter narrative notes by type, status, tags, or text content.' It specifies the verb ('search and filter'), resource ('narrative notes'), and filtering criteria. However, it doesn't explicitly differentiate from sibling tools like 'get_narrative_note' or 'get_narrative_context_notes', which appear to be related read operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a worldId), exclusions, or comparisons to siblings like 'get_narrative_note' (single note retrieval) or 'get_narrative_context_notes' (context-specific notes). Usage is implied only by the description's focus on searching/filtering.
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 real-time events and JSON-RPC notifications, but lacks critical details: whether this establishes a persistent connection, authentication requirements, rate limits, how events are delivered, or what happens if the session ends. For a subscription 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that convey core functionality. It's front-loaded with the main purpose, though it could be more structured by separating subscription mechanics from delivery format. No wasted words, but could benefit from slightly more detail given the tool's complexity.
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 (real-time subscription), lack of annotations, no output schema, and 0% schema description coverage, the description is insufficient. It doesn't explain what happens after subscription, how events are received, error conditions, or relationship to other event tools. For a subscription mechanism in a gaming/DM system, this leaves too many unknowns.
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 0%, so the schema provides no parameter documentation. The description doesn't mention either parameter ('topics' or 'sessionId'), leaving their purpose and usage completely unexplained. However, since there are only 2 parameters and one is optional, the baseline is 3 for minimal viability, though the description adds no value beyond 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: 'Subscribe to real-time events on world or combat topics' specifies the verb (subscribe), resource (events), and topic scope (world/combat). However, it doesn't explicitly distinguish from its sibling 'unsubscribe_from_events' or other event-related tools, 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. It mentions 'Events sent as JSON-RPC notifications' but doesn't explain when subscription is appropriate, what happens after subscribing, or how it relates to tools like 'poll_events' or 'get_event_history' in 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Returns DSL script for easy application,' which adds some context about the output format. However, it lacks critical details: it doesn't specify whether this is a read-only or mutative operation, what permissions are required, how suggestions are generated (e.g., algorithmic constraints), or any rate limits. For a tool with no annotations, 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 highly concise and front-loaded: two sentences that directly state the tool's function and output. There is zero waste or redundancy, 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.
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 (batch processing of POI locations with multiple parameters) and lack of annotations and output schema, the description is incomplete. It mentions the output is a 'DSL script' but doesn't describe its structure or how to apply it. For a tool with no behavioral transparency and moderate parameter coverage, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with parameters like 'worldId' and 'requests' having descriptions, but 'sessionId' lacks one. The description adds no specific parameter semantics beyond what the schema provides—it doesn't explain the meaning of 'POI types' in context, the implications of 'nearWater' or 'preferredBiomes', or how the DSL script relates to inputs. With moderate schema coverage, the baseline is 3, as the description doesn't compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Batch suggest locations for multiple POI types at once.' It specifies the verb ('suggest'), resource ('locations'), and scope ('multiple POI types at once'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'find_valid_poi_location' (which might handle single POI requests), so it misses full sibling 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 mentions 'batch suggest' but doesn't clarify scenarios where batch processing is preferred over single POI tools or other location-related operations. There are no exclusions, prerequisites, 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.
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 restorative effect (HP to maximum) and future spell slot restoration, but misses critical behavioral details: whether this consumes resources, triggers events, affects other characters, has cooldowns, or requires specific conditions (e.g., not in combat). For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action and effect. The second sentence about future enhancements is somewhat speculative but not wasteful. It could be more structured by separating current and future behaviors, but overall it's efficient.
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 game-state impact), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It omits critical context such as side effects, error conditions, return values, and interaction with other game mechanics (e.g., time advancement, event triggers).
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 50% (only 'characterId' has a description). The tool description adds no parameter-specific information beyond what the schema provides. With 2 parameters and partial schema coverage, the description fails to compensate for the undocumented 'sessionId' parameter, resulting in a baseline score of 3 due to adequate but incomplete documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a long rest') and its primary effect ('Restores HP to maximum'), with a future enhancement mentioned. It distinguishes from sibling 'take_short_rest' by specifying duration (8 hours vs. short rest's typical 1 hour), though not explicitly named. However, it doesn't fully differentiate from 'rest_party' (which might handle group rests).
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 like 'take_short_rest' or 'rest_party' is provided. The description implies usage for healing HP, but lacks context on prerequisites (e.g., safe location), timing constraints, or trade-offs (e.g., time passage effects).
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 spending hit dice to recover HP, which implies a mutation effect, but doesn't address other behavioral aspects like whether this consumes resources permanently, requires specific character states, has cooldowns, or what happens if invalid parameters are provided. 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 extremely concise—two short sentences that directly state the tool's purpose and key mechanic. Every word earns its place with zero waste, and it's front-loaded with the core action. This is a model of efficiency in tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (implied by 'spend' and 'recover') with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, what side effects occur, error conditions, or how it interacts with other game systems. For a tool that modifies character state in a complex gaming environment, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67% (2 out of 3 parameters have descriptions), so the baseline is 3. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain the relationship between hit dice spent and HP recovered, clarify the purpose of sessionId, or provide examples. It relies entirely on the schema for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a short rest') with a specific duration (1 hour) and purpose ('Spend hit dice to recover HP'), making the verb+resource explicit. However, it doesn't distinguish this from its sibling tool 'take_long_rest' or other rest-related tools like 'rest_party', leaving room for improvement in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'take_long_rest' or 'rest_party', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage instructions, leaving the agent to infer when this specific rest type 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?
No annotations are provided, so the description carries the full burden. It states the tool performs a transfer but doesn't disclose behavioral traits such as whether it requires specific permissions, if it's reversible, what happens on failure, or any rate limits. The description is minimal and lacks crucial 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 a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized for the complexity, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a transfer operation with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't cover behavioral aspects, error conditions, or what the tool returns, leaving significant gaps for an AI agent to understand how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, with clear descriptions for most parameters in the schema. The description adds no additional meaning beyond the schema, as it doesn't explain parameter interactions, constraints, or provide examples. Baseline 3 is appropriate given the 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 ('transfer') and resource ('item') with the context of moving between characters. It's specific about what the tool does, though it doesn't explicitly differentiate from sibling tools like 'give_item' or 'steal_item' which might have overlapping functionality.
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 'give_item' or 'steal_item' from the sibling list. It lacks context about prerequisites, restrictions, or typical scenarios for transferring items between characters.
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 only states the action without behavioral details. It does not disclose effects like stopping event streams, whether it's idempotent, permission requirements, or error handling, which are critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently conveys the core action 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 no annotations, no output schema, and a mutation tool with behavioral implications, the description is incomplete. It lacks details on effects, return values, error cases, or integration with event systems, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% with one parameter ('sessionId'), and the description adds no parameter information. Since the parameter count is low (1) and the schema provides basic structure, this meets the baseline of 3, but the description fails to explain the parameter's role or necessity.
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 ('unsubscribe') and the target ('all event topics'), which is specific and unambiguous. However, it does not differentiate from its sibling tool 'subscribe_to_events' beyond the opposite action, lacking explicit comparison or scope details that would warrant 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 on when to use this tool versus alternatives or prerequisites. It does not mention the sibling 'subscribe_to_events' for context, nor does it specify conditions like after session setup or to stop event polling, 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?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions updating an existing note and a common use case, but fails to describe critical aspects such as permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields. This is inadequate for a mutation 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 brief and front-loaded with the core purpose, followed by a common use example. Both sentences are relevant and contribute to understanding, with no wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, mutation operation, no annotations, no output schema), the description is insufficient. It lacks details on behavioral traits, error conditions, return values, and comprehensive usage guidelines, making it incomplete for effective 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?
The schema description coverage is 71% (5 out of 7 parameters have descriptions), which is moderately high. The description adds minimal value by hinting at 'marking a plot_thread as resolved' (related to the 'status' parameter), but does not provide additional semantics beyond what the schema already documents. This meets the baseline for adequate 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 ('Update') and resource ('existing narrative note'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'add_narrative_note' or 'delete_narrative_note', which would be needed for a score of 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 a 'Common use' example ('marking a plot_thread as resolved'), which implies some context but does not offer explicit guidance on when to use this tool versus alternatives (e.g., when to update vs. add or delete a note) or any prerequisites. This leaves gaps in usage 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 'Update or create', implying mutation, but doesn't disclose behavioral traits like required permissions, whether it overwrites existing data, error conditions, or side effects. The familiarity progression hint adds minimal context but lacks operational details. 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 extremely concise—two sentences with zero waste. The first sentence states the purpose, and the second provides a helpful hint about familiarity levels. It's front-loaded 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.
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 6 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context, usage guidelines, and details on return values or errors. The high schema coverage helps, but for a mutation tool, more guidance is needed to ensure correct agent 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 83% (high), so the baseline is 3. The description adds no parameter semantics beyond what the schema provides—it mentions 'Familiarity' with an enum progression, but the schema already documents this with enum values and description. No additional syntax, format, or usage details are given for 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 ('Update or create') and the resource ('PC-NPC relationship'), providing a specific verb+resource combination. It distinguishes from siblings by focusing on relationship management, unlike tools like 'update_character' or 'get_npc_relationship'. However, it doesn't explicitly differentiate from potential similar tools not in the list, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when not to use it, or reference sibling tools like 'get_npc_relationship' for checking existing relationships or 'interact_socially' for social interactions. The agent must infer usage from the purpose 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. It implies a mutation operation ('Update') but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error handling, or side effects. The description is minimal and lacks critical 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.
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 verbiage, though it could be slightly more structured (e.g., separating required vs. optional 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?
For a mutation tool with 7 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It lists some updatable fields but misses critical context like the required 'partyId', behavioral expectations, or result format. The agent would struggle to use this tool correctly without additional 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 0%, so the schema provides no parameter descriptions. The description lists five properties (name, description, location, formation, status) which correspond to some of the 7 parameters, adding some semantic value. However, it doesn't cover 'partyId' (required) or 'sessionId', leaving gaps in parameter understanding.
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 ('party properties'), and lists specific fields (name, description, location, formation, status). It doesn't distinguish from sibling tools like 'update_party_member' or 'update_character', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_party_member' or 'create_party'. It mentions what properties can be updated but doesn't provide context about prerequisites, constraints, or typical use cases.
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. While 'Update' implies a mutation, it doesn't specify required permissions, whether changes are reversible, error conditions, or what the response looks like. This leaves significant gaps for a tool that modifies party member 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, efficient sentence that front-loads the core functionality without any wasted words. It's appropriately sized for the tool's 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 mutation tool with 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It lacks details on behavior, parameter interactions, and expected outcomes, leaving too much uncertainty 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 description mentions 'role, position, or notes', which maps to three of the seven parameters (role, position, notes). With 0% schema description coverage, this adds some value, but it doesn't cover the other parameters (partyId, characterId, sharePercentage, sessionId) or explain their relationships, resulting in incomplete compensation.
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 ('Update') and target ('a party member's role, position, or notes'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_character' or 'set_party_leader', 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 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' or 'set_party_leader', nor does it mention prerequisites or constraints. It simply states what the tool does without context for selection.
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 implies a mutation ('Update') but doesn't disclose behavioral traits such as required permissions, whether changes are reversible, side effects (e.g., affecting gameplay), or response format. 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 no wasted words. It front-loads the core action and resource, making it easy to scan. Every part of the sentence earns its place by specifying the tool's 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?
Given the complexity (mutation tool with nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions or effects, and parameter documentation is insufficient. For a tool that modifies world state, more context is needed to ensure 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 0%, so the schema provides no parameter descriptions. The description adds some value by listing examples of environmental properties (time, weather, lighting, etc.), which maps to the 'environment' object's nested properties. However, it doesn't explain the 'id' or 'sessionId' parameters, leaving them undocumented. Baseline is 3 as it partially compensates but not fully.
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 the resource 'environmental properties for a world', specifying the types of properties (time, weather, lighting, etc.). It distinguishes from siblings like 'update_character' or 'update_item' by focusing on world-level environmental settings, though it doesn't explicitly contrast with similar tools like 'update_terrain'.
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 world ID), exclusions, or related tools like 'update_terrain' or 'create_world' for context. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool removes the item from inventory and applies effects, which covers basic behavior. However, it lacks details on permissions needed, whether effects are reversible, error conditions (e.g., invalid target), or rate limits, leaving significant 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action and effects. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It covers the basic action but lacks critical context like return values, error handling, or behavioral nuances (e.g., cooldowns, validation rules), which are essential for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with three parameters documented (characterId, itemId, targetId) and one undocumented (sessionId). The description adds no parameter-specific semantics beyond what the schema provides, such as explaining 'targetId' usage or 'sessionId' purpose, so it meets 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 ('use') and resource ('consumable item'), specifying that it removes the item from inventory and applies effects. It distinguishes from siblings like 'equip_item' or 'give_item' by focusing on consumption, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'equip_item' for equipment, 'give_item' for transfers, or 'use_spell_scroll' for scrolls). The description implies usage for consumables but lacks explicit context 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?
With no annotations provided, the description carries the full burden. It discloses that deletion affects members (they become unassigned but not deleted), which is valuable behavioral context. However, it doesn't mention permissions needed, whether deletion is reversible, error conditions, or what happens to other party-associated data like quests or inventory.
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—two brief sentences that directly state the action and a key behavioral consequence. Every word earns its place with no redundancy 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 destructive operation with no annotations and no output schema, the description is insufficient. It lacks critical information: what permissions are required, whether the action is reversible, error handling, confirmation of deletion, or what happens to party-related data beyond members. The behavioral note about members is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so parameters 'partyId' and 'sessionId' are undocumented. The description adds no information about what these parameters mean, their format, or how they're used. It doesn't compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a party'), making the purpose immediately understandable. It distinguishes from sibling tools like 'delete_character' or 'delete_world' by specifying the party resource, 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. It doesn't mention prerequisites, conditions, or what happens to related entities beyond members becoming unassigned. There's no comparison to similar tools like 'delete_character' or context for when deletion 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 the full burden of behavioral disclosure. It states the tool executes actions but doesn't describe what happens after execution (e.g., turn progression, state changes, error handling), whether it's idempotent, or any side effects. The examples show input structures but no behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. The initial statement is clear, but the extensive examples (5 JSON blocks) dominate the description. While helpful, they could be more efficiently integrated or referenced. The content earns its place but could be more front-loaded with critical usage 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 (13 parameters, no output schema, no annotations), the description is partially complete. The examples provide valuable context for parameter usage, but there are significant gaps: no information about return values, error conditions, or how this tool integrates with the broader combat/turn system. It's adequate for basic understanding but lacks comprehensive 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?
With schema description coverage at only 46%, the description compensates significantly by providing detailed examples that illustrate parameter usage across different action types. The examples clarify which parameters are needed for specific actions (e.g., targetId for attack/heal, targetPosition for move), adding substantial semantic value beyond the sparse schema 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 as 'Execute a combat action' and lists specific action types (attack, heal, move, cast_spell, etc.), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from sibling combat-related tools like 'execute_lair_action' or 'submit_turn_actions', 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 no guidance on when to use this tool versus alternatives. While examples show different combat actions, there's no mention of prerequisites, timing constraints, or when to choose this over other combat or turn-management tools in the extensive sibling list. The examples imply usage but don't provide explicit guidelines.
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 mentions the condition 'if they are dead,' which implies the tool may return null or an error for living characters, but it doesn't specify error handling, return format, or other behavioral traits like permissions or rate limits. This leaves significant gaps for a tool that likely involves data retrieval.
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: 'Get the corpse of a specific character (if they are dead).' It's front-loaded with the core purpose and includes a key condition without unnecessary words, making it appropriately sized and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving character-specific data, the lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what 'corpse' entails (e.g., inventory, decay state), how to handle missing data, or the return structure, leaving too many unknowns for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, meaning the schema provides no semantic information. The description doesn't add any details about the parameters (characterId, sessionId), such as what they represent, their formats, or why sessionId might be optional. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get the corpse of a specific character (if they are dead).' It specifies the verb ('Get'), resource ('corpse'), and condition ('if they are dead'), making it clear what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_corpse' or 'list_corpses_in_encounter,' which slightly reduces clarity.
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 guidelines through the condition 'if they are dead,' suggesting the tool should only be used when a character is deceased. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_corpse' or 'list_corpses_nearby,' nor does it mention prerequisites or exclusions beyond the character's death status.
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 mentions the tool 'gets' parties, implying a read operation, but does not specify permissions required, rate limits, pagination, or what happens if no parties are found. For a tool with 5 parameters and no annotations, this lack of detail 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 front-loads the core purpose ('Get all parties within a certain distance of a coordinate') and adds a brief use case ('useful for finding nearby groups'). There is no wasted verbiage, making it appropriately sized and well-structured for quick understanding.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, parameter meanings, and expected output format. For a spatial query tool in a gaming or simulation context, more context on how parties are defined, what data is returned, and any limitations would be necessary for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds minimal semantics by mentioning 'distance' and 'coordinate,' which loosely relate to parameters like 'radiusSquares', 'x', and 'y', but it does not explain the meaning of 'worldId', 'sessionId', or the units for 'radiusSquares'. With 5 parameters and low coverage, the description does not adequately compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get all parties within a certain distance of a coordinate' with a specific verb ('Get') and resource ('parties'), and it distinguishes the spatial filtering aspect ('within a certain distance of a coordinate'). However, it does not explicitly differentiate from sibling tools like 'list_parties' or 'get_party_context', which might list parties without spatial filtering, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for 'finding nearby groups,' which suggests a context of spatial proximity searches. However, it does not provide explicit guidance on when to use this tool versus alternatives like 'list_parties' or 'get_party', nor does it mention any prerequisites or exclusions, leaving the 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?
No annotations are provided, so the description carries the full burden. It mentions 'Fog of War' which hints at limited visibility or filtered data, but doesn't disclose behavioral traits like whether this is a read-only operation, what data is returned (e.g., partial vs. full state), error conditions, or performance considerations. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Get the world state') and efficiently adds qualifying details. Every word earns its place with no redundancy 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?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., structured data, limitations due to Fog of War), parameter usage, or behavioral aspects. For a state-retrieval tool in a complex strategy context, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'specific nation' which relates to 'viewerNationId', but doesn't explain any parameters (worldId, viewerNationId, sessionId) or their semantics (e.g., format, purpose, how they affect the Fog of War). It fails to compensate for the low 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') and resource ('world state'), and specifies the perspective ('from the perspective of a specific nation') with a contextual note about 'Fog of War for Grand Strategy'. It distinguishes this tool from sibling tools like 'get_world_state' by adding the nation-specific perspective, though it doesn't explicitly name that sibling for full 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 usage when needing a nation-specific view with Fog of War applied, but it doesn't explicitly state when to use this tool versus alternatives like 'get_world_state' (which likely provides a full view) or other state-retrieval tools. No exclusions or prerequisites are mentioned, leaving usage context somewhat inferred.
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 mentions the tool's utility but doesn't describe key behaviors: whether this is a read-only operation, what the output format looks like (e.g., list of character objects), potential side effects, or error conditions. For a tool with no annotations, 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 extremely concise and front-loaded: two sentences that directly state the purpose and a brief usage hint. There is no wasted language, and every word contributes to understanding the tool's role.
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 query tool with parameters), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what the tool returns, how parameters influence results, or behavioral traits. For a tool that likely returns structured data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, and the tool description provides no information about them. It doesn't explain what 'excludeEnemies' or 'sessionId' mean, their purposes, or how they affect the results. With low schema coverage, the description fails to compensate, leaving parameters undocumented.
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 characters not assigned to any party.' It specifies the resource (characters) and the filtering condition (unassigned). However, it doesn't explicitly differentiate from sibling tools like 'list_characters' or 'get_character', which might also retrieve character data but with different scopes.
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 context with 'Useful for adding members,' suggesting this tool is for finding characters to add to parties. It doesn't explicitly state when to use this versus alternatives like 'list_characters' or 'get_party_members', nor does it mention prerequisites or exclusions. The guidance is helpful but incomplete.
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 lists fences with optional filtering, but doesn't disclose behavioral traits such as pagination, sorting, rate limits, authentication needs, or what 'registered' entails. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool 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 that front-loads the core purpose ('List all registered fences') and adds optional functionality ('optionally filtered by faction'). There is no wasted verbiage, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, two parameters, and no output schema, the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter usage, return values, and context—critical for a tool in a complex system with many siblings. More information is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It mentions 'optionally filtered by faction,' which hints at the 'factionId' parameter's purpose, but doesn't explain 'sessionId' or provide details on parameter formats, constraints, or interactions. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all registered fences'), making the purpose understandable. It distinguishes from the sibling 'get_fence' by indicating this lists multiple fences rather than retrieving a single one, though it doesn't explicitly contrast with other list tools like 'list_characters' or 'list_items'.
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 through the phrase 'optionally filtered by faction,' suggesting when to use the optional parameter. However, it lacks explicit guidance on when to choose this tool over alternatives like 'get_fence' for single-fence retrieval or other list tools, and doesn't mention 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?
No annotations are provided, so the description carries full burden. It states the tool lists quests with optional filtering, but doesn't disclose behavioral traits like pagination, rate limits, authentication needs, return format, or whether it's read-only. For a list operation with zero annotation coverage, this leaves significant gaps in understanding how the tool 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 extremely concise—a single sentence that directly states the tool's function and optional filtering. It's front-loaded with the core purpose and wastes no words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and two parameters, the description is incomplete. It covers the basic purpose but lacks details on behavior, parameter meanings, return values, and usage context. For a tool in a complex environment with many siblings, this leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions optional filtering by 'world', which loosely corresponds to 'worldId', but doesn't explain the 'sessionId' parameter at all. The description adds minimal value beyond the schema, failing to clarify parameter purposes, formats, or relationships.
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 quests') and resource ('quests'), making the purpose immediately understandable. It distinguishes from other list tools by specifying 'quests' rather than characters, worlds, etc., but doesn't explicitly differentiate from similar list operations beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning optional filtering by world, suggesting this tool is for retrieving quests with possible world-based scoping. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'get_quest' or 'get_quest_log', nor does it mention 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a mutation operation ('update') but does not specify permissions required, whether changes are reversible, error handling, or response format. The advice on conditions adds some context, but overall, it lacks critical behavioral details for a mutation tool with 20 parameters.
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 and front-loaded, with the main purpose stated first. The two sentences earn their place by providing essential information about optional fields and condition handling. There is no unnecessary verbosity, making it efficient for an agent 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 complexity (20 parameters, nested objects, no output schema, and no annotations), the description is incomplete. It does not cover the full range of parameters, explain the update behavior for nested structures like 'stats' or 'spellSlots', or describe the response. For a mutation tool with high complexity and low schema coverage, more comprehensive guidance 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 description adds meaningful semantics beyond the input schema. It clarifies that 'All fields except id are optional,' which is not explicit in the schema (though implied by required parameters). It also provides specific guidance for the 'conditions' parameter, explaining how to use arrays for replacement versus 'addConditions'/'removeConditions' for granular control. This compensates for the low schema description coverage (15%) by adding practical usage 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: 'Update character properties.' It specifies the verb ('update') and resource ('character properties'), making the action explicit. However, it does not distinguish this tool from sibling tools like 'update_party_member' or 'update_item', which may also involve updates, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that 'All fields except id are optional' and gives specific advice for conditions, but does not indicate prerequisites, when to choose this over tools like 'create_character' or 'delete_character', or any exclusions. This leaves the agent without contextual usage instructions.
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 'creates a group of NPCs,' implying a write/mutation operation, but does not address permissions, side effects (e.g., whether NPCs persist in a database), error handling, or response format. The example hints at input structure but lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by role flexibility, and ends with a detailed example. The example is lengthy but necessary to demonstrate usage. No extraneous information is included, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete. It covers the purpose and provides an input example, but lacks details on behavioral aspects (e.g., what happens after creation, error conditions) and output format. For a mutation tool with 3 parameters, it meets minimum viability 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?
Schema description coverage is 67%, with parameters 'locationName' and 'npcs' described in the schema, but 'sessionId' undocumented. The description adds value by clarifying 'roles are flexible strings' with examples (e.g., 'blacksmith'), and provides a concrete JSON example that illustrates the structure and optional fields like 'race' and 'behavior'. This compensates well for the partial 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: 'Generate NPCs for a settlement or location. Creates a group of NPCs with specified roles.' It specifies the verb ('generate'/'create'), resource ('NPCs'), and context ('settlement or location'), but does not explicitly differentiate from sibling tools like 'create_character' or 'spawn_populated_location', which might have overlapping functionality.
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 roles are 'flexible strings' and gives an example for populating a village, but does not specify when to use this tool versus alternatives (e.g., 'create_character' for single NPCs, 'spawn_populated_location' for pre-configured locations). No explicit when-not-to-use or prerequisite information 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?
No annotations are provided, so the description carries full burden. It states the tool removes corpses, implying a destructive mutation, but doesn't disclose behavioral traits like permissions needed, whether removal is permanent, side effects (e.g., on inventory or game state), or error handling. The description is minimal and misses critical context for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and condition. There's zero waste or redundancy, making it easy to parse quickly. It's appropriately sized for the tool's apparent simplicity.
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 destructive nature (implied by 'Remove'), lack of annotations, no output schema, and minimal description, it's incomplete. The description doesn't cover what happens after removal (e.g., state changes, return values), error cases, or dependencies. For a mutation tool in a complex system with many siblings, this leaves significant gaps 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 1 parameter (sessionId) with 0% description coverage, so the schema provides no semantic context. The description doesn't mention parameters at all, but since there's only one parameter and it's likely a contextual identifier (common in sibling tools like 'initialize_session'), the lack of parameter info is less critical. A baseline of 4 is appropriate given the single, presumably straightforward parameter.
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 ('corpses that have fully decayed'), with a specific condition (state = gone). It distinguishes from sibling tools like 'advance_corpse_decay' (which changes state) and 'harvest_corpse' (which likely interacts differently with corpses). However, it doesn't explicitly contrast with 'delete_character' or 'delete_item', which might handle similar resources differently.
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 implies usage when corpses are in a 'gone' state, but provides no explicit guidance on when to use this tool versus alternatives like 'delete_character' or 'harvest_corpse'. It lacks prerequisites, exclusions, or named alternatives, leaving the agent to infer context from the condition 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 the full burden of behavioral disclosure. It mentions 'List all currently active auras', implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or what format the properties are in. 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 a single, clear sentence with no wasted words. It's front-loaded and efficiently communicates the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a read operation in a game/role-playing context), lack of annotations, no output schema, and incomplete parameter documentation, the description is insufficient. It doesn't explain return values, behavioral constraints, or how it fits with sibling tools, leaving significant gaps for an AI 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 one parameter ('sessionId') with 0% description coverage, but the tool description doesn't mention parameters at all. Since there's only one parameter and the tool likely operates in a session context, the lack of parameter info is less critical, but it doesn't add value beyond the schema. A baseline of 4 is appropriate given the low parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all currently active auras and their properties'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_auras_affecting_character' or 'expire_auras', 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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_auras_affecting_character' for character-specific auras) or any prerequisites. It's a basic statement of function without contextual usage advice.
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 query (read-only operation) and implies it returns concentration details, but doesn't specify error conditions (e.g., what happens if the character isn't concentrating), permissions needed, or response format. For a tool with no 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 front-loads the core purpose. Every word contributes directly to explaining what the tool does, with zero wasted text. It's appropriately sized for a simple query 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 (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and parameter explanations. Without annotations or output schema, the description should do more to compensate, but it meets the bare minimum for a read-only query.
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 50% (only 'characterId' has a description). The description adds no parameter-specific information beyond what's implied by the tool's purpose. It doesn't explain the 'sessionId' parameter or provide additional context for 'characterId'. With moderate schema coverage, the description doesn't compensate for the gaps, resulting in a baseline score.
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: 'Query what spell a character is currently concentrating on, including duration and targets.' It specifies the verb ('query'), resource ('spell a character is concentrating on'), and scope ('duration and targets'). However, it doesn't explicitly differentiate from sibling tools like 'check_concentration_duration' or 'break_concentration', 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a character to be concentrating), exclusions, or compare it to related tools like 'check_concentration_duration'. The lack of usage context leaves the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions aggregation but doesn't describe how the context is compiled (e.g., from what sources), whether it includes real-time updates, any rate limits, or what the output format looks like. For a tool with 5 parameters and no output schema, 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Aggregates comprehensive narrative context... for the LLM system prompt') directly contributes to understanding the tool's function, 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 the tool's complexity (5 parameters, no annotations, no output schema) and the description's brevity, it is minimally adequate. The purpose is clear, but without behavioral details, output information, or usage guidelines, it relies heavily on the schema for parameter understanding. This leaves gaps for an AI agent to fully leverage the 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 80%, with 4 out of 5 parameters having descriptions. The tool description does not add any parameter-specific information beyond what the schema provides (e.g., it doesn't explain relationships between worldId, characterId, and encounterId). Given the high schema coverage, the baseline score of 3 is appropriate 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.
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: 'Aggregates comprehensive narrative context (Character, World, Combat, Secrets) for the LLM system prompt.' It specifies the verb ('aggregates') and resource ('narrative context') with categories. However, it doesn't explicitly distinguish this tool from similar siblings like get_narrative_context_notes or get_party_context, which might also provide contextual 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 many sibling tools that retrieve context (e.g., get_narrative_context_notes, get_party_context, get_world_state), there is no indication of when this comprehensive aggregation is preferred over more specific tools. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify permissions, rate limits, or what happens if parameters are invalid. It mentions 'memoryLimit' but doesn't explain how memories are selected or formatted. For a tool with no 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 front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function, making it appropriately 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 the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage guidelines. Without an output schema, the description should ideally hint at return values (e.g., structured data for prompts), but it doesn't, leaving gaps in contextual 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 75%, with three parameters well-described and one ('sessionId') lacking a description. The tool description doesn't add any parameter-specific details beyond what the schema provides, such as explaining how 'memoryLimit' affects output or the purpose of 'sessionId.' Since schema coverage is relatively high, the baseline score of 3 is appropriate, but the description doesn't compensate for the gap in 'sessionId' documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get relationship + conversation history for LLM NPC dialogue prompts.' It specifies the verb ('Get') and resources ('relationship + conversation history'), and indicates the target use case ('LLM NPC dialogue prompts'). However, it doesn't explicitly differentiate from sibling tools like 'get_conversation_history' or 'get_npc_relationship', which appear to handle similar data components separately.
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 sibling tools like 'get_conversation_history' or 'get_npc_relationship', nor does it specify prerequisites, exclusions, or appropriate contexts beyond the generic 'LLM NPC dialogue prompts.' This leaves the agent without clear direction on tool selection.
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 this is a read operation ('Get'), implying non-destructive behavior, but doesn't disclose authentication needs, rate limits, error conditions, or what 'details' include beyond schema/parameters. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word contributes to understanding the tool's function 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?
For a read-only tool with 2 parameters (one required) and no output schema, the description is minimally adequate. It covers the basic purpose but lacks guidance, behavioral details, and parameter explanations that would help an agent use it effectively in context with many sibling tools.
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 50% (only 'name' parameter has a description). The tool description mentions 'template name' and 'full schema and parameters' as outputs, but doesn't clarify parameter semantics beyond what's in the schema. It doesn't explain the 'sessionId' parameter or provide additional context for 'name' (like format examples). Baseline 3 is appropriate given partial 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 ('workflow template'), specifying what information is retrieved ('details', 'full schema and parameters'). However, it doesn't distinguish this from similar sibling tools like 'get_character' or 'get_quest' beyond mentioning 'workflow template' as the specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, related tools like 'list_templates' for discovery, or contextual constraints. 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Returns'), but doesn't mention any behavioral traits like whether it's idempotent, has side effects, requires specific permissions, or how it handles errors. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the core purpose without unnecessary words. It's appropriately sized for a simple read operation and front-loads the key information ('Returns a high-level overview'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (read-only, 2 parameters, no output schema), the description is minimally adequate but has clear gaps. It explains what the tool returns but doesn't address behavioral aspects, parameter usage, or differentiation from siblings. The lack of annotations and output schema means the description should do more to compensate, but it only meets basic requirements.
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 50% (only 'worldId' has a description). The tool description doesn't mention any parameters, so it adds no semantic value beyond what the schema provides. With 2 parameters and partial schema coverage, the baseline score of 3 reflects that the schema does some work, but the description doesn't compensate for the undocumented 'sessionId' parameter.
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: 'Returns a high-level overview of the world including biome distribution and statistics.' It specifies the verb ('Returns'), resource ('world'), and scope ('high-level overview'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_world' or 'get_world_state', which might provide different types of world 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 many sibling tools like 'get_world', 'get_world_state', and 'get_world_tiles', there's no indication of how this tool's 'high-level overview' differs from those, nor any prerequisites or context for its use. This leaves the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 read operation ('Returns'), implying it's non-destructive, but doesn't cover other critical aspects like permissions, rate limits, response format, or pagination. For a tool with zero annotation coverage, 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 perfectly concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second adds valuable detail about included data. Every word earns its place, making it easy for an agent to parse 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 moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers what the tool does and what data it includes, but lacks details on behavior, parameters, and output structure. Without annotations or an output schema, more context would be helpful, but it meets the bare minimum for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'worldId' has a description). The description adds no parameter-specific information beyond what's implied by the tool's purpose. It doesn't explain 'sessionId' or provide context for 'worldId' beyond the schema's basic description. With partial schema coverage, the description fails to compensate adequately, resulting in a baseline score.
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: 'Returns the full tile grid for rendering the world map' specifies the verb (returns) and resource (tile grid). It adds detail about included data (biome, elevation, region, river) for visualization. However, it doesn't explicitly differentiate from siblings like 'get_world_map_overview' or 'get_region_map', 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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_world_map_overview' or 'get_region_map', nor does it specify prerequisites or exclusions. The agent must infer usage from the purpose alone, which is insufficient for effective tool selection.
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's a listing tool with optional filters, but doesn't disclose behavioral traits like pagination, rate limits, permissions needed, or what 'list all' entails (e.g., completeness, ordering). 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 a single, efficient sentence that front-loads the core purpose ('List all parties') and adds optional filtering details. Every word earns its place with no redundancy or 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 no annotations, 0% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose and hints at parameters, but lacks details on behavior, output format, or error handling. For a listing tool with three parameters, it should do more to be 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 0%, so the description must compensate. It mentions filtering by 'status or world', which maps to two of the three parameters (status, worldId), but doesn't explain 'sessionId' or provide details on format or usage. The description adds some value but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'parties', making the purpose specific and understandable. It distinguishes from siblings like 'get_party' (singular) and 'get_parties_in_region' (regional filter) by implying a broader listing, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering by 'status or world', but provides no guidance on when to use this tool versus similar listing tools (e.g., 'list_characters', 'list_worlds') or when filtering is appropriate. No exclusions or prerequisites are 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 the full burden of behavioral disclosure. It mentions that events are queued and polled by the frontend, which adds some context about the tool's role in an event-driven system. However, it lacks critical details such as permissions required, rate limits, whether events are durable, error handling, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in three sentences: it states the purpose, provides usage context, and explains the downstream effect (frontend polling). Each sentence adds value without redundancy. It could be slightly more front-loaded by emphasizing the core action first, but overall it's efficient.
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 (7 parameters, mutation operation, no output schema, and no annotations), the description is incomplete. It covers the high-level purpose and usage but lacks details on behavioral traits, parameter meanings beyond the schema, and expected outcomes. For a tool that pushes events in a system with many siblings, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 57% (4 out of 7 parameters have descriptions). The description doesn't add any parameter-specific semantics beyond what's in the schema—it doesn't explain the meaning of 'eventType' enums, 'payload' structure, or other parameters. With moderate schema coverage, the baseline is 3, as the description doesn't compensate for the coverage gap but doesn't detract either.
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: 'Push an event to the inbox.' It specifies the verb ('push') and resource ('event to the inbox'), and provides concrete examples of event types (NPC actions, combat updates, world changes). However, it doesn't explicitly differentiate this tool from sibling tools like 'poll_events' or 'get_event_history', which is why it doesn't reach a score of 5.
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 guidelines by stating 'Used by DM or internal systems to queue events' and listing example event types (e.g., NPCs doing things, combat updates). This gives context about when to use it, but it doesn't provide explicit alternatives or exclusions (e.g., when not to use it vs. other event-related tools). The guidance is helpful but not comprehensive.
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 the timing ('end of each round') but doesn't disclose behavioral traits like what effects are advanced, if it's idempotent, permission requirements, or error handling. This leaves significant gaps for a mutation tool with no structured safety hints.
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 short sentences that are front-loaded and waste no words. Every sentence earns its place by stating the action and usage timing efficiently.
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 4 parameters, no annotations, and no output schema), the description is incomplete. It lacks details on what effects are advanced, the result of the operation, error conditions, or dependencies, making it insufficient for safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It adds no meaning beyond the schema, failing to explain what 'target_id', 'target_type', 'rounds', or 'sessionId' represent in context. This is inadequate for a tool with 4 parameters, especially given the low 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 ('advance') and resource ('round-based effect durations'), making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'advance_corpse_decay' or 'advance_heat_decay', which also advance durations of different effects, so it misses full sibling distinction.
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 ('Call at end of each round'), which is helpful for timing. It doesn't specify when not to use it or name alternatives, such as other effect management tools, so it 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.
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 mentions the tool is 'useful for guard searches,' implying a read-only check, but does not specify permissions required, whether it modifies data, response format, or any side effects. For a tool with no annotations, 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 two sentences, front-loaded with the core purpose and followed by a brief usage hint. It is efficient with zero wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema description coverage (33%), the description is incomplete. It lacks details on behavioral traits, parameter meanings beyond the schema, and expected outputs. For a tool with 3 parameters and potential complexity in a gaming context, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only 'checkerId' has a description), and the tool has 3 parameters. The description does not add meaning beyond the schema, as it does not explain parameters like 'characterId' or 'sessionId'. With low coverage, the description fails to compensate, but the schema provides some basic structure, warranting a baseline score.
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: 'Check if a character carries stolen items.' It specifies the verb ('Check') and resource ('character'), but does not explicitly differentiate from sibling tools like 'check_item_stolen' or 'search_items', which might have overlapping functionality. The description is specific but lacks sibling distinction.
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 context with 'Useful for guard searches,' suggesting a scenario for application. However, it does not explicitly state when to use this tool versus alternatives like 'check_item_stolen' or 'search_items', nor does it mention prerequisites or exclusions. The guidance is present but limited.
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 states the tool creates a party, implying a write operation, but doesn't mention permissions, side effects, or response format. The example shows input structure but not behavioral traits like what happens if worldId is invalid or how initialMembers are validated.
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 a clear purpose statement followed by a comprehensive example. Every sentence (and the example) earns its place by demonstrating usage without redundancy. The structure is efficient and 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?
For a creation tool with 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is minimally adequate. The example compensates for parameter gaps but lacks behavioral context (e.g., error handling, permissions). It's complete enough to understand basic usage but insufficient for robust agent invocation without additional assumptions.
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 0%, so the description must compensate. The example effectively illustrates all 5 parameters (name, description, worldId, initialMembers, sessionId) with concrete values, adding meaning beyond the bare schema. It clarifies that initialMembers is an array of objects with characterId and role, though it doesn't explain optionality or defaults beyond the schema's enum for role.
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 creates a new party (adventuring group), which is a specific verb+resource combination. It distinguishes from siblings like 'delete_party' or 'update_party' by focusing on creation, though it doesn't explicitly contrast with similar creation tools like 'create_character' or 'create_world'.
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 lacks context about prerequisites (e.g., needing an existing world or characters), exclusions, or comparisons to sibling tools like 'add_party_member' for modifying existing parties.
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 that the secret is 'DM-only' and the AI narrates without revealing, which gives some behavioral context (confidentiality and AI role). However, it lacks details on permissions, side effects (e.g., if creation affects game state), rate limits, or response format, leaving significant 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.
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 purpose and includes key behavioral context. Every word earns its place, with no wasted information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, mutation operation) and lack of annotations and output schema, the description is insufficient. It covers purpose and basic AI behavior but misses critical details like what happens after creation, error conditions, or how secrets integrate with other tools (e.g., 'reveal_secret'), leaving the agent with incomplete 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 high (92%), so the baseline is 3. The description doesn't add specific parameter details beyond what the schema provides (e.g., it doesn't explain 'worldId' or 'leakPatterns' further). It mentions general categories (NPC, location, item, plot) which loosely map to the 'type' parameter but doesn't enhance schema information significantly.
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: 'Create a DM-only secret' with specific examples (NPC, location, item, plot) and explains the AI's role in narration without revealing. It uses a specific verb ('Create') and resource ('secret'), though it doesn't explicitly distinguish from sibling tools like 'update_secret' or 'delete_secret'.
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 specifying 'DM-only' and that the AI should narrate around it without revealing, which suggests when to use it (for hidden game elements). However, it doesn't provide explicit alternatives (e.g., vs. 'update_secret') or exclusions (e.g., when not to create a secret vs. using other 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. It states this creates a 'template' and implies it's for Dungeon Masters, but doesn't disclose behavioral traits such as whether this requires specific permissions, if the template is persistent, what happens on failure, or any rate limits. The mention of 'give_item' as a follow-up is helpful but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first states the purpose, and the second provides context for usage. It's front-loaded 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or behavioral nuances like template persistence. For a mutation tool in a complex gaming context, this leaves significant gaps for 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 63%, with 5 of 8 parameters having descriptions in the schema. The tool description adds no parameter-specific information beyond what's in the schema, but the schema provides good coverage for key parameters like 'scrollDC' and 'spellClass'. With moderate schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new spell scroll item template') and resource ('spell scroll'), distinguishing it from generic item creation tools like 'create_item_template'. However, it doesn't specify what makes this template unique compared to other item templates or scroll-related tools like 'get_scroll_details'.
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 tool' and that the scroll 'can then be given to characters via give_item', suggesting this is for game masters preparing items. However, it doesn't explicitly state when to use this versus alternatives like 'create_item_template' or 'give_item' directly, nor does it mention 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 the initiative timing and pending flag condition, which are useful behavioral constraints. However, it doesn't describe what 'execute' entails operationally—whether it's a read-only simulation or a destructive state change, what permissions are needed, how errors are handled, or what the response looks like. For a tool with 8 parameters and no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that directly state the tool's purpose and conditions. Every word earns its place, with no redundant information. It's front-loaded with the core action and immediately specifies prerequisites. This is a model of efficiency in tool descriptions.
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 (8 parameters, nested objects, no output schema, and no annotations), the description is insufficient. It doesn't explain what happens after execution, what the return value contains, error conditions, or side effects. For a tool that likely modifies encounter state (implied by 'execute'), this lack of operational context makes it incomplete for safe and 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?
The schema description coverage is high (88%), so most parameters are documented in the schema itself. The description adds minimal parameter semantics beyond the schema—it implies 'targetIds' are for 'environmental effects' and mentions damage application, but doesn't clarify parameter interactions or usage nuances. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.
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: 'Execute a lair action at initiative 20 when isLairActionPending is true. Apply environmental effects to targets.' It specifies the verb ('execute'), resource ('lair action'), and conditions (initiative 20, pending flag). However, it doesn't explicitly differentiate from sibling tools like 'execute_combat_action' or 'apply_custom_effect', which might handle similar combat or effect scenarios.
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 implicit usage context by stating 'when isLairActionPending is true' and 'at initiative 20', which suggests this tool should be used during specific combat phases. However, it doesn't explicitly mention when NOT to use it or name alternative tools for similar actions (e.g., 'execute_combat_action' for regular combat actions). The guidance is useful 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.
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 mentions that workflows 'automate multi-step operations,' which implies mutation or creation actions, but fails to disclose critical behavioral traits such as permissions required, whether execution is idempotent, error handling, or what happens on failure. For a tool with zero annotation coverage and no output schema, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with a clear purpose statement, but it includes lengthy JSON examples that, while helpful, could be considered excessive for a concise description. The examples earn their place by clarifying usage, but the overall structure is somewhat bloated, reducing efficiency compared to a more streamlined approach.
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 executing workflows (a multi-step automation tool) with no annotations and no output schema, the description is moderately complete. It explains the purpose and provides usage examples, but it lacks details on behavioral aspects like error handling, permissions, or return values. This leaves gaps that could hinder an AI agent's ability to use the tool effectively in all contexts.
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 itself provides no parameter information. The description compensates by including two detailed JSON examples that illustrate the expected input structure (e.g., using 'template' and 'params' or 'workflow' with nested steps). This adds substantial semantic value beyond the empty schema, effectively documenting the parameters through examples, though it lacks formal definitions.
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: 'Execute a workflow from a template or inline definition.' It specifies the verb ('execute') and resource ('workflow'), and distinguishes it from siblings by focusing on multi-step automation rather than single operations. However, it doesn't explicitly differentiate from all siblings (e.g., 'batch_create_characters' is also multi-step), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidelines by giving examples of when to use the tool (e.g., 'automate multi-step operations like creating a full party, setting up an encounter, or populating a village') and includes concrete examples for templates and inline workflows. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., when to use 'execute_workflow' vs. calling individual tools like 'create_party' directly), so it doesn't reach the clarity of a 4 or 5.
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 that results are 'ranked candidates by suitability,' which adds some context about output behavior, but fails to address critical aspects like whether this is a read-only operation, potential side effects, performance considerations, or error handling for invalid inputs.
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 clear sentences that are front-loaded with the core purpose. Every word earns its place, with no redundant information or unnecessary elaboration, making it easy for an agent 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 a 9-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain the return format, what 'suitability' means, how ranking works, or error conditions. For a tool that likely involves significant computation and game-world impact, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high at 89%, so the baseline is 3. The description adds minimal value beyond the schema by implying the tool considers terrain validity and suitability ranking, but doesn't provide additional semantic context for parameters like how 'preferredBiomes' affects ranking or what 'terrain-valid' specifically entails.
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 ('Find terrain-valid locations for placing a POI/structure') and resource ('POI/structure'), with the verb 'Find' and explicit scope of 'terrain-valid locations.' It distinguishes from the only relevant sibling 'suggest_poi_locations' by emphasizing terrain validation and ranking by suitability.
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 'suggest_poi_locations' or other placement tools. It lacks context about prerequisites, scenarios where it's appropriate, or exclusions, leaving the agent with no usage differentiation.
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 a possible skill check requirement, which is useful, but lacks details on permissions, side effects (e.g., does harvesting destroy the corpse?), rate limits, or what happens on success/failure. This is insufficient 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 that front-loads the core purpose and includes a key behavioral note. There is no wasted text, making it appropriately sized and well-structured for quick understanding.
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 (6 parameters, no annotations, no output schema, and low schema coverage), the description is incomplete. It lacks details on return values, error conditions, prerequisites, and how it interacts with other tools like 'loot_corpse'. For a mutation tool in this context, more comprehensive information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (2 out of 6 parameters have descriptions), which is low. The description adds value by implying 'resourceType' refers to things like 'scales, pelts' and that 'skillRoll' and 'skillDC' relate to skill checks, but it doesn't fully compensate for the coverage gap or explain the semantics of other parameters like 'characterId' or 'sessionId'.
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 ('harvest resources') and target ('from a corpse'), with specific examples ('scales, pelts') that help clarify the resource types. However, it doesn't explicitly differentiate from sibling tools like 'loot_corpse' or 'get_corpse_inventory', which might have overlapping functionality.
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 'May require skill check,' suggesting when skill checks are needed, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'loot_corpse' or how it differs from other corpse-related tools. No exclusions or prerequisites are 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 basic action but doesn't disclose important behavioral traits like whether this requires specific permissions, what happens to the corpse after looting, whether items are transferred immediately, or what the response format is. 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 extremely concise (two short sentences) and front-loaded with the core purpose. Every word earns its place with no wasted text, 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?
For a mutation tool with 6 parameters, 50% schema coverage, no annotations, and no output schema, the description is insufficient. It should explain more about the operation's behavior, return values, error conditions, and relationship to similar tools to be complete enough for 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 50% (3 of 6 parameters have descriptions). The description adds value by explaining the relationship between 'itemId' and 'lootAll' parameters, but doesn't provide context for other parameters like 'characterId', 'corpseId', 'quantity', or 'sessionId'. This partially compensates but doesn't fully address the coverage gap.
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 ('loot items') and target ('from a corpse'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar tools like 'loot_encounter' or 'harvest_corpse' in the sibling list, 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 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 two modes (specific item vs. everything), but it doesn't explicitly state when to use this tool versus alternatives like 'loot_encounter' or 'harvest_corpse', nor does it mention 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (apply effects) and includes power level guidelines and mechanics, but it does not address critical behavioral traits such as permissions required, whether the effect is reversible, potential side effects, or how conflicts with existing effects are handled. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by detailed guidelines and an example. However, it is lengthy and includes extensive lists (e.g., power levels, mechanic types) that could be streamlined. While informative, some sentences may not earn their place in terms of conciseness, making it moderately efficient but not optimal.
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 (14 parameters, nested objects, no output schema, no annotations), the description does a good job of providing context. It covers parameter meanings thoroughly and includes an example that illustrates usage. However, it lacks information on return values or error handling, and behavioral aspects are under-addressed, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides extensive parameter semantics: it explains 'power_level' with detailed guidelines (1-5), lists 'mechanics' types, and includes a comprehensive example that clarifies the meaning and usage of nearly all parameters (e.g., 'target_id', 'duration', 'triggers'). This adds substantial value beyond the bare 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: 'Apply a custom effect (divine boon, curse, transformation) to a target.' This specifies the verb ('apply'), resource ('custom effect'), and scope (boon/curse/transformation). However, it does not explicitly distinguish this tool from potential siblings like 'create_aura' or 'remove_custom_effect', which limits the score to 4.
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 lacks context about prerequisites, appropriate scenarios, or comparisons with sibling tools (e.g., 'create_aura' or 'apply_map_patch'). The example illustrates usage but does not offer explicit when/when-not instructions, resulting in minimal guidance.
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. It mentions that auras 'move with their owner and affect targets within radius' and 'optionally requires concentration,' adding some behavioral context. However, it omits critical details like whether this is a mutation (implied by 'Create'), what happens on failure, if it interacts with other systems (e.g., process_aura_effects), or the response format, 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.
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 additional context. It's efficient with two sentences, but could be slightly more structured by explicitly separating usage notes from behavioral traits.
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 (12 parameters, no output schema, no annotations), the description is incomplete. It lacks details on return values, error conditions, interactions with sibling tools (e.g., process_aura_effects), and comprehensive behavioral context, making it inadequate for a mutation tool with many parameters in a game 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 high at 92%, so the baseline is 3. The description adds minimal value beyond the schema by hinting at radius usage ('within radius') and concentration, but doesn't explain parameter relationships (e.g., how effects array interacts with triggers) or provide examples for complex fields like effects, relying heavily on 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 ('Create a new aura effect') with the resource ('centered on a character'), provides concrete examples (Spirit Guardians, Aura of Protection), and distinguishes it from sibling tools by focusing on aura creation rather than management (e.g., remove_aura, get_active_auras).
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 creating auras in a game context with examples, but lacks explicit guidance on when to use this tool versus alternatives (e.g., apply_custom_effect for non-aura effects) or prerequisites like character existence. It mentions concentration optionally, which hints at context but isn't comprehensive.
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 'returns DC and whether a check is required', which describes output behavior. However, it doesn't disclose important behavioral aspects like whether this is a read-only calculation (likely, but not stated), what happens with invalid inputs, whether it has side effects, or any performance considerations. 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 perfectly concise at two sentences that each earn their place. The first sentence states the core purpose, and the second sentence explains the return values. There's zero wasted language, and the information is front-loaded with the primary function stated immediately.
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 calculation tool with 3 parameters, no annotations, and no output schema, the description provides basic but incomplete context. It explains what the tool calculates and what it returns, but doesn't cover error conditions, side effects, or detailed behavioral expectations. The absence of output schema means the description should ideally explain return format more thoroughly, which it only does at a high level.
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 67% (2 of 3 parameters have descriptions). The description doesn't add any parameter-specific information beyond what the schema provides. It mentions 'character class/level' which relates to characterId, but doesn't explain parameter relationships or provide additional context. With moderate schema coverage, the baseline 3 is appropriate as the description neither compensates for gaps nor adds value beyond 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: 'Calculate the DC required to use a spell scroll' with the specific verb 'calculate' and resource 'DC'. It distinguishes from sibling tools like 'check_scroll_usability' or 'use_spell_scroll' by focusing on calculation rather than verification or activation. However, it doesn't explicitly contrast with these siblings in the description text.
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 'based on character class/level', suggesting it's for determining scroll usability requirements. However, it doesn't explicitly state when to use this tool versus alternatives like 'check_scroll_usability' (which might verify usability) or 'use_spell_scroll' (which might actually use the scroll). No explicit when-not-to-use guidance or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output format (text-based grid with specific symbols) and includes an example, which helps understand behavior. However, it doesn't mention side effects (e.g., if this modifies state), performance considerations, or error conditions, leaving 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 front-loaded with the core purpose, followed by details on the output format and an example. It's appropriately sized with no redundant sentences. However, the example is formatted as JSON, which might confuse the agent about input vs. output, slightly reducing 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 no annotations and no output schema, the description partially compensates by detailing the visual output format. However, for a tool with 5 parameters and complex behavior (rendering a combat map), it lacks information on error handling, state changes, or integration with other tools like 'get_encounter_state', making it incomplete for full contextual 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 80%, so the schema already documents most parameters well. The description adds minimal value beyond the schema: it implies 'encounterId' is required by including it in the example, but doesn't explain parameter interactions or semantics. 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: 'Render an ASCII map of the current combat state showing participant positions, obstacles, and terrain.' It specifies the exact resource (combat state) and output format (ASCII map), and distinguishes itself from siblings like 'get_region_map' or 'get_world_map_overview' by focusing on tactical combat visualization.
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 encounter), differentiate from similar tools like 'preview_map_patch', or specify scenarios where rendering a map is appropriate. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool is for discovery but doesn't disclose behavioral traits such as whether it's read-only, if it has rate limits, what the output format is, or any authentication needs. For a search 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 two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place with no redundancy or fluff, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a search tool with 5 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns, how results are structured, or any behavioral constraints. For a tool meant to discover other tools, more context on output and usage limits is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter semantics beyond the input schema, mentioning search by 'category, capability, or keyword,' which loosely maps to the 'query' and 'category' parameters. With 80% schema description coverage, the schema already documents most parameters well, so the description doesn't need to add much. It doesn't fully compensate for the 20% gap (e.g., 'sessionId' is undocumented in both), but meets the baseline.
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: 'Search for available RPG tools by category, capability, or keyword.' It specifies the verb ('search'), resource ('RPG tools'), and search dimensions. However, it doesn't explicitly differentiate from sibling tools like 'search_items' or 'search_narrative_notes,' which are more specific searches.
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: 'Use this to discover tools before using them.' This indicates it's for exploration and discovery rather than direct action. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for basic guidance.
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 discloses that the tool does not consume the scroll and returns check requirement and DC, which is good. However, it lacks details on permissions, error conditions, rate limits, or whether this is a read-only operation, which is important for a tool that checks usability.
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 key information: what the tool does and what it returns. There is no wasted text, 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, no output schema, and moderate schema coverage, the description is adequate but has clear gaps. It explains the core functionality and return values, but lacks details on behavioral traits, error handling, and the purpose of the 'sessionId' parameter, making it incomplete for full contextual 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 67% (2 out of 3 parameters have descriptions). The description does not add meaning beyond the schema, as it does not explain the parameters further. With moderate schema coverage, the baseline score of 3 is appropriate, as the schema provides some documentation but the description does not compensate for the undocumented 'sessionId' parameter.
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 ('check', 'use') and resources ('character', 'scroll'), and distinguishes it from siblings like 'use_spell_scroll' (which would consume it) and 'get_scroll_use_dc' (which might not check character-specific usability).
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 specifying 'without consuming it', suggesting this is for pre-use verification rather than actual scroll activation. However, it does not explicitly state when to use this tool versus alternatives like 'use_spell_scroll' or 'get_scroll_use_dc', leaving some ambiguity.
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 manual ending action but doesn't describe what 'end' means operationally (e.g., does it trigger side effects, require permissions, return confirmation?). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise - a single sentence that efficiently communicates purpose and usage context. Every word earns its place with no wasted text, and the parenthetical example provides helpful clarification without verbosity.
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 2 parameters, 50% schema coverage, and no annotations or output schema, the description provides adequate basic purpose and usage context but lacks details about behavioral implications, parameter meanings, and expected outcomes. It meets minimum requirements but has clear gaps 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 50% (only 'auraId' has a description). The description adds no parameter-specific information beyond what's implied by 'aura by ID'. It doesn't explain 'sessionId' or provide additional context about parameter usage. With moderate schema coverage, the description doesn't compensate for the undocumented parameter, resulting in a baseline score.
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 ('manually end') and target resource ('an aura by ID'), providing specific purpose. It distinguishes from siblings like 'expire_auras' (automatic) and 'remove_character_auras' (character-specific), though not explicitly named. However, it doesn't fully differentiate from 'break_concentration' which might overlap conceptually, keeping it from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 concentration breaks or spell is dismissed'), giving practical scenarios. It implies usage for manual intervention rather than automatic processes, but doesn't explicitly state when not to use it or name alternative tools like 'expire_auras', preventing a score of 5.
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: automatic application of ability modifier and proficiency bonus, and that it returns pass/fail if DC is provided. However, it doesn't cover other important aspects like error handling, response format, or whether it's a read-only or mutative 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 appropriately sized with two sentences: a clear purpose statement and a helpful example. It's front-loaded with the core functionality. The example could be slightly more concise, but overall it avoids unnecessary verbosity.
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 7 parameters, no annotations, and no output schema, the description is adequate but has gaps. It covers the core purpose and some behavior, but doesn't fully address the complexity—missing details on return values, error cases, or how parameters like 'advantage' and 'disadvantage' interact.
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 high at 86%, so the baseline is 3. The description adds minimal value beyond the schema: it mentions 'characterId and skill' in the example but doesn't explain parameter interactions or provide additional context not already 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 specific action ('Roll a skill check') and resource ('using character stats'), and distinguishes it from sibling tools like 'roll_ability_check' and 'roll_saving_throw' by specifying it's for skills with automatic modifier application. The example reinforces this distinction.
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 through the example ('for active character's Perception check'), suggesting it's for skill checks in role-playing contexts. However, it doesn't explicitly state when to use this tool versus alternatives like 'roll_ability_check' or 'dice_roll', nor does it mention 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?
No annotations are provided, so the description carries full burden. It mentions 'modify the world map' implying mutation, but lacks details on permissions, reversibility, side effects, or response format. The example hints at input structure but doesn't clarify behavioral traits like error handling or map state changes.
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: two sentences with zero waste. The first states the purpose, the second provides usage guidance and an example, each earning its place efficiently.
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 complexity (modification tool with no annotations, no output schema, and 67% schema coverage), the description is moderately complete. It covers purpose and usage but lacks behavioral details and parameter explanations, leaving gaps for a mutation tool that could affect game state significantly.
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 67% (2 of 3 parameters described), so the baseline is 3. The description adds minimal value beyond the schema: it implies 'worldId' and 'script' are used in the example but doesn't explain 'sessionId' or provide deeper semantics like DSL syntax or validation rules.
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 ('Apply DSL commands') and resource ('modify the world map'), making the purpose understandable. It distinguishes from siblings like 'update_terrain' or 'generate_terrain_patch' by specifying DSL-based modifications, though not explicitly contrasting them.
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 guidance by stating 'Use find_valid_poi_location first for structure placement,' which names a specific sibling tool as a prerequisite. This gives clear context for when to use this tool versus 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 discloses key behavioral traits: the tool checks recognition (implying a read operation) and specifies different logic for owners (always recognize) versus guards (check based on heat/bounty). However, it doesn't mention potential side effects, error conditions, or what the output looks like (e.g., boolean result or detailed response), leaving gaps for a mutation-free 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 extremely concise and front-loaded: two short sentences that directly state the tool's purpose and usage guidelines. Every word earns its place, with no redundant or vague phrasing, making it easy for an agent to parse 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 moderate complexity (checking recognition with conditional logic), no annotations, and no output schema, the description is partially complete. It covers the core purpose and some behavioral context but lacks details on return values, error handling, or deeper integration with sibling tools. This makes it adequate but with clear gaps for effective 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 75% (3 out of 4 parameters have descriptions), so the baseline is 3. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain how npcId, characterId, or itemId interact with the recognition logic). It only implies general usage without enhancing parameter understanding.
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: 'Check if NPC recognizes stolen item.' It specifies the verb ('check') and resource ('stolen item'), and distinguishes the action from generic checks by focusing on recognition of stolen items. However, it doesn't explicitly differentiate from sibling tools like 'check_item_stolen' or 'check_stolen_items_on_character', 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 for when to use the tool: 'Owner always recognizes; guards check vs heat/bounty.' This gives guidance on how different NPC types (owners vs. guards) affect recognition, which helps the agent understand appropriate scenarios. However, it doesn't explicitly mention when NOT to use it or name alternative tools for related checks, keeping it from a score of 5.
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 functional capabilities (supported notation types) but lacks behavioral details such as whether results are deterministic (seed parameter hints at this), output format expectations, error handling for invalid expressions, or performance considerations. For a tool with 4 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Roll dice using standard notation') and efficiently lists supported features in a single, well-structured sentence. Every part earns its place by clarifying capabilities without redundancy or fluff, making it easy to scan and 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 (4 parameters, no annotations, no output schema), the description is partially complete. It covers the primary use case and expression semantics but misses details on other parameters, behavioral traits, and output expectations. It's adequate for basic usage but lacks depth for full contextual understanding.
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 0%, so the description must compensate. It indirectly explains the 'expression' parameter through examples (e.g., '2d6+3', '4d6dl1'), providing semantic meaning for dice notation. However, it doesn't address other parameters like 'seed', 'exportFormat', or 'sessionId'. Since there are 4 parameters and only 1 is partially covered, the description adds value but doesn't fully compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb ('Roll dice') and resource ('dice'), specifies the notation ('standard notation'), and lists supported features like basic rolls, drop/keep mechanics, advantage/disadvantage, and exploding dice. This clearly distinguishes it from sibling tools (e.g., roll_ability_check, roll_saving_throw) by focusing on generic dice rolling with advanced notation rather than specific 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 through examples of supported notation (e.g., '2d6+3', '4d6dl1'), suggesting it's for any dice-rolling need with these features. However, it doesn't explicitly state when to use this tool versus alternatives like roll_ability_check or roll_saving_throw, nor does it provide exclusions or prerequisites. The guidance is contextual 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns 'parameter definitions, types, and usage info,' which is useful behavioral context. However, it doesn't mention potential side effects (e.g., caching, performance impact), error conditions, or authentication needs (sessionId parameter hints at this). The description adds value but lacks depth 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 two sentences, front-loaded with the core purpose and followed by return details. Every word earns its place, with no redundancy or fluff. It's appropriately sized for a straightforward utility 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 low complexity (2 parameters, no nested objects) but lack of output schema and annotations, the description is minimally complete. It explains what the tool does and what it returns, but doesn't cover error handling, sessionId usage, or example outputs. It's adequate but leaves gaps an agent might need to infer.
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 50% (toolName is described, sessionId is not). The description adds no specific parameter semantics beyond what the schema provides—it doesn't explain the purpose of sessionId or clarify toolName usage. With moderate schema coverage, the baseline is 3, as the description doesn't compensate for the gap but doesn't detract either.
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: 'Load the full input schema for a specific tool (required before first use).' It specifies the verb ('Load') and resource ('full input schema for a specific tool'), and distinguishes it from siblings by focusing on schema retrieval rather than game operations. However, it doesn't explicitly differentiate from potential schema-related siblings (none exist in the list), so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: 'required before first use' of a tool, implying this should be invoked to understand other tools' parameters. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to infer it's a preparatory step. No misleading guidance is present.
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 action ('Remove all auras') but doesn't specify whether this is reversible, requires permissions, affects other characters, or what happens on failure. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and provides context. Every word serves a purpose with zero waste, making it optimally concise while still informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides basic purpose and usage context but lacks details about behavioral implications, error conditions, or return values. It's minimally adequate but leaves important gaps given the tool's complexity and lack of structured metadata.
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 50% (only 'characterId' has a description). The tool description doesn't mention any parameters explicitly, so it adds no semantic value beyond what the schema provides. With moderate schema coverage, the baseline score of 3 reflects adequate but unenhanced 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 verb ('Remove') and resource ('all auras owned by a specific character'), making the purpose specific and actionable. It distinguishes from sibling tools like 'remove_aura' (singular) and 'expire_auras' (time-based), by focusing on character ownership removal.
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 ('when they die or lose concentration'), which helps the agent understand appropriate scenarios. However, it doesn't explicitly state when NOT to use it or name alternative tools for related actions.
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 function and supported shapes, but does not disclose behavioral traits like whether it's read-only, if it modifies game state, error handling, or performance characteristics. The examples add some context but leave gaps in behavioral understanding.
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. The examples are detailed but necessary for understanding parameter usage. However, the lengthy examples make it slightly less concise, though each sentence earns its place by demonstrating real-world applications.
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, no output schema, and moderate complexity (8 parameters with nested objects), the description is incomplete. It explains what the tool does and provides examples, but lacks information on return values, error conditions, or integration with other game systems. It's adequate for basic use but has clear gaps for full contextual understanding.
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 88%, so the schema already documents most parameters well. The description adds value by providing concrete examples with specific parameter values (e.g., radius: 4 for Fireball, angle: 90 for cone), clarifying units (tiles, degrees), and illustrating shape-specific parameter combinations beyond the schema's generic 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 explicitly states the tool's purpose: 'Calculate which tiles and participants are affected by an Area of Effect spell or ability.' It specifies the verb ('calculate'), the resource ('tiles and participants'), and distinguishes from siblings by focusing on AoE calculations, unlike other tools for narrative notes, character management, or combat actions.
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 AoE spells/abilities with supported shapes (circle, cone, line), but does not explicitly state when to use this tool versus alternatives. It provides examples but lacks guidance on prerequisites, exclusions, or comparisons to other calculation or combat tools in 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?
No annotations are provided, so the description carries full burden. It states the action ('Give items') but lacks critical behavioral details: whether this requires specific permissions, if items are consumed from a source, what happens on failure (e.g., invalid characterId), or any rate limits. The examples show usage but don't explain system 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: a clear purpose statement followed by two well-chosen examples that demonstrate different use cases. Every sentence earns its place, and the JSON examples are directly instructional without unnecessary commentary.
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 provides good purpose and parameter examples but lacks completeness. It doesn't cover error conditions, return values, or system constraints (like the 20-recipient limit mentioned in schema but not description). The examples help but don't fully compensate for missing behavioral 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 50% (only 'distributions' has a description, 'sessionId' lacks one). The description compensates well by providing two detailed examples that illustrate the structure and semantics of the 'distributions' parameter, showing how characterId and items arrays work in practice. However, it doesn't explain the purpose of 'sessionId'.
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 ('Give') and resource ('items to multiple characters'), and distinguishes it from sibling tools like 'give_item' (singular) and 'transfer_item' (one-to-one). The examples reinforce this batch distribution capability.
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 ('Perfect for starting equipment, loot distribution, or quest rewards') with concrete examples. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the context implies it's for batch operations versus single-item 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 the full burden of behavioral disclosure. While it implies a read operation ('Get'), it lacks details on permissions, rate limits, error conditions, or what 'all exits' entails (e.g., format, completeness). For a tool with no annotations, this is insufficient, scoring above 1 only due to the implied read nature.
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 states the purpose, and the second provides crucial sibling differentiation. Every word earns its place, making it highly efficient 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, no output schema, and 50% schema coverage, the description is adequate but has clear gaps. It covers purpose and sibling differentiation well, but lacks behavioral details and parameter explanations, making it minimally viable for a simple read 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 50% (only 'roomId' is described in the schema). The description adds no parameter-specific information beyond what the schema provides, failing to compensate for the undocumented 'sessionId'. With partial schema coverage and no additional param details in the description, the 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 verb ('Get') and resource ('all exits from a room'), and explicitly distinguishes it from the sibling tool 'look_at_surroundings' by noting that the sibling provides perception-filtered exits. This precise differentiation earns 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 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 versus an alternative: 'Use look_at_surroundings for perception-filtered exits.' This directly addresses sibling tool differentiation and usage context, meeting the criteria 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the mechanics (DC calculation and auto-success), it doesn't cover important behavioral aspects like whether this consumes resources, requires specific character permissions, affects game state, or what happens on failure. For a tool with potential game impact and no 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 perfectly concise with zero wasted words. It's a single sentence that front-loads the core purpose and efficiently explains both identification methods. Every element earns its place by providing essential context for tool selection and parameter understanding.
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 (identification with two methods), no annotations, and no output schema, the description provides adequate basic context but lacks completeness. It explains the identification mechanics well but doesn't cover behavioral consequences, failure outcomes, or return values, leaving gaps that could hinder effective agent usage.
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 adds meaningful context beyond the 75% schema coverage. While the schema describes parameters like 'characterId' and 'scrollItemId', the description explains that identification involves either an Arcana check (DC 10 + spell level) or the Identify spell, which helps interpret the 'useIdentifySpell' boolean parameter. This compensates well for the schema's partial 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 ('identify a spell scroll') and the two methods available (Arcana check with DC formula or Identify spell with auto-success). It distinguishes this tool from sibling tools like 'check_scroll_usability' or 'get_scroll_details' by focusing on the identification process rather than usability checks or information retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides usage context by explaining the two identification methods (Arcana check vs. Identify spell), which helps an agent decide when to use each approach. However, it doesn't explicitly state when to choose this tool over alternatives like 'check_item_recognition' or mention prerequisites such as character proximity to the scroll.
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 effectively describes the tool's behavior: polling unread events, returning them, and marking them as consumed. It adds context about event sources (NPCs, combat, world systems) and their purpose (autonomous feel). However, it lacks details on rate limits, error handling, or side effects beyond consumption.
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 first sentence stating the core purpose. The following sentences add useful context and an example, but the example could be more concise. Overall, it avoids unnecessary verbosity and maintains focus.
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 (event polling with consumption), no annotations, no output schema, and low schema coverage, the description does a good job explaining what the tool does and why. It provides an example response format, which compensates for the lack of output schema. However, it could improve by addressing parameters or error cases.
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 50% (only 'limit' has a description). The description does not mention parameters at all, failing to compensate for the low coverage. However, with only 2 parameters and one documented in the schema, the baseline is 3 as the schema provides some clarity, but the description adds no value beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('poll', 'returns', 'marks as consumed') and identifies the resource ('event inbox for unread events'). It distinguishes from siblings by focusing on event polling, unlike other tools that handle NPCs, combat, or world systems directly.
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 explaining events are generated 'while the player wasn't looking' and represent autonomous NPC actions, combat, etc. However, it does not explicitly state when to use this tool versus alternatives like 'get_event_history' or 'subscribe_to_events', nor does it provide exclusions 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 describes the core behavior (d20 roll with specific outcomes) but doesn't mention side effects like updating character state, permission requirements, or error conditions. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence with zero waste. It front-loads the purpose and includes all essential outcome rules without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the basic purpose and rules adequately. However, it lacks information about what the tool returns, how it affects game state beyond the described outcomes, and error handling. Given the complexity and lack of structured data, it should do more to be 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 67% (2 of 3 parameters have descriptions). The description doesn't add any parameter-specific information beyond what's in the schema. With moderate schema coverage, the baseline score of 3 is appropriate since the schema does most of the work, but the description doesn't compensate for the undocumented 'sessionId' parameter.
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 ('Roll a d20 death saving throw'), target ('for a character at 0 HP'), and outcome rules ('10+ success, nat 20 regains 1 HP, nat 1 counts as 2 failures'). It distinguishes itself from sibling tools like 'roll_saving_throw' by specifying the death save context.
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 explicitly states when to use this tool ('for a character at 0 HP'), providing clear context. However, it doesn't mention when not to use it or name specific alternatives among the many sibling tools, though 'roll_saving_throw' is a logical alternative for non-death saves.
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 that 'ONE CALL generates entire layout' (batch generation behavior) and provides pattern-specific behavioral traits (e.g., maze creates corridors & walls, maze_rooms adds chambers). However, it doesn't cover important behavioral aspects like whether this is a read-only or destructive operation, what permissions are needed, rate limits, or what the output looks like (no output schema 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 well-structured with clear sections (PATTERNS, MAZE EXAMPLE, MAZE WITH ROOMS) and front-loads the core purpose. Every sentence adds value, though the pattern list could be slightly more concise. The examples are appropriately detailed without being verbose.
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 (9 parameters, procedural generation), no annotations, and no output schema, the description is moderately complete. It covers pattern semantics and usage examples well, but lacks critical behavioral context (destructive vs. read-only, output format, error conditions). For a generation tool with significant parameters, more comprehensive disclosure 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?
Schema description coverage is high (89%), so the baseline is 3. The description adds significant value by explaining pattern semantics (what each pattern generates), providing concrete examples with parameter combinations, and clarifying usage constraints (e.g., corridorWidth for 'maze patterns only', roomCount for 'maze_rooms pattern only'). This goes well beyond the schema's enum and 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 generates terrain using pattern templates with a specific verb ('generate') and resource ('terrain'), and distinguishes itself from siblings by focusing on procedural terrain generation rather than narrative, combat, or character management tools listed. The opening sentence explicitly defines the core function.
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 specific patterns (e.g., 'USE THIS FOR MAZES' for the maze pattern, and pattern-specific examples like maze_rooms with roomCount), but doesn't explicitly state when NOT to use this tool versus alternatives like generate_terrain_patch or generate_world from the sibling list. The guidance is pattern-specific rather than tool-alternative focused.
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 disclosing key behavioral traits: it checks for expiration and automatically breaks concentration if expired. However, it lacks details on side effects, error handling, or what happens if concentration is not active.
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 concise with two sentences that directly state the tool's function and automatic behavior, with 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 tool with no annotations and no output schema, the description is adequate but incomplete. It explains the core action but lacks details on return values, error conditions, or how it interacts with other concentration-related tools, leaving gaps in understanding its full 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 67%, with 'sessionId' lacking a description. The tool description adds no explicit parameter semantics, but the purpose implies that 'characterId' identifies the concentrator and 'currentRound' is used for duration comparison. Since there are only 3 parameters and the schema covers most, a baseline near 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('check') and resource ('character's concentration'), and it distinguishes from sibling tools like 'break_concentration' and 'check_concentration_save' by focusing on duration-based expiration rather than manual breaking or saving throws.
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 in combat scenarios where concentration duration matters, but it does not explicitly state when to use this tool versus alternatives like 'check_automatic_concentration_break' or 'break_concentration', nor does it mention prerequisites such as needing concentration to be active.
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 the key behavioral trait ('Automatically breaks concentration if save fails'), which is critical for a mutation tool. However, it does not mention permissions, rate limits, or what happens on success (e.g., concentration continues). It adds value but is incomplete 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 the DC rule and outcome. Every sentence earns its place with no wasted words, making it highly efficient 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 is adequate for a simple tool but lacks details on success behavior, error handling, or return values. It covers the basic mechanics but could be more complete for a mutation tool in a complex gaming 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 67% (2 out of 3 parameters have descriptions). The description does not explicitly mention parameters, but it implies the need for 'damageAmount' in the DC calculation and context for 'characterId'. Since coverage is moderate, the description compensates by clarifying the tool's logic, earning a score above the baseline.
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 ('Roll a Constitution saving throw to maintain concentration after taking damage'), the resource involved ('concentration'), and distinguishes it from siblings like 'break_concentration' and 'check_concentration_duration' by focusing on the saving throw mechanic triggered by damage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('after taking damage') and provides the DC calculation rule, but it does not explicitly mention when not to use it or name alternatives like 'check_automatic_concentration_break' for cases where concentration breaks without a save. The context is clear but lacks explicit 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?
With no annotations provided, the description carries the full burden. It effectively describes the tool's behavior: it resolves improvised actions with skill checks, damage, and consequences based on provided guidelines. It includes DC and damage scales, and an example showing the expected input structure. However, it lacks details on error handling, side effects, or system state changes beyond the example.
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: it starts with the core purpose, provides context and guidelines, and ends with a comprehensive example. Every sentence adds value, but it is moderately long due to the detailed guidelines and example. It could be more front-loaded by emphasizing the example's role earlier.
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 (13 parameters, nested objects, no output schema, no annotations), the description does a good job. It explains the tool's role, provides scaling guidelines, and shows a full example. However, it doesn't cover all parameter nuances or potential outputs, leaving some gaps for a tool of this complexity.
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 very low (8%), so the description must compensate. It adds significant meaning: the example illustrates how parameters like 'narrative_intent,' 'skill_check,' and 'consequences' should be used, and the DC/damage guidelines inform 'dc' and 'success_damage' values. This goes beyond the bare schema, though it doesn't cover all 13 parameters explicitly.
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: 'Resolve a creative player action using the Rule of Cool.' It provides specific examples ('kick the brazier of coals into the zombie horde,' 'swing from the chandelier and kick both guards') and distinguishes it from sibling tools by focusing on improvised stunts rather than standard combat actions or narrative notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly defines when to use this tool: for creative, improvised player actions that require mechanical resolution. It provides DC and damage guidelines to help assess appropriateness. However, it does not explicitly state when NOT to use it or name specific alternatives among the many sibling tools, though the context suggests it's for non-standard actions.
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 the maximum batch size (20 characters) and minimum requirement (name), which are useful behavioral constraints. However, it lacks details on permissions, mutation effects (e.g., whether characters are saved permanently), error handling, or response format, leaving gaps for a write 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 appropriately sized and front-loaded, starting with the core purpose and usage guidelines. The examples are detailed but relevant for illustrating parameter usage. It could be slightly more concise by integrating example details into a shorter format, but overall, it avoids unnecessary fluff and is 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 provides good context on purpose, usage, and parameters through examples. However, it lacks information on behavioral aspects like error handling, permissions, or what the tool returns, which are important for a write operation. It is adequate but has clear 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?
Schema description coverage is 50%, with only the 'characters' array documented. The description adds significant value by explaining the 'characters' parameter through two detailed examples, showing required fields (name) and optional ones (class, race, etc.), and clarifying the structure beyond the schema. It compensates well for the coverage gap, though it does not mention the 'sessionId' parameter.
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 multiple characters at once, specifying the verb ('Create multiple characters') and resource ('characters'). It distinguishes from sibling tools like 'create_character' (singular) and 'batch_create_npcs' by emphasizing bulk creation for groups like parties or enemy squads, making the purpose specific and differentiated.
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: for generating groups such as a party, squad of enemies, or NPCs. It provides a maximum limit (20 characters per call) and a minimum requirement (each character needs a name), offering clear usage context without exclusions, though it does not mention alternatives like 'create_character' for single creations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool creates a new character (a write operation) and provides examples of behavior, but doesn't mention permissions, rate limits, side effects, or what happens on failure. The examples help, but key behavioral traits like persistence and error handling are missing.
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 for a complex tool with 23 parameters. It's front-loaded with the core purpose and defaults, followed by organized sections for character types and examples. Every sentence earns its place by providing essential guidance, though the examples are lengthy but necessary for 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?
Given the tool's complexity (23 parameters, nested objects, no output schema, and no annotations), the description does a good job of providing context. It explains the creation process, parameter flexibility, and includes examples. However, it doesn't cover return values or error cases, which would be needed for full completeness 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 26% schema description coverage, the description compensates extensively by explaining parameter semantics beyond the schema. It clarifies that 'class and race can be ANY string', 'stats can be any positive integer', provides character type definitions, and gives three detailed examples showing minimal and full usage. This adds significant value over the sparse 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 explicitly states the tool's purpose as 'Create a new character' with the verb 'Create' and resource 'character'. It distinguishes from siblings like 'batch_create_characters', 'update_character', and 'delete_character' by focusing on single character creation with detailed customization options.
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 by stating 'Only name is required - everything else has sensible defaults' and explaining character types with defaults. It doesn't explicitly mention when not to use this tool versus alternatives like 'batch_create_characters' or 'spawn_equipped_character', but the detailed parameter guidance implies this is for manual character creation.
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 adds context beyond basic creation: it details critical verticality rules (e.g., z=0 meaning 'standing on surface', z>0 for flying/levitating, fall risks), terrain generation rules (e.g., clustering obstacles, connecting water), and pattern templates. However, it does not cover aspects like error handling, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections like 'WORKFLOW', 'CRITICAL VERTICALITY RULES', 'TERRAIN GENERATION RULES', and 'PATTERN TEMPLATES', making it easy to scan. It is appropriately sized for a complex tool, but some sections (e.g., the detailed example) are lengthy, and not every sentence is strictly essential, slightly reducing 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 (4 parameters, nested objects, 50% schema coverage, no output schema, no annotations), the description is highly complete. It covers purpose, behavioral rules, parameter usage, and provides examples. However, it lacks explicit information on return values or error cases, which would be beneficial since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 50%, but the description compensates richly by explaining parameter semantics beyond the schema. It clarifies the meaning of 'position.z' with verticality rules, provides examples for 'terrain.obstacles' and 'terrain.water' using pattern templates, and illustrates 'participants' with a detailed example including fields like 'hp', 'initiativeBonus', and 'isEnemy'. This adds significant value over the schema's partial 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 tool's purpose: 'Create a combat encounter with positioned combatants and terrain.' It specifies the verb ('Create'), resource ('combat encounter'), and scope ('with positioned combatants and terrain'), distinguishing it from sibling tools like 'setup_tactical_encounter' or 'spawn_preset_encounter' by emphasizing structured creation with rules.
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 through workflow steps (e.g., 'Generate terrain', 'Add props', 'Place party', 'Place enemies'), suggesting a sequence for encounter creation. However, it lacks explicit guidance on when to use this tool versus alternatives like 'setup_tactical_encounter' or 'spawn_preset_encounter', and does not mention prerequisites or 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 the full burden. It effectively discloses behavioral traits: it describes the generation method (procedural noise/presets), lists biome presets with detailed components (e.g., 'forest: Trees (climbable props), undergrowth (difficult terrain), paths'), explains density scaling, and provides examples showing output behavior. It lacks details on permissions, rate limits, or error handling, but covers core functionality well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but not optimally structured. It front-loads the purpose and usage, but the biome preset list is lengthy (6 items with details), and the examples are verbose. While informative, some details (like full example JSON) could be streamlined. Every sentence adds value, but it could be more concise for quick scanning.
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 (10 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, parameters (with examples), and behavioral context. However, it lacks information on return values or error cases, which would be helpful since there's no output schema. The examples partially mitigate this by showing expected input structures.
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 high (90%), so the baseline is 3. The description adds significant value beyond the schema: it explains biome presets in detail (e.g., 'forest: Trees (climbable props)...'), clarifies density range ('0.1 (sparse) to 1.0 (dense)'), and provides two comprehensive examples that illustrate parameter usage and interactions (e.g., 'clearCenter' for player spawn). This compensates for the 10% schema gap and enhances understanding.
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 a terrain patch using procedural noise or preset patterns.' It specifies the verb ('generate'), resource ('terrain patch'), and method ('procedural noise or preset patterns'), distinguishing it from sibling tools like 'update_terrain' or 'generate_terrain_pattern' by focusing on patch creation rather than modification or pattern-only generation.
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: 'Much easier than placing individual tiles - LLM describes the area and this tool generates it.' This implies when to use it (for area-based generation vs. manual tile placement) and contrasts with alternatives like 'place_prop' or 'update_terrain'. However, it does not explicitly state when not to use it or name specific sibling alternatives.
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 clearly explains the calculation rules (5ft per square, diagonal rules), return format (distance in feet), and provides comprehensive examples showing different input patterns. However, it doesn't mention error conditions, performance characteristics, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by practical examples. While the examples are necessary for clarity, they make the description longer than minimal. Every sentence serves a purpose, 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 calculation tool with no annotations and no output schema, the description provides comprehensive coverage of what the tool does, how to use it, and what it returns. The examples effectively demonstrate parameter usage, and the distance calculation rules are clearly explained. The main gap is the lack of error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description provides excellent compensation through detailed examples that demonstrate all parameter combinations. The examples show exactly how to structure 'from' and 'to' objects with different 'type' values, clarifying what the schema leaves ambiguous about coordinate formats and entity references.
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 ('calculate the distance') and resource ('between two points or entities on the battlefield'), with explicit measurement units and rules. It distinguishes itself from sibling tools by focusing purely on distance calculation rather than combat actions, movement, or other spatial 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 usage through examples showing different scenarios (coordinates, entities, mixed), but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about prerequisites, limitations, or when other tools might be more appropriate for related spatial calculations.
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 creates a provenance record with detection risks, NPC disposition effects, and heat decay mechanics. It clearly indicates this is a mutation with in-world consequences, though it doesn't specify 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: a clear purpose statement, bullet points for consequences, and a practical example. Every sentence adds value without redundancy, and information is front-loaded with the core action followed by details.
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 theft's effects and heat decay. It covers behavioral context thoroughly, though it doesn't detail the return value or error conditions, leaving some gaps in full operational understanding.
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 high (83%), so the baseline is 3. The description adds value by providing a concrete example that illustrates parameter usage and relationships (e.g., witnesses as array, location context), enhancing understanding beyond the schema's individual parameter 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 specific action ('Record a theft event') and resource ('item'), distinguishing it from siblings like 'transfer_item' or 'give_item' by focusing on illicit transfer with consequences. It explicitly mentions creating a 'hot' theft record, which differentiates it from simple item movement tools.
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 example and consequences (e.g., 'May trigger guard searches'), but does not explicitly state when to use this tool versus alternatives like 'transfer_item' or 'give_item'. It provides some situational awareness but lacks direct guidance on tool selection.
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: the scroll is consumed after use (even on failure), and the Arcana check requirement depends on class list and casting level. This covers important mutation and conditional execution aspects that aren't in the 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 perfectly concise with two information-dense sentences. The first sentence states the core action and key behavioral constraint (consumption). The second sentence provides crucial conditional logic. Every word serves a clear purpose with zero waste.
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 covering consumption behavior and conditional execution rules. However, it doesn't describe what happens on success/failure, potential side effects, or return values, leaving some gaps in operational 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 schema description coverage is 80%, providing a solid baseline. The description doesn't add specific parameter information beyond what's in the schema, but it does provide context about how scroll usage works that informs parameter usage (e.g., characterId matters for class/level checks, scrollItemId identifies the consumable).
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 ('use a spell scroll from inventory') and resource ('spell scroll'), distinguishing it from sibling tools like 'use_item' by specifying the scroll type and consumption behavior. It provides precise operational details that differentiate it from generic item usage.
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 (consuming scrolls from inventory) and includes important usage rules (scroll consumption regardless of check outcome, no check required under certain class/level conditions). However, it doesn't explicitly mention when NOT to use it 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.
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 mentions the tool is for 'manually' breaking concentration, implying a user-initiated action, but lacks details on permissions, side effects, or response format. It adds some context (e.g., reasons for use) but doesn't fully cover behavioral traits like error handling or state changes.
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, using two sentences that directly state the tool's purpose and usage guidelines without unnecessary 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.
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 usage but lacks details on behavioral outcomes, error conditions, or return values. For a mutation tool with 4 parameters, it's adequate but has clear 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?
With 75% schema description coverage, the baseline is 3. The description adds value by implying the 'reason' parameter's usage context (e.g., 'voluntary breaks' maps to 'voluntary' enum), but doesn't detail parameter interactions like 'damageAmount' only applying to 'damage' reason. It compensates partially for the schema's gaps.
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 ('break') and resource ('a character's concentration on a spell'), and distinguishes it from siblings by specifying it's for manual breaks, unlike automated checks like 'check_concentration_save' or 'check_automatic_concentration_break'.
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?
It explicitly lists when to use this tool: for voluntary breaks, incapacitation, death, or when casting a new concentration spell, providing clear context without exclusions, which helps differentiate it from other concentration-related 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively communicates that this is a destructive operation ('Delete') and advises caution ('Use sparingly'), which is crucial for a mutation tool. However, it doesn't mention potential side effects, permissions required, or what happens to associated data, 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 extremely concise with two sentences that each serve a distinct purpose: stating the action and providing usage guidance. It's front-loaded with the core function and wastes no words, 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?
For a destructive tool with no annotations and no output schema, the description does the minimum by clarifying the action and advising caution. However, it lacks details on permissions, irreversible consequences, error conditions, or what 'archiving via status update' entails, leaving gaps in contextual understanding despite its conciseness.
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 50% (only 'noteId' has a description). The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining the 'sessionId' parameter or providing context for 'noteId' format. With partial schema coverage, the description doesn't compensate for the gaps, resulting in a baseline 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 verb ('Delete') and resource ('a narrative note'), making the purpose specific and unambiguous. It distinguishes this from the sibling tool 'update_narrative_note' by indicating a destructive action rather than modification.
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 guidance on when to use this tool ('Use sparingly') and when to prefer an alternative ('prefer archiving via status update'), offering clear context for decision-making. This directly addresses the tool's role relative to other options.
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 of behavioral disclosure. The description explains this is a batch operation that creates multiple entities at once, which adds useful context beyond just 'initialize'. However, it doesn't disclose important behavioral traits like whether this operation is idempotent, what happens if sessionId is provided, what permissions are required, or what the response looks like. For a complex creation tool with no annotations, 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 perfectly structured with zero waste. The first sentence states the purpose, the second provides critical usage guidance, and the example illustrates parameter usage. Every sentence earns its place, and the information is front-loaded with the most important details 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?
Given the tool's complexity (6 parameters with nested objects, no annotations, no output schema), the description is incomplete. While it explains the batch nature and provides a helpful example, it doesn't cover all parameters, doesn't describe the return value or possible errors, and doesn't address important behavioral aspects like idempotency or permissions. For a tool that creates multiple game entities at once, 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?
With 0% schema description coverage for 6 parameters, the description must compensate. The example provides concrete semantic meaning for worldName, partyName, characters array structure, and startingLocation object, which covers 4 of the 6 parameters. However, it doesn't explain worldSeed or sessionId parameters at all. The example adds substantial value but doesn't fully compensate for the coverage gap.
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 ('Initialize a new game session') and resources ('with world, party, and starting location'). It explicitly distinguishes this tool from its siblings by listing the exact operations it replaces ('create_world + create_party + N×create_character + move_party'), making it distinct from individual creation 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 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 versus alternatives by stating it 'REPLACES: create_world + create_party + N×create_character + move_party (6-10 calls → 1 call)'. This clearly indicates this is a batch initialization tool that should be used instead of making multiple separate calls, with no misleading or missing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait of being a preview-only, non-destructive operation. However, it lacks details on permissions, rate limits, output format, or error handling, which would be helpful for a mutation-related tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key behavioral constraint. Every word earns its place with no 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 no annotations and no output schema, the description is minimal but adequate for a preview tool. It covers the core purpose and non-destructive nature, but lacks details on what the preview output contains, error conditions, or dependencies. For a tool that simulates changes, more context on the preview format 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?
Schema description coverage is 67% (two parameters have descriptions, one does not). The description does not add specific parameter details beyond what the schema provides, but it contextually explains that 'worldId' and 'script' are used for previewing a patch. With moderate schema coverage and no parameter info in the description, a baseline 3 is adjusted to 4 because the tool has only 3 parameters and the description implicitly clarifies their roles.
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 ('previews') and resource ('DSL patch script'), and distinguishes it from its sibling 'apply_map_patch' by emphasizing it does not apply changes to the world. This provides immediate differentiation from a key alternative tool.
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 ('previews what a DSL patch script would do without applying it') and implies when not to use it (use 'apply_map_patch' for actual application). This provides clear guidance on tool selection relative to its sibling.
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 of behavioral disclosure. It describes the tool as a creation operation ('Create a complete location'), implying it's a write/mutation tool, which is useful context. However, it lacks details on permissions, error handling, or response format. The examples provide some behavioral insight (e.g., structure of input), but key operational traits like idempotency or side effects are not addressed.
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: the first sentence states the purpose clearly, followed by replacement context, token savings, and examples. The examples are detailed but necessary for illustrating complex usage. The lists of categories, icons, and biomes are concise references. While lengthy due to examples, every section adds value, and there is no redundant or verbose text.
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 (15 parameters, no output schema, no annotations), the description does a strong job. It explains the tool's purpose, usage context, and provides rich examples that clarify parameter semantics. However, it lacks details on behavioral aspects like error conditions or return values, and some parameters (e.g., 'sessionId') are not mentioned in the description, 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?
Schema description coverage is high (87%), so the baseline is 3. The description adds value by providing two detailed examples (Goblin Cave and Village Inn) that illustrate practical usage of parameters like 'rooms', 'inhabitants', and 'loot', including nested structures. It also lists allowed values for 'categories', 'icons', and 'biomes' beyond the schema enums, enhancing understanding. However, it doesn't fully explain all 15 parameters, keeping it from a 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 tool's purpose: 'Create a complete location with POI, optional room network, and inhabitants in one call.' It specifies the verb ('create'), resource ('complete location'), and components (POI, room network, inhabitants), distinguishing it from simpler creation tools. The explicit mention of replacing multiple sibling tools (e.g., create_poi, create_network) further clarifies its unique, comprehensive function.
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 versus alternatives: it states it 'REPLACES: create_poi + create_network + N×create_room + N×spawn_character + N×(create_item + place_item)' and highlights 'TOKEN SAVINGS: ~90%'. This directly informs the agent to use this tool for batch creation of populated locations instead of individual component tools, with clear efficiency benefits.
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 creates (POI, room network, NPCs) and the token savings benefit. However, it lacks details on permissions, error handling, or mutation impacts (e.g., overwriting existing locations), which are important for a creation tool. It adds good context but misses some behavioral traits.
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 sections like 'TOKEN SAVINGS', 'WHAT THIS TOOL DOES', and examples, making it front-loaded and easy to scan. However, the preset list is somewhat lengthy, and some sentences could be more concise (e.g., the examples are detailed but necessary). It's efficient but has minor verbosity.
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 (8 parameters, no annotations, no output schema), the description is mostly complete. It covers purpose, usage, parameters, and examples, but lacks details on return values or error conditions. With no output schema, it should ideally mention what is returned (e.g., location ID), leaving a small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 88% coverage. It explains parameter usage through examples (e.g., 'preset' values like 'generic_tavern', 'spawnNpcs' for NPC spawning, 'customName' overrides) and lists available presets, clarifying semantics that the schema alone does not fully convey, compensating for any gaps.
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 and resources: 'Spawn a complete location from a preset. Creates POI, room network, and optionally NPCs.' It distinguishes from siblings like 'spawn_populated_location' by emphasizing preset-based creation with token savings, and from 'generate_room_node' by handling complete location setup.
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 spawning preset locations with efficiency (85% token savings). It implies alternatives like manual specification or other spawn tools but does not explicitly name when-not-to-use scenarios or direct sibling comparisons, keeping it at a 4.
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 critical semantics (e.g., heightFeet describes visual height, not entity position), covers prop types and cover mechanics, and includes an example with climbable properties. However, it does not address potential side effects like persistence across sessions or interaction limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for height semantics, prop types, and cover types, and includes a detailed example. While it is appropriately sized for a complex tool, some parts could be more concise (e.g., the height semantics explanation is verbose). Overall, it is front-loaded with key information and uses formatting effectively, but minor verbosity prevents a perfect score.
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?
Given the tool's complexity (12 parameters, no output schema, no annotations), the description is highly complete. It covers purpose, usage context, behavioral details, parameter semantics, and provides an illustrative example. The lack of output schema is mitigated by the example showing expected input structure, making it sufficient for an agent to understand and invoke the tool correctly in the given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 92% coverage. It clarifies the semantics of heightFeet (critical for understanding elevation), explains prop types with examples (e.g., cliff, wall), details cover types with D&D 5e rules, and provides a comprehensive example that illustrates parameter usage. This compensates for any gaps in the schema and enhances understanding of complex parameters like climbDC and cover.
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 ('Place') and resource ('improvised prop/object on the battlefield during combat'), distinguishing it from siblings like update_terrain or generate_terrain_patch. It explicitly defines props as 'free-form terrain features with rich description that can be interacted with,' providing clear differentiation from other tools.
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 ('during combat') and offers examples of props (e.g., ladders, wagons, trees), but it does not explicitly state when not to use it or name alternatives. While it implies usage for combat terrain features, it lacks explicit exclusions or comparisons to sibling tools like update_terrain.
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 (healing, restoring spell slots, clearing effects), constraints (combat restriction), and different outcomes for long vs short rest. It doesn't cover error conditions or response format, but provides substantial behavioral context beyond basic functionality.
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, replacement context, long/short rest details, and examples. While comprehensive, every sentence serves a purpose - no wasted text. The examples are appropriately placed after the conceptual explanation.
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 substantial context: clear purpose, usage guidelines, behavioral details for both rest types, and parameter examples. It doesn't describe the return value format, but otherwise gives the agent sufficient information to understand when and how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 80% description coverage, establishing a baseline of 3. The description adds significant value through three detailed examples that illustrate parameter usage, show the relationship between hitDicePerMember and hitDiceAllocation, and demonstrate proper JSON structure. This goes well beyond what the schema descriptions provide.
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 ('rest entire party', 'heals all members', 'restores spell slots') and distinguishes it from sibling tools by explicitly mentioning it replaces 'N×take_long_rest or N×take_short_rest'. This provides clear differentiation from the individual rest 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 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 versus alternatives: it states it 'REPLACES: N×take_long_rest or N×take_rest' and quantifies token savings. It also specifies constraints like 'Cannot rest while any member is in combat' for both rest types, giving clear conditions for when not to use it.
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: it creates a full combat encounter (implying a write/mutation operation), mentions token savings (~90%), and provides detailed examples of input formats (e.g., position shorthand). However, it doesn't explicitly state permissions, error conditions, or side effects like session initialization needs.
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: the first sentence states the purpose, followed by key benefits (REPLACES, TOKEN SAVINGS), then examples and details. Every sentence adds value, though the long list of creature templates at the end could be slightly trimmed for better flow.
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 (7 parameters, nested objects) and no output schema, the description is quite complete. It covers purpose, usage, parameters with examples, and available options. The main gap is the lack of explicit mention of required permissions or error handling, but the example and template list provide strong contextual support.
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 high (86%), so the baseline is 3. The description adds significant value beyond the schema: it explains position shorthand ('"10,5" instead of {x:10, y:5, z:0}'), provides a full example with all major parameters, and lists available creature templates (which aren't in the schema as enums). This compensates well for the 14% schema gap.
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 full combat encounter with creatures from presets and terrain patterns.' It specifies the verb ('create'), resource ('full combat encounter'), and distinguishes it from siblings by explicitly mentioning it replaces 'create_encounter + N×create_character + N×update_terrain'.
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 guidelines: it states when to use this tool ('REPLACES: create_encounter + N×create_character + N×update_terrain') and includes a concrete example ('Example - Goblin Ambush:'). It also lists available creature templates, helping users understand what's possible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: the tool modifies terrain in an active encounter (implying mutation), emphasizes efficiency considerations (preferring ranges), and provides detailed examples of input formats and terrain types. However, it doesn't mention permissions, error handling, or response format, leaving some gaps in 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with the core purpose and key guideline, but it becomes lengthy with detailed lists of terrain types, range shortcuts, and examples. While informative, some sections (e.g., extensive shortcut lists) could be condensed or structured more efficiently without losing clarity, making it somewhat verbose.
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 of terrain modification and the lack of annotations and output schema, the description is largely complete. It covers purpose, usage, input semantics, and examples. However, it doesn't explain the return values or error conditions, which are important for a mutation tool with no output schema, leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 parameters are documented in the schema. The description compensates fully by detailing input options (ranges and tiles), providing extensive examples, and explaining terrain types and range shortcuts. This adds significant semantic value beyond the empty 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 explicitly states the tool's purpose: 'Add, remove, or modify terrain in an active encounter.' It clearly distinguishes this from sibling tools by specifying the resource (terrain) and the context (active encounter), which no other sibling tool addresses. The description goes beyond the tool name by detailing the types of terrain modifications possible.
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: 'ALWAYS prefer ranges over tiles arrays for efficiency.' It also distinguishes between input options (ranges vs. tiles) and specifies that ranges are preferred for efficiency, giving clear alternatives within the tool's usage. This helps the agent choose the most effective approach.
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: automatic corpse finding, loot transfer mechanics, optional currency distribution, and comprehensive summary return. It also mentions potential failure conditions ('may fail without skill check' for harvestable resources). The only minor gap is lack of explicit mention about permissions or side effects beyond the core functionality.
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 and concise. It starts with the core purpose, immediately provides the efficiency benefit, lists automated behaviors, and then gives practical examples. Every sentence earns its place, with no wasted words, and the information is front-loaded appropriately.
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 8 parameters, no annotations, and no output schema, the description does an excellent job covering the essential context. It explains the tool's purpose, usage scenarios, behaviors, and parameter semantics through examples. The only minor gap is that it doesn't explicitly describe the format of the 'comprehensive loot summary' return value, though this is somewhat mitigated by the detailed parameter explanations.
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?
With 88% schema description coverage, the baseline would be 3, but the description adds significant value through the three detailed examples that illustrate parameter combinations and their semantic implications. The examples show how parameters interact (e.g., partyId with distributeEvenly, selective looting with include flags) which goes beyond what the schema descriptions provide.
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 ('loot all corpses', 'transfers all loot') and resources ('from an encounter'). It explicitly distinguishes itself from sibling tools by mentioning it replaces 'list_corpses_in_encounter + N×loot_corpse', making its unique value proposition clear.
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 guidelines by stating when to use this tool ('REPLACES: list_corpses_in_encounter + N×loot_corpse') and the token savings benefit (~85%). It also gives clear alternatives through the examples showing different looting scenarios (single looter, party distribution, selective looting).
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 the tool's behavior: it creates a character with equipment in one call, supports preset names or full item specs, and includes examples showing input structure. However, it lacks details on error handling, permissions, or rate limits, which would be useful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with the core purpose, followed by replacement context, token savings, parameter details, and examples. Every sentence adds value, with no wasted words, making it efficient for an AI agent 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 complexity (14 parameters, no output schema, no annotations), the description does a good job of covering essentials: purpose, usage, parameters, and examples. It addresses the mutation nature and equipment handling. However, it could improve by mentioning output format or error cases, which would help for a tool with many inputs and no output schema.
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 low (29%), but the description compensates by explaining key parameters: it clarifies that 'equipment' can be 'preset names or full item specs', lists available presets (e.g., 'PHB weapons, armor, gear'), and provides examples that illustrate usage of 'template', 'name', 'stats', etc. This adds significant meaning beyond the schema, though some parameters (e.g., 'sessionId') remain less explained.
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 character with equipment from presets in a single call.' It specifies the verb ('Create'), resource ('character'), and scope ('with equipment from presets'), and distinguishes it from sibling tools by explicitly mentioning it replaces 'create_character + N×(create_item + give_item + equip_item)'.
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: it states when to use this tool ('REPLACES: create_character + N×(create_item + give_item + equip_item)') and includes practical examples (e.g., 'Dwarf Fighter', 'From creature template') that illustrate common scenarios. It also mentions token savings (~85%), which helps prioritize this tool over alternatives.
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 encounters (implying a write/mutation operation), lists available presets and difficulties, and hints at scaling based on party parameters. However, it doesn't explicitly mention permissions, side effects (e.g., if it modifies existing encounters), or error handling, 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 well-structured and front-loaded, starting with a clear purpose statement. Every sentence adds value: it explains the tool's advantage (token savings), provides practical examples, and lists available options without redundancy. The use of bullet points for presets and difficulties enhances readability, making it efficient and easy to scan.
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 (11 parameters, no output schema, no annotations), the description does a good job of providing context. It covers purpose, usage, examples, and available options, which helps compensate for the lack of output schema. However, it doesn't detail the return format or potential errors, leaving some gaps in completeness for a tool with many parameters and no structured output information.
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 high description coverage (91%), so the baseline is 3. The description adds significant value beyond the schema by providing concrete examples (e.g., 'goblin_ambush', 'orc_warband') and clarifying parameter interactions (e.g., 'partyLevel' defaults to 'level' if set). It also lists available presets and difficulties, which helps interpret the 'preset' and 'difficulty' parameters, though it doesn't fully document all 11 parameters.
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 complete combat encounter from a preset with a single call.' It specifies the verb ('create'), resource ('combat encounter'), and scope ('from a preset'), and explicitly distinguishes it from the sibling tool 'setup_tactical_encounter' by noting it replaces manual specification with preset-based automation.
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 versus alternatives: it states it 'REPLACES: setup_tactical_encounter with manual participant/terrain specification' and highlights token savings. It also includes multiple examples (e.g., 'Goblin Ambush', 'Scaled for large party', 'Random encounter') that illustrate different usage scenarios, making it clear when and how to apply the 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 well: it explains the multi-step behavior (move + auto-discover + optional enter), mentions a perception check condition ('if DC set'), and describes what happens with different parameter combinations through concrete examples. It doesn't cover error cases or rate limits, but provides substantial 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 efficiently structured with clear sections: purpose statement, token savings rationale, numbered what-it-does list, and concrete examples. Every sentence adds value—no fluff or repetition. It's appropriately sized for a complex 6-parameter tool.
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 complex mutation tool with 6 parameters, no annotations, and no output schema, the description does well: it explains the multi-step behavior, provides usage guidance vs siblings, and shows parameter interactions. It could mention error conditions or return values, but given the schema coverage and examples, it's mostly 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?
Schema description coverage is high (83%), so baseline is 3. The description adds value beyond the schema by explaining parameter interactions through examples: it shows how 'enterLocation' works with dungeon POIs, how 'autoDiscover' bypasses perception checks, and implies 'discoveringCharacterId' defaults to party leader. This provides practical context not 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 explicitly states the tool's purpose as 'Move a party to a POI on the world map' and distinguishes it from siblings by explaining it 'Combines move_party + discover_poi + enter_room' (two of which are sibling tools: move_party and discover_poi is implied). It provides specific 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 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 states it combines three separate tools (move_party, discover_poi, enter_room) and offers 'TOKEN SAVINGS: ~70% vs separate calls (3 tools → 1)', clearly positioning it as a consolidated alternative to those sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 thoroughly explains the tool's behavior: DC calculation with modifiers, outcomes (Mastery, Success, Fizzle, Backfire, Catastrophic), and damage guidelines. This includes risk factors (e.g., mishaps, damage to caster, WILD SURGE), which are critical for an AI agent to understand the consequences of invoking this 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 well-structured, with sections for DC Calculation, Modifiers, Outcomes, and Damage Guidelines, followed by an example. Each sentence adds value, such as explaining mechanics and risks. However, it is somewhat lengthy due to the complexity of the tool, which is justified but slightly reduces conciseness.
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?
Given the tool's high complexity (17 parameters, nested objects, no output schema, no annotations), the description is complete enough. It covers purpose, usage context, behavioral details (including risks and outcomes), parameter semantics, and provides an example. This compensates for the lack of structured fields, ensuring an AI agent can understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is low (18%), so the description must compensate. It adds significant meaning beyond the schema by explaining how parameters affect outcomes: e.g., 'encounter_id' adds +2 DC if in combat, 'estimated_level' influences base DC and damage, and 'circumstance_modifiers' map to specific DC adjustments. The example illustrates parameter usage in context, clarifying semantics that the schema alone does not provide.
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: 'Attempt to create a spell on the fly through Arcane Synthesis.' It specifies the action ('create a spell') and the mechanism ('Arcane Synthesis'), distinguishing it from sibling tools like 'create_spell_scroll' or 'use_spell_scroll' which handle predefined spells. The detailed mechanics further clarify this is for improvisational spell creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for creating spells dynamically based on narrative intent and specifications. It implicitly suggests usage when a player wants a custom spell effect not covered by existing spells. However, it does not explicitly state when not to use it or name alternatives (e.g., 'use_spell_scroll' for predefined spells), which prevents a perfect score.
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:

[![mnehmos.rpg.mcp MCP server](https://glama.ai/mcp/servers/Mnehmos/mnehmos.rpg.mcp/badges/card.svg)](https://glama.ai/mcp/servers/Mnehmos/mnehmos.rpg.mcp)

Score Badge

Copy to your README.md:

[![mnehmos.rpg.mcp MCP server](https://glama.ai/mcp/servers/Mnehmos/mnehmos.rpg.mcp/badges/score.svg)](https://glama.ai/mcp/servers/Mnehmos/mnehmos.rpg.mcp)

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/Mnehmos/mnehmos.rpg.mcp'

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