Poker Task Management MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific resources (Body, BuildupFactor, Detector, Source, Transform, Zone, Unit) and actions (analyze, apply, change, delete, execute, get, propose, update, validate). There is no ambiguity or overlap between tools, as each handles a unique operation on a specific entity in the radiation shielding calculation domain.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with the prefix 'poker_' (e.g., poker_deleteBody, poker_proposeDetector, poker_updateUnit). The naming is uniform across all 26 tools, using snake_case and clear action-resource combinations, making it highly predictable and readable.
Tool Count2/5
With 26 tools, the count is too high for typical MCP server scope, which usually benefits from 3-15 tools. While the domain (radiation shielding calculation) is complex, the tool set feels heavy and could overwhelm agents, suggesting potential over-fragmentation of operations.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for the domain, including propose (create), get, update, and delete operations for all key entities (Body, BuildupFactor, Detector, Source, Transform, Zone, Unit), plus analysis, validation, and execution tools. There are no obvious gaps, ensuring agents can handle full workflows without dead ends.
Average 2.8/5 across 26 of 26 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 40 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a creation/mutation operation, what permissions might be required, whether it's idempotent, or what happens on success/failure. The single sentence provides no behavioral context beyond the vague verb 'propose'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with one short sentence, this is under-specification rather than effective conciseness. The description fails to provide essential context that would help an agent understand and use the tool correctly, making it inefficient despite its brevity.
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?
Given the tool's complexity (7 parameters with nested objects, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a 'source' is in this domain, what 'proposing' entails, or what the expected outcome is. The agent would struggle to use this tool effectively based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 7 parameters. The description adds no parameter information beyond what's already in the structured schema, meeting the baseline score of 3 when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '新しい線源を提案します' (proposes a new source) is a tautology that restates the tool name 'poker_proposeSource' without adding specificity. It doesn't clarify what type of source (radiation source in a physics context) or distinguish it from sibling tools like 'poker_proposeBody' or 'poker_proposeDetector'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, context, or comparison with sibling tools like 'poker_updateSource' or 'poker_deleteSource'. The agent receives zero usage instructions.
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 for behavioral disclosure. It only states the action 'deletes' without addressing critical aspects: whether this is destructive (implied but not confirmed), what permissions are needed, if deletion is reversible, or what happens on success/failure. For a deletion 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, direct sentence in Japanese ('変換を削除します'), which is appropriately concise and front-loaded with the core action. There is no wasted text or unnecessary elaboration, making it efficient 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 as a deletion operation with no annotations and no output schema, the description is incomplete. It fails to address behavioral traits (e.g., destructiveness, error handling) or provide usage context, leaving gaps that could hinder an AI agent's ability to invoke it correctly. The high schema coverage helps with parameters but doesn't compensate for the lack of operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'name' documented as '削除する変換名' (name of the transformation to delete). The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 '変換を削除します' (deletes a transformation) states a basic action but lacks specificity about what 'transformation' means in this context. It doesn't distinguish this tool from sibling deletion tools like poker_deleteBody or poker_deleteZone, which suggests similar deletion operations on different resources. The purpose is stated but remains vague without clarifying 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 Guidelines1/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., if the transformation must exist), exclusions, or comparisons to sibling tools like poker_updateTransform or poker_proposeTransform. The description offers no context for usage decisions.
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 'proposes' a buildup factor, which implies a non-destructive, suggestion-generating operation, but it does not clarify whether this is a calculation, recommendation, or estimation, what the output might look like (e.g., numerical value, report), or any constraints like computational requirements. The description is too vague to adequately inform the agent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Japanese, making it efficient with no wasted words. However, it is under-specified rather than optimally concise, as it lacks necessary details for clarity and completeness. It is front-loaded but too brief to be fully helpful, so it scores a 4 for structure but loses points for insufficient content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by parameters related to corrections in a technical domain (likely radiation or physics), no annotations, and no output schema, the description is incomplete. It does not explain what a buildup factor is, the context of its use, what the tool returns, or how parameters influence the result. For a tool with three parameters and no structured output information, the description fails to provide adequate context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear parameter definitions: 'material' (material name), 'use_finite_medium_correction' (whether to use finite medium correction), and 'use_slant_correction' (whether to use slant correction). The description adds no additional meaning beyond the schema, such as explaining how these parameters affect the proposal or providing examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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 'ビルドアップ係数を提案します' (proposes a buildup factor) restates the tool name 'poker_proposeBuildupFactor' almost verbatim, making it tautological. While it indicates the tool suggests something related to buildup factors, it lacks specificity about what a buildup factor is, what domain this applies to (e.g., radiation physics, engineering), or how it differs from sibling tools like 'poker_changeOrderBuildupFactor' or 'poker_updateBuildupFactor'.
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 does not mention prerequisites, context (e.g., during simulation setup), or comparisons to sibling tools such as 'poker_changeOrderBuildupFactor' or 'poker_updateBuildupFactor', leaving the agent with no information to make an informed choice among related 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 but provides almost none. '提案します' (proposes) suggests a creation or submission action, but it doesn't clarify whether this is a write operation, what permissions might be required, whether it's idempotent, what happens on success/failure, or any side effects. The description adds no behavioral context beyond the vague action verb.
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 Japanese sentence. While it's under-informative, it doesn't waste words or bury information. Every word directly relates to the tool's purpose, making it structurally efficient despite its content deficiencies.
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 severely incomplete. It doesn't explain what a detector is, what proposing one achieves, how it relates to other poker tools, or what the expected outcome is. The combination of missing behavioral context and lack of purpose differentiation makes this inadequate for 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?
The description provides zero information about parameters. However, the schema description coverage is 100%, meaning all 5 parameters are documented in the schema itself (name, origin, grid, transform, show_path_trace). Since the schema does the heavy lifting, the baseline score of 3 is appropriate even though the description adds no parameter semantics.
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 '新しい検出器を提案します' (proposes a new detector) is a tautology that essentially restates the tool name 'poker_proposeDetector' without adding meaningful specificity. It doesn't explain what a 'detector' is in this context, what proposing entails (creation? configuration?), or how this differs from sibling tools like 'poker_proposeBody' or 'poker_proposeSource'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. There are multiple 'propose' tools in the sibling list (proposeBody, proposeSource, proposeTransform, etc.), but no indication of what distinguishes proposing a detector from proposing other entities. No prerequisites, constraints, or use cases 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 mentions analysis and calculation but doesn't specify whether this is a read-only operation, if it has side effects, requires permissions, or handles errors. For a tool with complex nested parameters, this lack of behavioral context 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 a single, efficient sentence in Japanese that clearly states the tool's function. It's front-loaded with the core purpose and avoids unnecessary details, making it appropriately concise for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of nested parameters and lack of annotations or output schema, the description is incomplete. It doesn't explain the tool's behavior, return values, or how to interpret results like physical consistency analysis, leaving the agent with insufficient information 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 schema description coverage is 100%, so the schema already documents the parameters well. The description adds minimal value by implying unit conversion and physical consistency analysis, but it doesn't provide additional details beyond what's in the schema, such as explaining the structure of 'targetUnits' or the meaning of 'includePhysicalAnalysis.' Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'analyzes and calculates conversion coefficients between different unit systems,' which provides a clear verb ('analyzes and calculates') and resource ('conversion coefficients'). However, it doesn't distinguish this from sibling tools like 'poker_getUnit' or 'poker_validateUnitIntegrity,' which may also involve unit-related operations, leaving the purpose somewhat vague in 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 offers no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to siblings such as 'poker_getUnit' or 'poker_validateUnitIntegrity,' leaving the agent without context for 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 the action ('changes the order') but lacks critical behavioral details: whether this is a mutation or proposal, if it requires specific permissions, what happens on success/failure, or if there are side effects. For a tool that likely modifies data, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's action. It's appropriately sized and front-loaded with the core purpose. However, it could be slightly more specific (e.g., clarifying what 'buildup factors' are in this context) 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 the complexity of a reordering operation with no annotations and no output schema, the description is incomplete. It doesn't explain what 'buildup factors' are, how the order affects the system, what the valid range for 'newIndex' is beyond the schema's minimum, or what the tool returns. For a mutation tool in a technical domain, 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 100%, with clear parameter descriptions: 'material' (material name to reorder) and 'newIndex' (new index position). The description adds no additional parameter semantics beyond what the schema provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'ビルドアップ係数の順序を変更します' (changes the order of buildup factors) states a clear verb ('変更します' - changes) and resource ('ビルドアップ係数の順序' - order of buildup factors), but it's vague about what exactly is being reordered. It doesn't distinguish from siblings like 'poker_updateBuildupFactor' or 'poker_proposeBuildupFactor', leaving ambiguity about whether this is a proposal, update, or direct mutation.
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 'poker_updateBuildupFactor' and 'poker_proposeBuildupFactor', the description offers no context about prerequisites, when this tool is appropriate, or what distinguishes it from other buildup factor operations. This leaves the agent guessing about the tool's specific role.
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 'automatic backup' which suggests some safety mechanism, but doesn't explain what 'propose' means operationally (is this a draft creation? does it require approval?), what permissions are needed, whether this is a read or write operation, or what happens on success/failure. For a complex 25-parameter tool with no annotations, 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 extremely concise - a single Japanese sentence that states the core function. While efficient, it may be too brief given the tool's complexity. There's no wasted text, but it might benefit from slightly more context given the 25 parameters and lack of annotations.
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 25-parameter tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after proposal, what the 'automatic backup' entails, what domain this operates in (CAD? simulation?), or what the expected outcomes are. The description fails to provide adequate context for proper tool selection and 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 schema has 100% description coverage, providing detailed parameter documentation including coordinate formats and type-specific usage. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'proposes a new 3D solid (with automatic backup)', which provides a general purpose but lacks specificity. It doesn't clearly distinguish what makes this different from sibling tools like 'poker_updateBody' or 'poker_deleteBody', nor does it specify what kind of 3D solid creation system this is for. The purpose is understandable but vague about the domain 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 siblings like 'poker_updateBody' and 'poker_deleteBody' available, there's no indication whether this is for initial creation versus modification, or what prerequisites might be needed. The mention of 'automatic backup' hints at a safety feature but doesn't explain 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 full burden. It states 'updates parameters' which implies a mutation, but doesn't disclose behavioral traits like whether changes are reversible, permission requirements, side effects, or error handling. For a complex update tool with 24 parameters, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese ('既存立体のパラメータを更新します'), which is appropriately sized and front-loaded. There's no wasted text, making it concise. However, it could be more structured if it included key details upfront.
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 (24 parameters, mutation operation) and lack of annotations and output schema, the description is incomplete. It doesn't explain what happens after the update (e.g., success response, error cases), or provide context on the solid types or parameter constraints beyond the schema. For such a tool, 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 100%, with detailed descriptions for all 24 parameters in the input schema. The description adds no additional meaning beyond the schema, which already explains each parameter (e.g., '新しい底面中心座標' for bottom_center). Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with context like parameter interactions.
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 '既存立体のパラメータを更新します' (Updates parameters of an existing solid) clearly states the verb ('updates') and resource ('parameters of an existing solid'), but it's vague about what kind of solid or which parameters. It doesn't distinguish from siblings like poker_updateTransform or poker_updateZone, which also update things. The purpose is understandable but lacks specificity.
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 poker_proposeBody (propose) and poker_deleteBody (delete), the description doesn't explain prerequisites (e.g., need an existing solid), appropriate contexts, or exclusions. It's a basic statement with no 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's an update operation, implying mutation, but doesn't cover critical aspects like permissions needed, whether changes are destructive or reversible, error handling, or rate limits. 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 a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more informative 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 tool's complexity (a mutation operation with 3 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to provide necessary context such as behavioral traits, usage scenarios, or output expectations, 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what's in the schema, which has 100% coverage with clear descriptions for all three parameters (material, use_finite_medium_correction, use_slant_correction). Since schema coverage is high, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '既存ビルドアップ係数の設定を更新します' (Updates existing buildup factor settings) clearly states the action (update) and target (buildup factor settings), but it's somewhat vague about what 'buildup factor' entails and doesn't distinguish from siblings like 'poker_changeOrderBuildupFactor' or 'poker_proposeBuildupFactor'. It avoids tautology by not just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as how it differs from 'poker_changeOrderBuildupFactor' or 'poker_proposeBuildupFactor', leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '更新します' (updates) implies a mutation, the description doesn't specify permissions required, whether changes are reversible, error conditions, or what happens to unspecified operations. It lacks details on rate limits, side effects, or response format, which are critical for a mutation tool with no structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a basic update operation, though it could be more front-loaded with key details if expanded for better 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 as a mutation with 2 parameters and no annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, permissions, or what the update entails (e.g., whether it replaces all operations or merges them). For a tool that modifies data, more context is needed to ensure safe and correct usage by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('name' as the transformation name to update, 'operations' as an array of new transformation operations). The description adds no additional meaning beyond the schema, such as explaining the structure of operations (e.g., rotate_around_x/y/z and translate) or providing examples. Since the schema is well-documented, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '既存変換の操作を更新します' (Updates operations of an existing transformation) states a clear verb ('更新します' - updates) and resource ('既存変換の操作' - operations of an existing transformation), but it's somewhat vague about what 'operations' entail and doesn't distinguish this tool from sibling update tools like poker_updateBody or poker_updateZone, which follow the same pattern for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing transformation), exclusions, or comparisons to sibling tools like poker_proposeTransform (for creation) or poker_deleteTransform (for deletion), 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive validation' but fails to describe what the tool actually does behaviorally—e.g., whether it performs read-only checks, modifies data, requires specific permissions, or handles errors. This leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary elaboration. It is front-loaded and avoids redundancy, though it could be slightly more informative 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 implied by 'comprehensive validation' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the validation entails, what outputs or errors to expect, or how it interacts with the system, making it inadequate for a tool with potential operational nuances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('generateReport' and 'includeSystemAnalysis') with clear descriptions. The tool description adds no additional meaning or context about these parameters beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool performs 'comprehensive validation of 4-key completeness and physical integrity of unit systems,' which gives a general purpose but lacks specificity about what '4-key' refers to or what constitutes 'physical integrity.' It distinguishes from siblings like 'poker_analyzeUnitConversion' by focusing on validation rather than analysis, but remains somewhat vague in its 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 explicit guidance is provided on when to use this tool versus alternatives. The description implies it's for validation, but it doesn't specify scenarios, prerequisites, or exclusions compared to siblings like 'poker_getUnit' or 'poker_updateUnit,' leaving the agent without clear 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 destructive action ('削除します' - deletes) but doesn't disclose behavioral traits like whether deletion is permanent, requires specific permissions, has side effects, or provides confirmation. 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 in Japanese with zero waste. It's appropriately sized and front-loaded, directly stating the 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 this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after deletion (e.g., success confirmation, error handling), nor does it address safety concerns or dependencies. The minimal description fails to compensate for the lack of structured 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 100%, with the parameter 'name' documented as '削除する検出器の名前' (name of the detector to delete). The description adds no additional meaning beyond what the schema provides, such as format constraints or examples. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '検出器を削除します' (deletes a detector) states a clear verb+resource action, but it's vague about what a 'detector' is in this context and doesn't differentiate from sibling tools like poker_deleteBody or poker_deleteZone. It provides basic purpose but lacks specificity about the domain or 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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing detector), exclusions, or relationships with sibling tools like poker_proposeDetector or poker_updateDetector. The description offers no 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 of behavioral disclosure. The description only states that it 'proposes' transformations, which implies a non-destructive, suggestion-making operation, but doesn't clarify if this creates a draft, requires approval, affects system state, or has any side effects. For a tool with zero annotation coverage, this is insufficient 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 a single, efficient sentence in Japanese ('回転・移動変換を提案します') that directly states the tool's function. It is front-loaded with the core purpose and has no wasted words, making it highly concise and well-structured for 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?
Given the complexity of transformation operations (with nested objects for operations) and no annotations or output schema, the description is incomplete. It doesn't explain what happens after proposing (e.g., whether a transformation object is created, returned, or requires further steps), nor does it provide context about the transformation domain (e.g., 3D geometry, physics simulations). This leaves significant gaps for an AI agent to understand the tool's full role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear documentation for both parameters (name and operations). The description adds no additional meaning beyond what the schema provides—it doesn't explain parameter relationships, constraints, or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'proposes rotation/movement transformations' which is clear but vague. It uses a specific verb ('proposes') and identifies the resource ('transformations'), but doesn't specify what is being transformed or distinguish it from sibling tools like poker_proposeBody or poker_proposeZone. The purpose is understandable but lacks specificity about the transformation context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools with 'propose' in their names (e.g., poker_proposeBody, poker_proposeZone), but no indication is given about when to propose a transformation versus proposing other entities. No prerequisites, exclusions, or alternative tools 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 mentions 'physical verification' but doesn't explain what this entails—whether it's a validation step, if changes are applied immediately, or what happens on failure. For a proposal tool with mutation implications, 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 in Japanese that directly states the tool's purpose. It's front-loaded with no wasted words, 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 proposing a material zone with physical verification, no annotations, and no output schema, the description is incomplete. It fails to explain the verification process, success/failure outcomes, or how this tool interacts with others in the workflow, leaving significant gaps for an 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 input schema has 100% description coverage, clearly documenting all three parameters. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.
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 'proposes a material zone (with physical verification)', which provides a basic verb+resource combination. However, it doesn't clearly differentiate from sibling tools like 'poker_proposeBody' or 'poker_updateZone', leaving the specific scope of 'material zone' versus other zone types 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 explicit guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, timing, or comparisons to sibling tools such as 'poker_updateZone' or 'poker_deleteZone', leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Updates parameters' implies a mutation operation, but the description doesn't disclose critical behavioral aspects: whether this requires specific permissions, what happens to existing data not mentioned in the update, whether the operation is atomic or partial, error conditions, or what the response contains. For a complex mutation tool with 6 parameters including nested objects, 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 in Japanese that directly states the tool's purpose. There's zero waste or redundancy. It's appropriately sized for what it communicates, though what it communicates is limited. The structure is front-loaded with the core functionality.
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 mutation tool with 6 parameters (including nested objects with oneOf constraints), no annotations, and no output schema, the description is inadequate. It doesn't explain the update semantics, error handling, permissions, or what constitutes a successful update. The agent would struggle to understand the behavioral context needed to use this tool correctly despite the comprehensive schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly with descriptions, constraints, and complex oneOf structures. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify the overall update semantics. Baseline 3 is appropriate when the schema does all the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'updates parameters of existing radiation sources' which is a clear verb+resource combination, but it's quite generic and doesn't differentiate from sibling tools like poker_updateBody or poker_updateDetector. It specifies 'existing radiation sources' which helps scope the operation, but lacks specificity about what distinguishes this update operation from other update tools 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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling update tools (poker_updateBody, poker_updateDetector, etc.) but no indication of when this specific radiation source update tool is appropriate versus other operations. No prerequisites, constraints, or alternative tools 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. While '削除します' (delete) implies a destructive mutation, the description doesn't specify whether this operation is reversible, what permissions are required, what happens to dependent data, or what the response looks like. For a destructive tool with zero annotation coverage, this is a significant gap 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.
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 for a simple deletion operation and front-loads the essential information. 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 this is a destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after deletion, whether there are confirmation steps, error conditions, or what the return value contains. The context signals indicate a simple parameter structure, but the behavioral aspects are critically under-specified for a deletion 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?
The input schema has 100% description coverage, with the single parameter 'material' clearly documented as '削除する材料名' (material name to delete). The description doesn't add any additional parameter semantics beyond what the schema provides, such as format examples or constraints. With complete schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('削除します' - delete) and the resource ('ビルドアップ係数' - buildup factor), providing a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'poker_deleteBody' or 'poker_deleteDetector' that also perform deletion operations on different resources, so it doesn't fully differentiate 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. There are multiple sibling tools with 'delete' operations (e.g., poker_deleteBody, poker_deleteDetector) and related 'buildup factor' tools (e.g., poker_proposeBuildupFactor, poker_updateBuildupFactor), but the description doesn't indicate when this specific deletion is appropriate or what distinguishes it from other deletion or buildup factor 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions execution but doesn't describe what happens during execution (e.g., computational intensity, side effects, file system changes, or error handling). The description lacks critical behavioral context like whether this is a long-running process, if it modifies input files, or what authentication/rate limits apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function. It's appropriately sized and front-loaded with the core action. However, it could be slightly more structured by explicitly mentioning the tool's domain (radiation shielding) earlier.
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 with nested objects, no output schema, and no annotations), the description is incomplete. It doesn't explain what the tool returns, how results are delivered, or behavioral aspects like execution time or error conditions. For a calculation execution tool with rich input schema but no output schema, 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 100%, so the schema already documents all three parameters thoroughly. The description adds no parameter-specific information beyond implying a YAML file is needed. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance understanding of parameter relationships or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'execute radiation shielding calculation using poker_cui with created YAML file.' It specifies the verb ('execute calculation') and resource ('YAML file'), but doesn't differentiate from sibling tools like poker_analyzeUnitConversion or poker_validateUnitIntegrity, which appear to be analysis/validation tools rather than execution 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 minimal guidance: it mentions using 'created YAML file' which implies a prerequisite, but doesn't specify when to use this tool versus alternatives. No explicit when/when-not instructions or sibling tool comparisons are provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. '更新します' (updates) implies a mutation operation, but it doesn't specify required permissions, whether changes are reversible, error handling, or side effects. It mentions updating parameters but doesn't clarify if all parameters must be provided or if partial updates are allowed. 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 Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a basic update operation and front-loads the essential information. Every word earns its place 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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or error conditions. While the schema covers parameter details, the description fails to provide the contextual information needed for safe and effective tool invocation in a complex system with multiple update 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 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between parameters or provide usage examples). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't 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 '既存検出器のパラメータを更新します' (Updates parameters of an existing detector) clearly states the action (update) and target resource (detector parameters). It distinguishes from siblings like poker_deleteDetector and poker_proposeDetector by specifying 'update' rather than delete or create. However, it doesn't explicitly differentiate from poker_updateBody or poker_updateZone which have similar update patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., detector must exist), when not to use it (e.g., for creating new detectors), or refer to sibling tools like poker_proposeDetector for creation or poker_deleteDetector for removal. 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 full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't disclose critical behavioral traits: whether it requires specific permissions, what happens if the zone doesn't exist, whether changes are reversible, if it affects related entities, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that directly states the tool's purpose. There's no wasted verbiage or unnecessary elaboration. It's appropriately sized for a straightforward update 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address what happens on success/failure, what permissions are needed, or what the tool returns. Given the complexity of updating physical properties (density with min/max constraints) in what appears to be a physics/simulation context, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions '材料や密度' (material and density) which aligns with two parameters, but doesn't provide additional context about parameter interactions or usage. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('更新します' - updates) and the target resource ('既存ゾーンの材料や密度' - existing zone's material and density). It distinguishes from siblings like 'poker_updateBody' or 'poker_updateUnit' by specifying it updates zones specifically. However, it doesn't explicitly mention what 'zone' refers to in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing zone), when not to use it, or how it differs from similar tools like 'poker_updateBody' or 'poker_proposeZone'. The agent must infer usage from the name and 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 the full burden of behavioral disclosure. While '削除します' clearly indicates a destructive operation, the description doesn't mention important behavioral aspects like whether the deletion is permanent/reversible, what permissions are required, whether there are dependencies or constraints, or what happens to related data. For a destructive operation 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 extremely concise - a single Japanese sentence that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. It's front-loaded with the essential information about what the tool does.
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 and no output schema, the description is insufficiently complete. It doesn't address critical context like what happens after deletion (confirmation? error handling?), whether there are preconditions or dependencies, or what the tool returns. The description provides only the basic purpose without the behavioral context needed for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'name' clearly documented as '削除対象線源名' (name of the radiation source to delete). The description doesn't add any parameter information beyond what's in the schema, but with complete schema coverage and only one parameter, the baseline is appropriately high. The description implicitly confirms this is about radiation sources, which aligns with the parameter 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 ('削除します' - deletes) and the resource ('放射線源' - radiation source), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling deletion tools like poker_deleteBody, poker_deleteBuildupFactor, poker_deleteDetector, poker_deleteTransform, or poker_deleteZone, which all perform deletion operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple deletion tools in the sibling list (deleteBody, deleteBuildupFactor, deleteDetector, deleteTransform, deleteZone), but the description doesn't indicate when this specific radiation source deletion tool is appropriate versus those other deletion operations.
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 reveals the tool performs deletion with dependency checking, which is valuable context about safety mechanisms. However, it doesn't disclose other critical behaviors like whether deletion is permanent, what permissions are required, error conditions, or what happens to dependent objects. The description adds some value but 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 - a single Japanese sentence that directly states the tool's function. Every word earns its place: '立体を削除します' establishes the core action, and '（依存関係チェック付き）' adds important behavioral context. No wasted words or redundant 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 destructive deletion tool with no annotations and no output schema, the description is insufficient. It mentions dependency checking but doesn't explain what that entails, what the tool returns, error handling, or confirmation requirements. Given the high-stakes nature of deletion operations and the lack of structured safety annotations, more comprehensive description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'name' parameter thoroughly. The description doesn't add any meaningful semantic context beyond what's in the schema - it doesn't explain naming conventions, format requirements, or provide examples. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('削除します' - deletes) and the resource ('立体' - solid/body), making the purpose understandable. It distinguishes from siblings by specifying '立体' rather than other resources like 'BuildupFactor' or 'Detector'. However, it doesn't explicitly contrast with 'poker_updateBody' or other body-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 'poker_updateBody' or 'poker_proposeBody'. It mentions '依存関係チェック付き' (with dependency check) which hints at a specific context, but doesn't explicitly state when this tool is appropriate or what prerequisites exist for safe deletion.
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 it indicates this is a destructive operation (deletion), it doesn't mention important aspects like whether this requires specific permissions, whether the deletion is reversible, what happens to associated data, or any rate limits. The ATMOSPHERE exclusion 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 extremely concise - a single Japanese sentence that communicates the core action and a key constraint. There's no wasted language, 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.
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 incomplete. It doesn't explain what happens after deletion, whether there are confirmation steps, error conditions, or what the return value might be. The ATMOSPHERE constraint is helpful but doesn't compensate for the missing behavioral 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 schema description coverage is 100%, with the single parameter 'body_name' clearly documented in the schema as '削除するゾーンの立体名' (3D name of the zone to delete). The description adds no additional parameter information beyond what the schema already provides, which is acceptable 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 ('削除します' - deletes) and resource ('ゾーン' - zone), making the purpose understandable. However, it doesn't distinguish this from sibling tools like poker_deleteBody or poker_deleteSource, which also perform deletions on different resources.
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 some usage context by specifying 'ATMOSPHERE以外' (except ATMOSPHERE), which implies when NOT to use this tool. However, it doesn't explicitly mention when to use this versus alternatives like poker_deleteBody or provide broader context about the deletion operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions '完全性保証' (completeness guarantee) which adds some behavioral context about reliability. However, it doesn't disclose important traits like whether this is a read-only operation, potential rate limits, authentication needs, or what happens if no unit settings exist. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence that efficiently communicates both the action and the guarantee. Every word earns its place with no redundancy. The Japanese text is direct 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is reasonably complete for a basic retrieval operation. However, without annotations or output schema, it should ideally specify the return format more clearly (e.g., structure of the 4 keys). The 'completeness guarantee' adds value but doesn'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?
The tool has 0 parameters, so there's no parameter documentation needed. The description appropriately focuses on what the tool returns rather than inputs. With 100% schema description coverage (though empty properties), the baseline would be 3, but for zero-parameter tools, a score of 4 is justified as the description correctly indicates no parameters are required.
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 current unit settings) and specifies it returns all four keys. It distinguishes from siblings by focusing on retrieval rather than creation/update/deletion operations. However, it doesn't explicitly differentiate from 'poker_validateUnitIntegrity' which might also involve unit checking.
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, timing considerations, or comparison to sibling tools like 'poker_updateUnit' or 'poker_proposeUnit'. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it's a partial update ('部分更新可能') and maintains a 4-key structure ('4つのキーは常に維持'), which helps understand its mutation behavior. However, it lacks details on permissions, side effects, or response format, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, stating the core action and key constraint in one sentence. It avoids unnecessary elaboration, though it could be slightly more structured (e.g., separating purpose from behavior).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is moderately complete. It covers the update action and structural constraints, but lacks details on error handling, return values, or integration with sibling tools, which would be needed 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 100%, with each parameter (angle, density, length, radioactivity) well-documented in the schema, including enums. The description adds minimal value beyond the schema by noting the 4-key structure and partial update capability, but doesn't explain parameter interactions or usage beyond what's already structured.
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 ('更新します' - updates) and resource ('既存単位設定' - existing unit settings), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'poker_getUnit' (read) or 'poker_proposeUnit' (create), which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing unit to update), exclusions, or comparisons to siblings like 'poker_proposeUnit' for creation or 'poker_getUnit' for reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it applies changes to actual files (implying mutation/destructive action), performs automatic backup (safety measure), and handles 'all pending changes' (scope). However, it doesn't detail error handling, permissions required, rate limits, or what 'pending changes' entails, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Japanese that front-loads the core action ('apply all pending changes') and includes essential context (automatic backup). Every word contributes meaning without redundancy, making it appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and behavioral hints but lacks details on error cases, return values, or system state changes. For a mutation tool that applies changes to files, more context on outcomes (e.g., success confirmation, rollback on failure) would improve completeness, though the concise description covers minimum essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no specific parameter semantics beyond implying that 'backup_comment' relates to the automatic backup mentioned, and 'force' might override warnings. This meets the baseline of 3 since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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') and target ('pending changes to actual YAML files'), specifying the scope ('all pending changes') and mentioning automatic backup execution. It distinguishes from siblings like 'propose' or 'update' tools by focusing on finalizing changes rather than creating or modifying individual components. However, it doesn't explicitly contrast with specific alternatives like 'poker_executeCalculation'.
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 pending changes need to be finalized, suggesting a workflow where changes are first proposed then applied. It mentions automatic backup, hinting at a safety measure. However, it lacks explicit guidance on when NOT to use this tool (e.g., if no pending changes exist) or clear alternatives among siblings, leaving some ambiguity about the exact triggering 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 mentions '4キー完全性保証' (guarantees completeness of 4 keys), which adds behavioral context about required parameters. However, it lacks details on side effects (e.g., whether this writes to the YAML file), error handling, or response format. For a mutation tool with no annotations, this is a moderate 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 extremely concise: one sentence in Japanese that efficiently states the purpose, condition, and key guarantee. It's front-loaded with the main action and wastes no words, earning its place fully.
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 usage condition but lacks details on behavioral traits (e.g., mutation effects) and return values. For a tool that likely modifies a YAML file (implied by '提案します'), more context on outcomes would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters with enums and defaults. The description adds minimal value beyond the schema by implying the 4 keys are mandatory ('4キー完全性保証'), but doesn't provide additional semantics like usage examples or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '単位設定セクションを提案します' (proposes a unit settings section). It specifies the condition 'YAMLファイルに未存在の場合のみ' (only when not already existing in the YAML file), which adds specificity. However, it doesn't explicitly differentiate from sibling tools like 'poker_updateUnit' or 'poker_getUnit', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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: 'YAMLファイルに未存在の場合のみ' (only when not already existing in the YAML file). This indicates when to use this tool (for initial proposal) versus alternatives like update tools. However, it doesn't explicitly name alternatives or state when-not to use it, 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.

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:

[![poker_mcp MCP server](https://glama.ai/mcp/servers/Hirao-Y/poker_mcp/badges/card.svg)](https://glama.ai/mcp/servers/Hirao-Y/poker_mcp)

Score Badge

Copy to your README.md:

[![poker_mcp MCP server](https://glama.ai/mcp/servers/Hirao-Y/poker_mcp/badges/score.svg)](https://glama.ai/mcp/servers/Hirao-Y/poker_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/Hirao-Y/poker_mcp'

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