srdcheck
Server Quality Checklist
Latest release: v0.9.0
- Disambiguation4/5
Most tools target distinct rules (ability checks, saving throws, concentration, grappling, etc.), but `attack_modifiers` and `roll_compose` both handle advantage/disadvantage composition and could be confused. The tic-tac-toe tools are clearly separated by the `ttt_` prefix.
Naming Consistency3/5Names use a mix of noun phrases (`attack_modifiers`, `creature_stats`), noun-verb (`check_make`, `event_apply`), and single nouns (`jurisdiction`). The `ttt_` prefix is consistent, but overall there is no uniform verb_noun or noun_verb pattern.
Tool Count3/524 tools is on the heavy side, and the two tic-tac-toe tools do not belong in an SRD rules server, inflating the count. The SRD tools themselves cover a broad rules domain, but the set would be better scoped without the ttt tools.
Completeness4/5The SRD tools cover major mechanics: checks, saves, attacks, grappling, help, turn economy, spell facts, and encounter budgets. Minor gaps include no dedicated initiative or death-save resolution (death-save is only an event type), but the core is well covered.
Average 4.1/5 across 24 of 24 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 110 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does disclose meaningful traits: 'Always self-attested, including when the calling agent is the DM' and 'table authority remains with the caller or protected host.' However, it does not disclose side effects, error behavior, or permission requirements beyond authority, leaving 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. Each sentence earns its place: one states the core action and output, the other states the authority model. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a highly complex schema with nested objects for table_policy, asserted_facts, and table_decision, yet the description omits any explanation of these input structures or how they relate. The output schema exists but does not compensate for the lack of input guidance, making the description inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate but does not. It mentions 'named SRDCheck query' and 'scoped result' but offers no explanation of query_type, params, table_policy, asserted_facts, policy_context, or table_decision, leaving the agent with no semantic guidance for any of the 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adjudicate') and identifies a precise object ('one named SRDCheck query') and output ('deterministic table.evaluation/1.0'), making the tool's function clear. The wording distinguishes it from sibling tools like check_make or save_check by focusing on adjudication and table.evaluation projection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for adjudicating SRDCheck queries but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The 'Always self-attested' clause provides some context about caller roles, but no comparative guidance is given.
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 present, so the description carries the full burden. It discloses key behavioral traits: without the numeric 'blanks' (CHA modifier or paladin level), it returns the formula rather than a number; the 'closed set' limits valid features; and tables are explicitly out of scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no waste, but 'Formula-blanks discipline' is jargon. Still, the information is dense and front-loaded, with the core scope and special behavior stated early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, a nested policy schema, and no annotations, the description is too lean. It explains the core computation but leaves the policy/table parameters unexplained; 'Tables are out of scope' is a terse exclusion that doesn't clarify whether table_policy/table_decision are ignored or rejected. The presence of an output schema mitigates some, but not enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It connects divine-sense to CHA modifier and lay-on-hands to paladin level, explaining two parameters. However, it doesn't clarify the purpose of the remaining six parameters (request_id, table_policy, asserted_facts, policy_context, table_decision), leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's domain: use-count formulas for divine-sense and lay-on-hands, with arithmetic expressions. Though it lacks an explicit verb like 'calculate', the reference to 'verdict returns' makes the function clear. It distinguishes itself from siblings like attack_modifiers by focusing on class feature uses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when a feature use-count is needed for the two listed features. It explicitly states 'Tables are out of scope', excluding table-related queries, but doesn't name alternative tools or provide when-not-to-use guidance beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses output contents (feet_remaining, stand-up cost, crawl mode, spell-slot availability) and a consistency guarantee against turn.plan, which is useful. However, it omits whether the operation is read-only, error behavior, or boundary semantics, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the primary purpose, and each sentence adds distinct value: what the tool does, what options carry, and a consistency guarantee. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has a complex input schema (9 params, nested objects) and a short description that relies heavily on the agent knowing turn.plan's shape. It doesn't explain the 'boundary' concept or how parameters like spent and conditions should be populated, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, with only exhaustion_level described. The description does not explain any of the 9 parameters (speed, spent, conditions, etc.) beyond a vague reference to turn.plan's state shape. This is a critical gap for a tool with nested objects and required fields, and the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enumerate what remains legal this turn' with a specific verb and resource. It distinguishes itself from turn.plan by explicitly noting '(no plan)' and referencing the same state shape, making its scope and relationship to sibling tools clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by referring to 'the same state shape as turn.plan (no plan)', implying this is the options-enumeration counterpart to turn_plan. It does not explicitly name alternative tools for exclusions, but the context and consistency-testing reference give clear guidance on appropriate use.
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 burden. It discloses the three possible outcomes and the ambiguity of 'cannot-adjudicate' (2014-only vs typo vs third-party). However, it does not mention whether the tool is read-only, how optional parameters like table_policy affect behavior, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that efficiently defines the tool's core purpose and outcome categories with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a very rich input schema with optional nested objects for policies and contexts, but the description only covers the core name-validation behavior. It does not explain why an agent would pass table_policy, asserted_facts, etc., nor how they influence results. Given the absence of annotations, this is a significant gap 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 6 parameters with 0% description coverage. The description only adds meaning to 'name' by defining it as a creature name to validate. The other parameters (request_id, table_policy, asserted_facts, policy_context, table_decision) are completely unexplained, leaving the agent to guess their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates whether a name is an SRD 5.2.1 creature and defines three outcome categories. This distinguishes it from sibling tools like creature_stats or spell_facts, which likely provide details for already-valid names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool when you need to classify a name as legal/illegal/cannot-adjudicate. It also explains the 'cannot-adjudicate' limitation, which helps an agent avoid misusing it for non-SRD names. However, it does not explicitly name alternative tools for other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses meaningful behavioral details: exit code 0 means known content, exit code 2 means unknown/third-party and 'honestly refused'. This goes beyond a simple 'lookup' and informs the agent about refusal behavior and result interpretation. It doesn't cover other edge cases or side effects, but the disclosed exit-code semantics are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action and followed by exit-code semantics. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema with 6 parameters and nested objects, and no annotations. The description only covers the core lookup behavior and exit codes, ignoring the context params (e.g., table_policy, asserted_facts) and their role. An output schema exists, but the description does not explain how the inputs relate to outputs or when the optional parameters should be used. This is incomplete 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, so the description must compensate. It implicitly maps the required 'name' parameter to the named entity, but it says nothing about the other five parameters (request_id, table_policy, asserted_facts, policy_context, table_decision), which remain undocumented in both schema and description. The agent has no guidance on how these affect the lookup. The description adds minimal value beyond the schema's sparse descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 ('look up') and resource ('content registries'), and defines the outcome via exit codes. This distinguishes it from sibling tools, which are primarily combat/mechanics focused (e.g., attack_modifiers, save_check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: checking whether a named entity is known in the loaded rulesets. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. Usage context must be inferred from the phrasing alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return payload shape ({name, cr, xp, citation}) and a fallback behavior ('cannot-adjudicate otherwise'). It does not explicitly state side-effect-freedom or permissions, but 'Return' and the deterministic phrasing imply a read-only lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every clause adds information. There is no redundant or filler text, aside from minor stylistic quirks like 'legal with data'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and likely documents the return structure, so the description does not need to repeat that. It covers the core purpose and failure mode. However, the rich optional policy parameters are left entirely unexplained, which is a moderate completeness gap for an agent deciding whether to include them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with six parameters, yet the description only implicitly mentions the 'name' parameter via 'known creature' and the output keys. It does not explain request_id, table_policy, asserted_facts, policy_context, or table_decision, or when these optional parameters should be supplied. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return a creature's Challenge Rating and XP with a page citation.' It clearly states what the tool does and its purpose ('for deterministic encounter-budget math'), distinguishing it from sibling tools like encounter_xp_budget or creature_valid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear context for use ('for deterministic encounter-budget math') and an explicit applicability condition ('for a known creature; cannot-adjudicate otherwise'). It does not name alternative tools, but the when/when-not boundary is apparent.
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 behavioral disclosure burden. It clearly states behavioral rules: Reactions refresh at the start of the creature's own turn (not the round), are usable on that turn, and are prevented by Incapacitated and conditions that include it (Stunned, Paralyzed, Petrified, Unconscious). It also discloses rejection behavior for unknown or non-condition names, which is critical for error handling. It doesn't describe return values, but an output schema exists, so this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose question, and every sentence adds valuable rule information. It avoids fluff and redundantly stating the tool name. The structure flows logically from 'what does it do' to 'key rules' to 'error behavior,' making it highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, nested objects, output schema), the description sufficiently covers the core legality rules and error conditions that an agent needs to know. The existence of an output schema removes the need to describe return values. It doesn't explain all generic protocol parameters, but those are likely common across tools. The description is complete enough for correct use of the main functional parameters (conditions, spent_since_turn_start).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters but only 14% have descriptions. The description partially compensates by explaining that the conditions parameter expects condition names and that unknown/non-condition names are refused. It also aligns with spent_since_turn_start by explaining refresh timing. However, it does not explicitly map to parameters like table_policy, asserted_facts, or policy_context, and it doesn't clarify whether conditions is required or how multiple conditions are handled. The compensation is incomplete given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the question 'Is taking a Reaction legal right now?' which directly conveys the tool's purpose: to determine reaction availability. It specifies the resource (Reaction) and adds scope by clarifying refresh timing at the start of one's own turn, distinguishing it from generic availability checks. However, it doesn't use a conventional 'verb + resource' structure or explicitly name sibling alternatives, so it falls short of 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The question format implies the tool should be used when an agent needs to verify if a Reaction can be taken, and the rule details provide context for when it is relevant (e.g., during a character's turn or when conditions are involved). However, there is no explicit guidance on when not to use it, no mention of alternatives like opportunity_attack_provoked, and no exclusions. The usage context is implied rather than clearly stated.
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, the description discloses key behavioral traits: statelessness, no internal clock, arithmetic for expires_at, null for non-fixed durations, and exit code for unknown spells. This goes beyond a simple 'returns facts' and is crucial for correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence. It is dense but not bloated; all sentences contribute to understanding key behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers the core function and important edge cases, the many optional parameters are unaddressed. Given the schema's complexity, the description should at least hint at when to provide policy/context fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 29%, and the description only explains `name` and `cast_at`. The other five parameters (request_id, table_policy, etc.) are left undefined in both schema and description, leaving the agent without guidance on their purpose or use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing machine-readable spell facts for a registered SRD 5.2.1 spell, listing the specific fields returned. It lacks an explicit active verb (e.g., 'get') but is unambiguous and distinct from the listed sibling tools, which address other 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use for SRD 5.2.1 spell facts, optional cast_at behavior, and error exit. It does not explicitly discuss alternatives, but no direct sibling competes, so the context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and delivers substantial context: idempotency auto-key behavior, fail-closed handling of stale/out-of-order events, the rule vs. ruling distinction with DM authority, and the guarantee that srdcheck does not own state, produce events, advance time, or generate randomness. This covers key concerns for a stateful evaluation tool, though it omits details like error responses or authorization 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is densely packed and front-loaded with the core purpose in the first sentence, followed by idempotency, persistence, event types, and boundary statements. Every sentence adds value and there is no filler. It is longer than ideal, but the complexity of the tool justifies the length, though the event type enumeration could have been shortened by referring to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with massive nested schemas and low coverage, the description provides essential high-level orientation: evaluation-only, idempotency, fail-closed behavior, and ruling authority. It benefits from the existing output schema, so return values need no elaboration. However, it leaves significant gaps around state/event construction and policy inputs, which are crucial for an agent to invoke the tool correctly; the description is a good overview but not a complete guide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 13%, so the description should compensate, but it adds little beyond the schema. It restates idempotency_key usage (already in schema) and lists event types (already an enum). The only genuinely new semantic is the deterministic auto key on omission. Most complex parameters (state, event, table_policy, asserted_facts) are not explained in the description, leaving the agent to rely on the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Evaluate one declared event against a canonical state and return a precondition-bound transition proposal plus stamped next_state.' This clearly distinguishes it from the sibling transition_commit tool, which persists the proposed transition. The stated outputs and the explicit boundary 'Persist only through transition.commit' make the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage constraints: supply a stable idempotency_key for Discord events, and persist only through transition.commit, which also names an alternative tool. It further clarifies that stale or out-of-order events fail closed, and that srdcheck never owns state or generates randomness. However, it does not explicitly contrast with other siblings like check_make or save_check, so the guidance is clear but not exhaustive.
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 transparency burden. It discloses the return behavior (per-character XP budget with citation) and the total when party_size is passed, implying a read-only calculation. However, it does not discuss edge cases (e.g., invalid level/difficulty), state whether any state changes occur, or clarify any rate limits or authorization needs. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence front-loading purpose and primary inputs/outputs, and the second providing usage guidance. There is no filler or repetition of schema details; every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not detail return fields. It provides the essential workflow hint (combine with creature.stats) and mentions the citation. However, given the schema's complexity (nested policy objects, many optional parameters), the description does not address how the total is represented when party_size is provided or how to interpret the difficulty values beyond the basic enum. It is complete for the primary use case but leaves some integration details to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description must add meaning to parameters. It maps 'level' to party level, 'difficulty' to low/moderate/high, and clarifies that 'party_size' yields the total budget, adding value beyond the raw schema. The remaining parameters (request_id, table_policy, etc.) are likely generic infrastructure fields and not explained, but the description compensates for the core domain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'XP budget per character for encounter building' and specifies the key inputs (level, difficulty) and output (per-character budget with citation). This distinguishes it from sibling tools focused on combat mechanics like attack_modifiers or check_make. The resource and action are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says the tool is for 'encounter building' and gives concrete combination guidance: 'Combine with creature.stats to check whether an encounter is within budget.' It also explains the optional party_size behavior and how to get a total. However, it does not explicitly state when not to use this tool or mention alternative budget methods, so it stops short of a 5.
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, the description carries full behavioral disclosure. It reveals conditional fact-request behavior (distance for granted uses, weight for carrying/manipulating), states that prohibitions won't request irrelevant facts, and explains the fallback behavior for out-of-list uses (cannot-adjudicate with gm-discretion and resolve-table-ruling). This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause adds value: purpose, allowed/prohibited categories, limits, fact requirements, conditional behavior, and fallback. It front-loads the verb and resource, avoids fluff, and is appropriately sized given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good core guidance, the description omits critical information about the complex nested parameters. It mentions 'resolve-table-ruling' and 'agent-DM may rule directly,' but does not explain how to populate table_policy or table_decision, nor the role of asserted_facts and policy_context. Without this, an agent cannot confidently invoke the tool for out-of-list or DM-ruling scenarios. An output schema exists but is not shown, so the description should have covered these gaps more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, so the description must compensate. It does for the core parameters: kind (via the granted/prohibited lists), distance_ft, and weight_lb (via the fact-requirement rules). However, it gives no semantic guidance for complex parameters like table_policy, asserted_facts, table_decision, or policy_context, leaving their roles unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Adjudicate one proposed use of the Mage Hand cantrip,' and enumerates the exact use categories, carry limit, and range. This clearly distinguishes it from generic tools like table_evaluation or spell_facts, though it does not explicitly name sibling tools or contrast itself 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies exactly when to use the tool (for any proposed Mage Hand use) and when not to (uses outside the can/can't lists). It also provides an explicit alternative: 'an authorized agent-DM may rule directly,' satisfying the when/when-not/alternatives criterion.
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 burden of behavioral disclosure. It explicitly states the two key rules: multiple sources never add dice, and any Advantage with any Disadvantage yields a straight roll. It also mentions the optional reroll-one-die-only rule. This goes beyond the schema by explaining the operational logic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is stated first, followed by the critical rule about cancellation. Every clause adds value: the source lists, the no-stacking rule, the cancellation rule, and the optional reroll note. This is an exemplary concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool whose core function is to compose advantage/disadvantage, the description is quite complete: it explains the input lists and the transformation rules. The output schema exists, so the description need not detail return values. The only minor gap is that the 'Optionally notes the reroll-one-die-only rule' is a bit ambiguous—does 'notes' mean it returns the rule as a flag or adds it to the output? Still, overall the tool is well-understood from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 meaning to the core parameters by referring to 'lists of sources' (advantage_sources/disadvantage_sources) and the 'reroll-one-die-only rule' (reroll_available). However, it does not explain the other six parameters, which are mostly generic infrastructure fields. The compensation is partial but covers the tool-specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: "Compose net Advantage/Disadvantage from lists of sources." It clearly distinguishes this tool from siblings like check_make or attack_modifiers by focusing on the net composition logic instead of actual dice rolling or modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the usage context: when you have lists of advantage/disadvantage sources and need to determine the net effect. It does not explicitly mention alternatives or exclusions, but the task is specific enough that an agent can recognize when to use it. 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.
- 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 transparency burden. It discloses key behavioral aspects: it checks turn order, cell validity, occupancy, and game completion. However, it does not specify whether it modifies state, what the return value looks like (though an output schema exists), or how it handles invalid moves (e.g., return an error vs. false). This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately front-loaded with the purpose. Each sentence adds essential information: the first states what the tool does, the second specifies the board format and validation checks. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema's complexity (8 params, nested objects) and the presence of an output schema, the description covers the core task well: it explains the board format, cell indexing, and validation checks. It does not detail optional policy-related parameters, but these are likely shared infrastructure. The tool's simple validation purpose is adequately described, and the output schema covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates for the core parameters. It explains that 'board' is a 9-character string of X, O, and '.' and that cells are 1-9 left-to-right/top-to-bottom, which fully describes the board and cell parameters. 'player' is defined via the enum in the schema. Optional parameters (request_id, table_policy, etc.) are not explained, but they appear to be standard cross-tool infrastructure and are likely already understood by the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Judge one proposed tic-tac-toe move.' It immediately clarifies the tool's scope and distinguishes it from siblings like ttt_options by focusing on validating a single move rather than generating options or managing a game. The board format and validation checks are also clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever a proposed tic-tac-toe move needs to be validated. It outlines the specific validation criteria (turn order, cell validity, occupancy, game-ended), which gives clear context. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behavioral traits: the return of an empty list when the game state is invalid (not player's turn or ended). The 'same encoding as ttt.move' note also reduces ambiguity about the output format. It does not discuss side effects, but enumeration inherently implies a read-only action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every word contributes to understanding. It avoids redundancy and is appropriately sized for a straightforward query tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, edge cases, and encoding consistency with a sibling tool. An output schema exists, so return value details are not needed. It does not explicitly mention that the board is a 9-character string, but the schema already provides that, and the cross-reference helps fill gaps. Overall, it is complete enough for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning by referencing the encoding of ttt.move for the board and implicitly identifying the 'player' parameter. However, it does not detail the board string format or what constitutes a legal move beyond the cross-reference, leaving some ambiguity for agents unfamiliar with ttt.move.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: 'Enumerate the legal moves for a player on a board.' It specifies the resource (board/player) and the verb (enumerate). It also differentiates from sibling ttt_move, which makes a move, by focusing on legal moves, and provides an explicit encoding reference to ttt.move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when wanting legal moves before deciding) and clarifies edge cases ('Empty when it is not the player's turn or the game has ended'). It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when to invoke it.
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, the description carries the full burden and does so thoroughly. It discloses the caller-rolls-d20 contract, return object shapes for both modes, condition auto-fail/disadvantage rules, exhaustion penalty, and error behaviors (missing-fact, structured recovery classes). This goes well beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place. It front-loads the core purpose, then efficiently covers optional condition handling, return modes, and error cases without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is thorough for the basic saving-throw adjudication workflow, it omits the substantial policy/table/asserted-facts machinery that the schema exposes. Given the nested objects and output schema, an agent would be underprepared to use those advanced parameters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful context for save_ability, saver_conditions, d20_result, and exhaustion_level beyond the schema. However, it completely ignores several complex parameters (table_policy, asserted_facts, policy_context, table_decision) that have no schema descriptions, and with 55% coverage, the description does not fully compensate for those gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Adjudicate') and a specific resource ('a saving throw against a DC') with an SRD citation, making the tool's purpose immediately clear. It distinguishes itself from sibling tools like check_make and concentration_check by focusing on saving throws and DC resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains two invocation modes (with d20_result vs. without) and explicitly states when to pass save_ability + saver_conditions for condition-aware overrides. It does not explicitly name alternative tools or state when NOT to use this tool, but the purpose clarity largely handles differentiation.
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, the description carries full burden and delivers. It discloses that missing prerequisite facts return 'cannot-adjudicate', explains the conditional presence of the dc field depending on str_modifier and proficiency_bonus, and clarifies that formula blanks may be omitted. It also explicitly scopes out the save resolution and escape contest, giving a complete behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, prerequisites/error behavior, and return/scope. Every sentence carries substantive information with no filler, and the structure front-loads the main purpose then details constraints and output behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 params, nested objects), the description is fairly complete for the domain logic: it covers the SRD reference, prerequisite checks, conditional DC output, and the separation from save.check. It does not explain the policy/table parameters, but these may be system-wide conventions; the core adjudication behavior is well-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (27%), and the description partially compensates. It clarifies that attacker_size and target_size are both required, that has_free_hand is needed for grapple, and how str_modifier and proficiency_bonus affect the output's dc field. However, the numerous policy-related parameters (table_policy, asserted_facts, policy_context, table_decision) are not explained in the description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Adjudicate initiating a Grapple or Shove via an Unarmed Strike' and cites the exact source (SRD 5.2.1 p.190). It clearly distinguishes this tool from sibling save/check tools by stating the target's save is resolved separately via save.check and the escape contest is out of scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: it adjudicates the initiation step and explicitly delegates the target's save to save.check, defining what is out of scope (escape contest). It also states required inputs ('Both sizes are required; Grapple also requires has_free_hand'), helping callers know when they can call the tool. It does not explicitly name alternatives, but the scope exclusions provide practical guidance.
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, the description fully discloses behavior: it returns legal/illegal/cannot-adjudicate with citations, and illegal verdicts name the first offending step. It also explains error handling ('Unmodeled conditions and out-of-range inputs return exit 2 rather than a guess') and the exact scope boundaries, making the tool's behavior highly predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at roughly 90 words and front-loaded: the first sentence states the purpose and core rules, the second explains output, and subsequent sentences handle scope and error behavior. Every sentence adds unique information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, nested objects) and the presence of an output schema, the description adequately covers the core adjudication logic and error modes. It omits guidance on how the policy/table context parameters (table_policy, asserted_facts, table_decision) interact with the judgment, but these may be shared infrastructure. The explicit scope and error handling make it sufficiently complete for an agent to select and invoke the tool for its primary purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, leaving many parameters (table_policy, asserted_facts, policy_context, table_decision) undocumented in both schema and description. The description does add some validation semantics not in the schema, such as rejecting 'negative speed' and 'spell level >9,' and references movement edge cases (crawling, standing from Prone, Grappled speed 0) that clarify plan step semantics. However, it does not compensate for the large set of unexplained auxiliary parameters, so it meets the baseline but doesn't exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb 'Judge' and a precise resource: 'a whole proposed turn under SRD 5.2.1 ACTION ECONOMY.' It enumerates the exact rules covered (action/bonus-action/reaction/free-interaction budgets, movement, Incapacitated, one-spell-slot rule) and explicitly distinguishes itself by stating it does NOT verify feature-granted actions, which differentiates it from siblings like attack_modifiers or turn_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly delineates when this tool is appropriate ('this checks the turn's economy only') and what it does not cover ('does NOT verify that a feature grants a given action'), which implies when to look elsewhere. It also notes out-of-range inputs return exit 2, signaling a boundary condition. However, it does not explicitly name alternative sibling tools or give a positive 'use this if...' statement.
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, the description fully carries behavioral disclosure. It explicitly states that condition-sensitive observations must be supplied rather than defaulted, that exhaustion is always a flat modifier (never Advantage), and that ambiguous rules return cannot-adjudicate with the ambiguous sentence cited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence but front-loaded with the verb and object. Every clause adds rule detail, though it could be split into two sentences for easier readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 10-parameter tool with an output schema, this description covers the main attack-modifier domain, required observations, and ambiguity handling. It remains short on sibling differentiation and auxiliary parameter semantics, but it is largely sufficient for the core invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (~20%), so the description compensates by explaining the core condition and distance parameters, including the charmer/grappler relationships, visibility requirements, and nearby-enemy census. It does not detail auxiliary policy parameters, but those are largely infrastructure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compose') and a precise resource ('an attack roll's Advantage/Disadvantage'), naming the exact rules considered (Prone's 5-foot flip, Blinded, Restrained, etc.). This clearly distinguishes it from generic roll or check 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes that the tool is for attack-roll advantage/disadvantage calculation and even notes when ranged-attack rules apply. It does not explicitly name alternative tools or say 'use roll_compose for dice rolls,' but the usage context is unambiguous.
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?
No annotations are provided, so the description carries the full burden. It explicitly details condition behaviors (Blinded/Deafened auto-fail, Poisoned/Frightened Disadvantage, Exhaustion penalty, charmer Advantage), both invocation modes (with/without d20_result) including return shapes, and error behavior ('Missing required facts return exact paths; malformed inputs...return their structured recovery class'). This is exceptional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but structured, opening with the core purpose and then enumerating condition effects, modes, and error handling. Each sentence adds necessary information, though the semicolon-heavy condition list could be more readable. Slightly long but 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behavioral rules, both invocation modes, return value shapes (with/without d20_result), condition interactions, and error handling. Given the complex nested schema and no annotations, the description provides all essential context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description adds meaning beyond the schema: it explains check_requires semantics ('explicit empty array for neither'), ties target_charmed_by_actor to social Advantage, and specifies the two d20_result modes and their outputs. This helps the agent understand parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Adjudicate an ability check (a D20 Test) against a DC, condition-aware,' clearly specifying the verb, resource, and scope. It distinguishes from siblings like save_check via 'ability check' and from roll_compose by framing adjudication with condition effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the use case (ability checks vs DC) and condition handling, but never explicitly contrasts with alternatives such as save_check or attack_modifiers. However, the role is unambiguous due to the phrase 'ability check (a D20 Test)' and the detailed condition rules.
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, the description carries the full burden of behavioral disclosure. It openly states that false is illegal, omission is cannot-adjudicate, and that fictional possibility remains an authorized DM ruling (including agent-DM usage surfaced as data.gm_discretion). It also discloses the return shape ({grants_advantage}). These are non-obvious behaviors beyond 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, then logically structured by kind. Every sentence adds essential information without padding. It packs complex rules into a dense but readable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite many infra parameters (table_policy, asserted_facts, policy_context), the description focuses on the domain logic that an agent must know to invoke correctly: required facts and their constraints. It also notes the DM discretion mechanism. It does not explain the standard policy/context fields, but these are likely common across sibling tools and the output schema is present, so the description is largely complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (two booleans have descriptions), but the description adds significant semantic context: it explains that the boolean parameters must be explicit facts, false is illegal, and omission leads to cannot-adjudicate. It also clarifies the 'kind' enum and the meaning of the return value. This goes beyond the schema's bare types and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Adjudicate the Help action' with an SRD citation. It then breaks down the two supported kinds (ability-check and attack-roll), clearly distinguishing this tool from siblings like check_make or attack_modifiers. The scope 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use the tool: when adjudicating a Help action, and for each kind it states the explicit fact prerequisites (helper_has_relevant_proficiency for ability checks, enemy_within_5ft for attack rolls). It also explains illegal and cannot-adjudicate cases, implying the tool is only usable under those exact conditions. It does not name alternative tools, but the conditions are specific enough.
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 does this thoroughly: it explains exclusions (Disengage, Teleportation, forced movement, unseen mover), states that missing facts return 'cannot-adjudicate', and clarifies that a false prerequisite can short-circuit the need for other facts. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet concise: four sentences, each providing essential information. It front-loads the core question and immediately follows with conditions, exclusions, input requirements, and fallback behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, nested table policy objects, output schema), the description covers the core decision logic, exclusions, and missing-facts behavior well. The output schema handles return values. However, it does not explicitly mention how table_policy/table_decision or asserted_facts influence the outcome, which could be relevant given their presence in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 38% (3 of 8 params have descriptions). The description adds crucial semantics for the core decision params: movement_kind is required, and a voluntary path additionally needs leaves_reach and mover_seen_by_reactor. It also explains the 'cannot-adjudicate' behavior. It does not cover policy/context params, but those are likely common plumbing across sibling tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to determine if a creature's movement provokes an Opportunity Attack. It specifies exact conditions (leaves reach via own movement, visible to reactor) and explicitly lists what does NOT provoke, making it distinct from 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: it defines required inputs (movement_kind, and for voluntary movement leaves_reach and mover_seen_by_reactor), and it references reaction.available as a separate tool for checking reaction availability. However, it does not explicitly name sibling alternatives or state when not to use this tool.
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, the description carries the full burden. It discloses atomic compare-and-swap, idempotent retries returning the same receipt, stale-state rejection with reason_code 'stale-state', no server-side persistence, and the host requirement to store next_state only after exit_code 0. This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, behavioral guarantees, and host instruction. No wasted words, highly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 7 parameters and nested schemas, the description covers the essential workflow and state pact, though it doesn't explain optional params like table_policy. Since an output schema exists, return values need not be described. A 4 is fair.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 defines 'state' as the caller-owned current state and 'transition' as an event.apply proposal, and introduces next_state, exit_code, and reason_code. It does not detail optional parameters, but it covers the core required ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Verify and commit') and a clear resource ('one event.apply proposal against caller-owned current state'). It distinguishes itself from sibling tools by positioning as the commit phase following event.apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (after event.apply produces a proposal) and provides context about caller-owned state and the host's atomic store requirement. However, it does not explicitly name alternatives or exclusion conditions, so a 4 is appropriate.
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, the description fully explains behavior: deterministic DC formula, optional d20 check, return shape, and the caller-rolls convention. No side effects or hidden behaviors are involved for this pure computation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the formula, then states optional behavior and return values. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the large schema, the description covers the essential domain logic and return shape. The output schema exists, and the tool is a focused calculation, so the description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (38%), so the description compensates by explaining the key parameters: damage, d20_result, and con_modifier, including their optional relationship. It does not explain infrastructure params like table_policy or asserted_facts, but those are secondary to the tool's core purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Compute'), identifies the resource ('Concentration saving-throw DC'), and includes the exact formula and cap. It also distinguishes itself from sibling check-related tools by noting the caller rolls and 'srdcheck folds.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool ('when a concentrating creature takes damage') and explains the optional d20 resolution path. It lacks explicit named alternatives, but the context and division of responsibility are clear enough.
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, the description carries the full burden of behavioral disclosure. It states what the tool returns ({score}), when the score number appears, and how it handles invalid advantage/disadvantage input with an honest refusal. It also cites the SRD rule, providing strong transparency for a calculation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loads the core formula, and succinctly covers behavior, exclusions, and conditional output. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return structure in detail. It fully describes the formula, the refusal behavior for advantage/disadvantage, and the conditional absence of the score. It is complete for a stateless calculation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that perception_modifier feeds into the formula and that advantage/disadvantage trigger a refusal. Schema coverage is low (38%), and the description does not clarify generic parameters like table_policy or asserted_facts, but it sufficiently covers the tool's core domain-specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: computes Passive Perception using the SRD formula. It distinguishes itself from sibling tools (e.g., check_make, save_check) by explicitly noting that advantage/disadvantage is not part of the SRD passive formula and that passing these parameters triggers an honest refusal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 formula and gives an explicit exclusion: do not pass advantage/disadvantage because the SRD defines no adjustment for passive scores. However, it does not name alternative tools for active checks or other related operations, so it falls short of full 'when/when-not/alternatives' guidance.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/chaoz23/srdcheck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server