trpg-dice-mcp

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool targets a distinct aspect of TRPG rolling: basic dice expressions, tables, skill checks, dice pools, FATE dice, arbitrary selection, history, hidden roll reveal, and opposed checks. No two tools have overlapping purposes, and the descriptions clarify niche uses like d66 or nested triggers.
Naming Consistency5/5
All tool names follow a clear verb_first_noun pattern in snake_case (roll_dice, roll_table, pick_random, get_roll_history, reveal_hidden_roll). The roll_* prefix is used for dice-related tools, with only opposed_check deviating slightly but still readable and consistent in style.
Tool Count5/5
9 tools is well-scoped for a TRPG dice server, covering the core surface without bloat. Each tool serves a distinct gameplay need, from basic rolls to history management, making the count appropriate.
Completeness5/5
The tool set covers the full life cycle of dice rolls: rolling (multiple types), evaluating checks/pools, handling tables, tracking history, revealing hidden rolls, and even opposed checks. Missing operations like clearing history or editing rolls are not essential for the domain, so the surface feels complete.
Average 3.7/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no safety signal (all false). The description does not disclose how success/failure is computed, whether results include criticals, what hidden or bonus_dice do, or if there are side effects. It only shows input examples, leaving the actual behavior opaque.
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 succinct, starting with the core purpose and then providing four concrete examples that add value without redundancy. It is well-structured and easy to scan, though it could have added parameter details without becoming bloated.
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 12 parameters and no output schema, the description covers only a subset of use cases. It omits return value format, handling of hidden rolls, locale behavior, reason tagging, and advanced features like custom degrees, leaving significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage, the description compensates partially by illustrating preset, target, dice, and advantage in examples. However, many parameters (mode, times, hidden, locale, reason, bonus_dice, degrees) lack explanatory context, and the description does not clarify how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs 'skill/attribute checks' and supports multiple rule presets and custom success levels. The examples (CoC 7e, D&D 5e, PbtA, advantage) leave no ambiguity about its purpose, distinguishing it from generic dice rollers like roll_dice.
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 examples imply usage for tabletop RPG checks, but the description does not explicitly state when to prefer this over siblings like roll_dice, roll_pool, or opposed_check. There is no mention of exclusions or alternative conditions, so guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the full burden of behavioral disclosure. It mentions 4dF, modifier, and ladder evaluation, but does not disclose side effects, whether the roll is random, if it affects game state, or what the return format is. This is minimal transparency for an action that could have non-deterministic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line plus a usage example. It is front-loaded and every word adds value. However, it is slightly under-specified, leaving key aspects unexplained, so it loses one point for efficiency over completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns (beyond 'ladder evaluation'), how hidden/tags/locale/reason affect behavior, or what outputs the caller can expect. This is inadequate for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only difficulty has a description). The description's example and text clarify 'modifier' and 'difficulty' roles, but parameters like tags, hidden, locale, and reason remain undocumented in both schema and description. This is insufficient compensation for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is FATE-system-specific: 'FATE 系统专用：4dF + 修正值，带梯形评价' (FATE system exclusive: 4dF + modifier, with ladder evaluation). This specifies the verb (roll), the resource (FATE dice), and distinguishes it from siblings like roll_dice or roll_check that are likely more generic.
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 gives some context by declaring it as FATE-system exclusive, implying use for FATE rolls. However, it does not explicitly compare with alternatives like roll_check or roll_pool, nor state when not to use it. The example 'roll_fate modifier=3 difficulty=2' demonstrates usage but lacks exclusion guidance.
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?
The description discloses the core comparison behavior (margin/total/success) and example parameters, but it does not mention side effects like random generation, roll history, or hidden-roll behaviors. With annotations all false, the description carries the burden but only partially covers it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by two useful examples. The structure is clear and each sentence earns its place, though the examples take some space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (13 params, 4 enums) and no output schema, the description is incomplete. It does not cover many parameters, does not explain return values, and lacks discussion of edge cases (e.g., ties). The examples help but are insufficient for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 15% (only actor1/actor2 have basic descriptions). The description's examples add meaning for preset, target, dice, mode, and actor modifiers, but many parameters (resolution, degrees, times, hidden, locale, reason) remain unexplained. It compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an opposed check ('双方对抗检定') and compares two characters' margin/total/success to determine a winner. This specific verb+resource distinguishes it from siblings like roll_check or roll_dice.
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 examples imply usage contexts (CoC, D&D initiative) but do not explicitly state when to use this tool over alternatives or provide exclusions. There is no mention of 'use this when' or 'don't use for single checks'.
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?
Annotations are all false and provide no safety profile. The description discloses no side effects, such as whether rolls are recorded in history or how hidden rolls behave, despite the presence of a 'hidden' parameter. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by concise examples that illustrate each mode. The examples are valuable and not wasteful, though they make the description longer than strictly necessary.
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?
With 9 parameters and no output schema, the description leaves many parameters undocumented and does not describe the return format or how nested triggers affect output. It covers core behavior, but the tool's complexity demands more complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema by explaining the options structure (label, min/max, weight, trigger_roll) and dice usage across three modes. This compensates for the low schema coverage, though secondary parameters like tags, times, locale, and reason remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws results from a random table and details three mutually exclusive modes (range, weight, equal probability) plus nested triggers. This specific verb+resource structure distinguishes it from sibling roll tools like roll_dice or roll_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for random table rolling through examples and the term 'random table', but it never explicitly contrasts with alternatives or provides when-not-to-use guidance. No exclusions are stated, so the guidance is only implicit.
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?
The annotations do not indicate read-only (readOnlyHint=false), and the description says 'unlock', implying a state change. Yet it does not disclose whether the reveal is permanent, whether it affects all players, or any authorization requirements. The description carries a low burden but still lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus two examples. It leads with the primary purpose and includes only necessary details, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description states the return value ('完整掷骰明细') but does not detail output structure or edge cases. Given no output schema, more detail could be expected, but for a simple reveal tool, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the schema already describes roll_id and reason. The description adds useful examples of roll_id formats (h7, #h12) and reason usage, but does not explain locale. The baseline of 3 is appropriate since the schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: unlocking and viewing hidden dice roll results and returning complete roll details. It uses a specific verb-resource pair ('解锁查看' / '暗骰结果') and is easily distinguished from sibling rolling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hidden rolls and provides examples, making the context clear. However, it does not explicitly state when not to use it (e.g., for normal rolls), but sibling tools like roll_dice provide sufficient contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the algorithm (Fisher-Yates shuffle) and cryptographic randomness, which adds behavioral context beyond the sparse annotations that only set all hints to false. It does not mention potential side effects or state changes, but since this is a pure selection tool, that omission is minor.
Agents need to know what a tool does to the world before 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 remarkably concise: one sentence describing the core behavior plus two illustrative examples. Every word earns its place, and the examples are compact and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core functionality is well-covered with examples, and the algorithm note is useful. However, with 7 parameters, no output schema, and several optional parameters (hidden, tags, locale, reason) undocumented, the description is not fully complete for advanced or edge-case use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description only illustrates items, count, and unique via examples. The parameters tags, hidden, locale, and reason are left unexplained, so the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '从列表中随机抽取' (randomly draw from a list), and the examples with initiative order and card draws make the resource and action unambiguous. This distinguishes it well from sibling tools like roll_dice or roll_table, which are for other random generation tasks.
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 examples imply clear usage scenarios (shuffling initiative order, drawing cards) and the description notes the no-replacement behavior via the example. However, it does not explicitly mention when not to use the tool or compare it to alternatives like roll_table.
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?
Annotations provide no behavioral hints (all false), so the description carries the burden. It does not disclose that rolls are random, that results may be recorded (given get_roll_history sibling), or that hidden rolls are excluded from context—though the 'hidden' parameter schema touches on the latter. The description focuses on expression syntax rather than operational behavior, which is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single introductory sentence followed by a well-formatted list of examples. It is front-loaded with the purpose, and every line adds value—no filler. The structure makes it easy to scan and understand the tool's capabilities quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 7 parameters, the description provides a solid overview and expression examples, but it does not explain parameters like 'times', 'hidden', 'locale', or 'reason'—though the schema descriptions cover them. It also does not mention recording behavior or how this relates to sibling tools. Given the schema's coverage, this is reasonably complete for a dice roller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), and the description adds significant value for the core 'expression' parameter by providing concrete usage examples (e.g., '4d6kh3', '(8d6)/2', 'd66') that clarify syntax beyond the schema's brief description. It also mentions rounding functions, aligning with the 'rounding' parameter. Other parameters are left to the schema, which is acceptable given their self-descriptive schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool rolls dice and evaluates arithmetic expressions, with a specific resource (dice expression) and scope (supports four operations, parentheses, rounding, and all modifiers). The examples differentiate it from siblings by showcasing general-purpose expression handling (e.g., 4d6kh3, d%, 4dF), implying broader capability than specialized tools like roll_pool or roll_fate.
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 clear context for use—any time a dice expression with arithmetic/modifiers is needed—but it does not explicitly state when NOT to use it or mention alternatives like roll_check or roll_table. Usage is implied through examples rather than explicit guidance.
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?
Annotations are all false (e.g., readOnlyHint false), suggesting the tool may have side effects such as recording history or hidden rolls. The description does not mention these behaviors, nor does it explain output format or whether multiple rolls are supported (times parameter). However, it does add context about glitch/critical mechanics (ones_glitch, tens_crit) which enriches the behavioral understanding beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and structured: a one-line purpose followed by three clear example configurations. Every sentence adds value, and the examples are well-formatted for quick reference. No wasted words.
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?
Despite the complexity of the tool (15 parameters, no output schema), the description does not explain the return value format, the meaning of hidden, times, explode_on, explode_limit, double_success_on, or locale. It also omits any mention of edge-case behaviors, leaving significant gaps for an agent to understand full functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%). The description compensates with concrete examples for Shadowrun, WoD, and Year Zero, showing how to set key parameters like count, sides, target, success_condition, ones_glitch, ones_cancel, and tens_crit. While not all 15 parameters are explained, the examples clarify the most important ones and illustrate the intended usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '骰池检定（Shadowrun / WoD / Year Zero 等）' and '统计满足条件的成功骰数', which translates to 'dice pool check' and 'count successful dice meeting conditions'. It specifies the resource (dice pool check) and differentiates from siblings like roll_dice or roll_check by focusing on pool-based systems and success counting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, listing specific game systems (Shadowrun, WoD, Year Zero) and example parameter configurations for each. It implicitly guides the agent to use this tool for dice pool mechanics, though it does not explicitly state exclusions or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a read-only, non-destructive operation. The description adds valuable context that hidden rolls only show '结果保密' (result confidential), disclosing a key behavioral trait not evident from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the primary purpose, and then uses concise examples to demonstrate usage. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality, hidden-roll behavior, and usage patterns. It omits output format, but no output schema is provided, and the examples sufficiently guide the agent for common query needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the description compensates by illustrating offset usage (limit=10, offset=10), clarifying pagination. The tag example reinforces filtering. It does not cover locale, but the enum in schema handles that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '查询掷骰历史' (query dice roll history), a specific verb+resource combination. It distinguishes from sibling roll tools, and the note about hidden rolls adds important scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage examples (limit, tag, pagination) and implies that hidden rolls are not fully visible, guiding agents to not expect reveal functionality here. However, it does not explicitly name alternative tools like reveal_hidden_roll for full results.
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:

[![trpg-dice-mcp MCP server](https://glama.ai/mcp/servers/Komeiji-Shiki/trpg-dice-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Komeiji-Shiki/trpg-dice-mcp)

Score Badge

Copy to your README.md:

[![trpg-dice-mcp MCP server](https://glama.ai/mcp/servers/Komeiji-Shiki/trpg-dice-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Komeiji-Shiki/trpg-dice-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/Komeiji-Shiki/trpg-dice-mcp'

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