cozyvtt-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools map clearly to a distinct resource and action: characters, maps, tokens, chat, dice, initiative, and sessions. A few boundaries are slightly fuzzy, such as chat_read vs events_poll and token_add vs token_place_creature, but the descriptions explicitly differentiate history/live events and generic/creature-placed tokens.
Naming Consistency4/5
The set generally follows a consistent resource_action pattern (chat_read, map_list, token_add, character_update), which makes the tools predictable. Minor deviations like campaign_status, initiative_state, token_hp, and token_place_creature break the imperative style but are still readable.
Tool Count3/5
20 tools is on the heavy end for a single MCP server, making the surface feel broad to audit. However, each tool covers a distinct VTT responsibility, so the count is defensible for the domain.
Completeness3/5
Core session workflows are well covered: campaign status, chat, dice, maps, tokens, initiative, characters, creatures, and session control. Notable gaps exist, however: no token removal/deletion, no character deletion, and no map creation/upoad, which create dead-ends for some agent workflows.
Average 3.6/5 across 20 of 20 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on September 5, 2026
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. '地图列表' is a noun phrase that only restates the name; it does not state whether the operation is read-only, what behavior to expect, or whether it has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It adds no meaningful information beyond the title.
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?
Although the tool has no parameters and an output schema exists, the description fails to convey when to use it, what listing entails, or how it relates to map_switch. With no annotations, the agent is left to infer essential context from the name alone.
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 zero parameters and 100% coverage, so there are no parameter semantics for the description to clarify. The no-parameter baseline of 4 applies here.
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 '地图列表' simply restates the tool name/title in Chinese and does not express a clear verb+resource action such as 'retrieves all available maps.' It is a tautology that provides no differentiation from siblings like map_switch.
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 gives no guidance about when to use map_list versus alternatives such as map_switch, token_add, or campaign_status. There are no conditions, exclusions, or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有注释，描述必须完全承担行为披露责任。描述只说了DM only，未说明添加token的行为（如是否覆盖、图层默认值、可见性处理等），信息严重不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述非常简短，无冗余内容，结构上也无问题。但考虑到工具复杂度（10个参数），这种简洁更像信息不足而非精心组织，未能承担应有的信息传递作用。
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?
工具具有10个参数、5个必填项和众多兄弟工具，描述仅一句话，远远不足以让代理正确调用。没有说明参数如何组合、与兄弟工具的关系，也没有提供任何操作上下文。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入模式覆盖率为0%，所有参数均无描述。描述中也没有解释任何参数的含义或关联，代理无法从描述中理解map_id、x、y、image_url等参数的作用。描述完全没有补偿模式信息的缺失。
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?
描述'放 token 到地图（DM only）'明确了具体动作（放）和资源（token、地图），能初步传达工具功能。但与兄弟工具如token_move、token_place_creature相比，未说明区分点，容易造成混淆。
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?
描述仅提及'DM only'权限限制，没有提供任何关于何时使用此工具与替代工具（如token_move、token_place_creature）的指导。没有when/when-not说明，代理无法判断该工具适用场景。
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 present, so the description must carry the full behavioral burden. It does disclose the two-step workflow (read creature template, then place token), but it omits side effects, required preconditions, failure behavior, and return details. For a mutation-like tool, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The one-line description is terse and front-loaded, using an arrow to compactly show the process. However, it is under-specified rather than efficiently complete, so it earns only a mid score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four required parameters, no annotations, and 0% schema description coverage, this description leaves too much for the agent to infer. The output schema exists, but the description still lacks parameter semantics, usage context, and behavioral detail needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters directly. Parameter names like creature_id, map_id, x, and y are suggestive, and '以模板名/图' hints at creature_id's role, but the description does not compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('调怪上图' – summon creature onto map) and the resource (monster library template), and it explains that a token is placed using the template name/image. This is specific enough to distinguish the tool from generic token tools, though it does not name sibling 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 gives no explicit guidance about when to use this tool versus alternatives such as token_add or token_move. The only implied context is template-based creature placement, which is not enough to route an agent clearly.
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 only labels the tool as a roster and does not mention whether the call is read-only, whether it reflects the current campaign or session, whether results are filtered, or how characters are ordered. A 'list' implies a read operation, but that is not explicitly stated.
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 with no filler content. It is a single short phrase that communicates the essential resource. It could be improved by adding a verb or a brief behavioral note, but as written it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is near-minimally viable: an agent can infer that calling it with no arguments returns a roster. However, it does not clarify whether the roster applies to the current campaign, whether it includes all character types, or whether any implicit context is required, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty with additionalProperties false. Since there are no parameters to explain, the description does not need to provide parameter semantics. The baseline of 4 is appropriate for a no-parameter tool.
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 '角色列表（战役 roster）' communicates that this tool returns a campaign-level roster of characters, which is slightly more specific than the title alone. However, it lacks a verb and largely restates the name, and it does not explicitly distinguish itself from sibling tools like character_get or creature_search.
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 given about when to use this tool versus alternatives. The 'campaign roster' phrase implies a general listing use case, but there is no explicit instruction such as 'use character_get for a single character' or 'use creature_search for monsters.'
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 adds useful context that the character sheet structure varies by campaign system (5e/PF2e/SR6/CoC7e), which is not visible from the input schema alone. However, it does not discuss error behavior, authorization requirements, or whether the operation is read-only, though '读' strongly implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, then adds the important schema-variation caveat in parentheses. Every word earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with an output schema present, the description is largely complete. It conveys full-sheet retrieval and system-dependent schemas, which is enough for an agent to understand the tool's behavior. A minor gap is the lack of explicit guidance distinguishing it from character_list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for the lack of parameter documentation. The description does not explain character_id, its format, or how it relates to campaign-specific schemas. The parameter name is self-explanatory, but the description adds no direct semantic value beyond implying that a character must be identified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '读' (read) and the resource '角色卡全量' (full character sheet), making the tool's core purpose unambiguous. It does not explicitly distinguish itself from sibling tools like character_list, though '全量' implies it returns complete sheet data rather than a summary list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as character_list or character_validate. The description implies full-sheet retrieval but does not state exclusions, prerequisites, or selection criteria relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add one concrete behavioral fact: type only accepts DM / PLAYER with upstream validation and a test date. However, it does not disclose persistence, visibility, or error behavior on send.
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, front-loaded, and free of filler. It could carry more operational detail, but its brevity is appropriate for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple send tool with an output schema, the description covers core purpose and the key type constraint. Missing usage guidance and behavioral detail such as whether the message is persisted or visible to players keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully enumerates the allowed type values and notes validation, but it does not define content beyond the general 'DM narrative / NPC line' context. Partial compensation for incomplete schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as handling DM narration / NPC dialogue, and the title 'Chat Send' supplies the verb. It is unambiguous about the resource and intent, though it does not explicitly differentiate itself from chat_read.
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 given on when to use this tool versus alternatives like chat_read. The phrase 'DM 叙事 / NPC 台词' implies a role-based use case, but there is no contextual or exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the role restriction and the three actions, but does not explain what starting, pausing, or ending a session actually does, what side effects occur, or whether any action is irreversible.
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 short and front-loads the key information: the tool name, the role restriction, and the accepted actions. There is no redundant content, though more detail would be welcome given the lack of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and an output schema present, the description is minimally viable: it tells the agent the role and the valid actions. Still, the absence of behavioral detail and usage context leaves notable gaps for an agent deciding how and when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description or enum for the single 'action' parameter, and schema coverage is 0%. The description compensates by listing the valid action values (start / pause / end), which is essential, but it does not elaborate on the meaning or expected effect of each value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (session) and the supported operations (start, pause, end), which makes the tool's purpose understandable. It is not perfectly differentiated from siblings like initiative_manage, but the action list narrows the semantics enough.
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 includes a clear access restriction, 'DM only', which tells the agent who may use it. However, it does not explain when to choose this tool over alternatives such as initiative_manage or how session management fits in a typical flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It does well by stating the validation schema source, the response shape {isValid, errors?}, and that validation failure still returns HTTP 200, which is valuable non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. The core action and the critical response/HTTP behavior are front-loaded and every sentence adds value.
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?
With one parameter and an output schema present, the description is reasonably complete: it explains the validation source, response shape, and HTTP behavior. However, it leaves unclear what 'data' refers to and how character_id drives the validation, which could lead an agent to expect a payload parameter that does not exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly define character_id; it only indirectly associates it with the character card. The description mentions 'data' but the input schema has no data parameter, leaving the exact input contract unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action, re-validating data against the character card's own gameSystem Zod schema, and notes this is server-side, which distinguishes it from character_get, character_update, and character_create. The term 'data' is somewhat ambiguous because the input schema only exposes character_id, but the core purpose is still clear.
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?
There is no explicit guidance on when to use this tool instead of character_get, character_update, or other siblings. The phrase 'server-side validation' hints at a context, but no prerequisites, exclusions, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals a useful side effect: switching broadcasts a WebSocket map.changed event. However, it does not disclose whether the switch is persistent, whether permissions are required, or what happens if map_id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler; the core action is front-loaded and the parenthetical broadcast side effect is efficiently appended. For a 1-parameter tool this is appropriately sized.
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 is minimally viable: it states the action and the side-effect event, and an output schema exists so return values need not be spelled out. But it omits the source of map_id, error behavior, and any prerequisites, leaving the agent to assume details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain map_id, but it never mentions the parameter or its format/source. The parameter name and the verb '切当前图' make the general role of map_id inferable, but no real semantic detail is added beyond the bare string type.
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 uses a specific verb '切' (switch) and resource '当前图' (current map), clearly stating the tool changes the active map. It does not explicitly name a sibling alternative like map_list, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call it when you need to change the current map, passing a map_id. However, there is no explicit guidance about when to use this tool versus alternatives, no prerequisites, and no mention that map_list should be used to obtain a valid map_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond a basic statement by revealing that the operation is a REST PUT and that a WebSocket broadcast of 'map.changed' synchronizes all clients. This gives useful side-effect awareness, though it omits permission or validation details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core action and then adds the key technical/behavioral details. Every element earns its place with no redundant wording.
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 gives the essential operation and a key side effect, and the output schema reduces the need to describe return values. However, for a tool with four required parameters and no annotations, it leaves gaps around parameter semantics and preconditions, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters. It only loosely refers to 'position', which implies x and y are coordinates, but it does not define map_id or token_id, nor clarify whether x and y are absolute or relative values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('移动 token' = move token) and the resource being modified (token position). It distinguishes this from sibling tools like token_add and token_hp by specifying 'REST PUT position', making the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that token_add is for creating tokens or token_hp for health changes, nor does it specify any preconditions such as the token needing to exist on the map.
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 transparency burden. It usefully discloses the Open5e source and the campaign-system restriction, which is real behavioral nuance. However, it does not disclose behavior for empty source, default filtering, or whether results are paginated beyond the schema's limit/offset defaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with no filler. The primary purpose is front-loaded, and the important source/system gate is added in a separate, clearly scoped sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, return values do not need explanation. Still, the tool has 5 parameters with zero schema descriptions, and the description only clarifies source. The behavior of an empty source value and the meaning/format of cr are important gaps, so the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only explains the source parameter and its srd/custom values. The cr, limit, offset, and search parameters are left undocumented; cr in particular could mean challenge rating but that is never stated.
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 a specific verb (search/检索) and a specific resource (Open5e SRD + campaign custom monster library). It also names the two source scopes, srd and custom, and adds the system-gate nuance, which disambiguates this from sibling tools like token_place_creature or character_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditional usage context: source=srd is only valid in DND_5E campaigns, while custom is unrestricted. This tells an agent when each source mode is appropriate. It does not explicitly discuss alternatives among sibling tools, but the search-versus-placement distinction is clear from purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden, and it delivers a concrete behavioral detail: health is checked via GET /health and a 200 response means alive. This goes beyond what the tool name alone conveys. It stops short of explicitly stating whether the operation is side-effect free, but the status-oriented wording and GET-based health check strongly imply a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it front-loads the three output categories and then adds the useful health-check mechanism. Every phrase earns its place, with no redundant restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters and an output schema exists, the description is nearly complete for invoking the tool correctly. It tells the agent what data to expect and how health is assessed. It is slightly vague about what 'campaign status' encompasses, though the output schema can carry that detail.
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 zero parameters, so there are no parameter semantics for the description to clarify. The description correctly omits parameter information, and the parameterless baseline applies.
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 enumerates what the tool returns: instance health, campaign status, and current map. It is specific enough for an agent to understand the tool's purpose, though it lacks an explicit active verb and does not directly differentiate itself from siblings like map_list or initiative_state.
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 intended use is implied: call this tool to get a combined status snapshot including health, campaign state, and current map. However, it does not state when to prefer it over alternatives or when not to use it, leaving the routing decision mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: the return contract ({events, latest_seq}), the event categories, and cursor-based incremental semantics an agent cannot infer from the bare schema. It stops short of disclosing event ordering guarantees, retention limits, or whether the call blocks, but the core behavioral contract is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with zero waste: the first front-loads the operation and scope, the second delivers the return contract and the canonical usage pattern. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter poll tool with an output schema present, the description covers the essential contract: input cursor semantics, output payload shape, event content types, and the recommended incremental loop. It is sufficient to call correctly; the absent details (ordering guarantees, event expiration) are minor for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It gives real meaning to `since` — a seq cursor where events with seq > since are returned — which is significant added value. `limit` receives no explanation, though its name and default value (100) make its role largely inferable.
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?
States a specific verb (拉取/poll), a precise resource (实时事件/real-time events), and the exact filter mechanism (seq > since). It enumerates the event content (player speech, dice, movement, including dice history), which positions it distinctly from siblings like chat_read and dice_roll.
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?
Explains the incremental polling workflow explicitly: store latest_seq from the response and feed it back as the next since parameter. However, it never states when to prefer this unified event stream over sibling alternatives such as chat_read, which plausibly serves the same 'read player speech' need, and names no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden and does disclose important behavior: sign semantics and a table-wide broadcast of character.hp.updated. This is meaningful beyond the schema. It does not mention failure cases or persistence, but for a simple HP mutation it is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the action first and the crucial semantic details in a parenthetical. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with an output schema, the description covers the operation, sign convention, and side effect (table broadcast). It is complete enough for an agent to call it correctly, though it omits explicit error cases or whether HP can go below zero.
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 0%, so the description must explain parameters. It explicitly defines delta as health change with positive=healing and negative=damage, which is the critical semantic. character_id is left implicit but its meaning is clear from the property name and tool context.
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 states a specific verb ('改' = modify) and resource ('token HP'), and defines the delta direction (positive=healing, negative=damage). This clearly separates it from sibling tools like token_move, token_add, and character_update.
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 given on when to prefer this tool over alternatives, nor any exclusions or prerequisites. The intended use is only implied by the tool name and the verb '改'; the description never names sibling tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals secret-roll visibility, the 2.1s minimum interval, the 30/min WebSocket rate limit, and that queuing does not raise an error. It does not cover failure modes or permission requirements, but the most important side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver purpose, syntax, secrecy behavior, and rate limiting with no filler. Critical call-shaping information is front-loaded, and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers expression syntax, secret rolling, and rate limiting. Since an output schema exists, return-value documentation is not required; the only notable gap is behavior on invalid expressions, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the expression parameter through examples and clarifies that is_secret=true means only the DM can see the roll. It does not formalize the full expression grammar, but an agent can construct valid calls from the provided examples.
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 indicates the tool performs dice rolls by giving concrete expression formats such as 1d20+5, 2d6, and 4d6kh3. It does not use an explicit verb like 'roll', and it does not differentiate itself from siblings by name, but the examples and tool name make the purpose unmistakable.
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 actionable usage context: is_secret=true is for hidden rolls visible only to the DM, and there is a client-side minimum interval of 2.1s with WS rate limiting. It does not explicitly state when not to use the tool or name alternatives, but no sibling tool overlaps with dice rolling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses that the server validates data against the campaign system's Zod schema and returns 400 on failure, and explains that data shape is system-dependent with upstream file references. It also reveals the side effect of adding the card to the current campaign, though it does not detail duplicate handling or requirements for a campaign 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 definition is four short, purposeful sentences with the core action first. Parenthetical validation details and upstream references are dense but relevant, and there is no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists to describe the return value, the description covers the creation effect, gameSystem inheritance, validation behavior, system-specific data structure, and a verification step. The main omissions are explicit semantics for token_image_url and an explicit distinction from character_update, but for a create tool with one required parameter this is near-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 0%, so the description must compensate. It does so for the complex data parameter (dict of card fields, structure depends on gameSystem, references dnd5e.ts/callOfCthulhu7e.ts), but it says nothing about token_image_url, and name is only evident from the schema property key. The most complex parameter is well covered, but not all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair — '创建角色卡' (create character card) — and adds the key effect '直接加入当前战役' (directly joins the current campaign). It also distinguishes creation from validation by pointing to character_validate, and the verb separates it from sibling character_update. This is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the intended context: create a new character card in the current campaign, with gameSystem automatically inherited so the caller need not supply it. It provides post-action guidance ('建完可用 character_validate 复查'), naming character_validate as the verification alternative. It does not explicitly state 'use character_update for existing cards', but the creation context is clear enough.
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?
There are no annotations, so the description carries the burden. It discloses a non-obvious behavioral trait: DICE_ROLL messages are excluded from chat history and must be retrieved via events_poll. This is meaningful context beyond the tool name and schema, though it does not discuss pagination or ordering.
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?
A single efficient sentence states the core purpose and adds the key caveat in parentheses. Every part earns its place and the important routing note is clearly included.
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?
This is a simple read tool with an output schema and two self-explanatory optional parameters. The description covers the essential purpose and a key behavioral exception. However, a fully complete description would also briefly clarify pagination semantics for limit/offset given the complete lack of parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the limit or offset parameters. The agent must rely entirely on parameter names and default values, with no explicit semantics provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('翻' = browse/read) and a clear resource ('聊天记录' = chat history). It also explicitly distinguishes this tool from events_poll by noting that DICE_ROLL messages are not in chat history, so the agent can tell it apart from relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says DICE_ROLL entries are not part of the chat history and directs the agent to use events_poll for dice history. This gives an explicit when-not-to-use condition and names the correct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates a read operation ('查' = query) and discloses the conditional fallback when no broadcast exists. It doesn't state whether the output is raw or parsed, but this is minor for a simple query 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 concise Chinese sentence with the core action and the no-data fallback. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only query with an output schema, the description adequately covers the tool's purpose and edge-case behavior. Nothing necessary is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already captures all input semantics. The description adds no parameter details, but none are needed; the baseline of 4 applies.
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 checks the initiative state, specifically the most recent initiative.state broadcast, and defines the fallback when none exists. This distinguishes it from siblings like initiative_manage, which likely modify initiative state, by signaling a read-only query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage intent is implied: use it when you need the current initiative status. However, it does not explicitly mention when not to use it, nor does it compare against alternatives like initiative_manage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a partial update, that no rule calculation happens in the bridge, and that data is the dict of fields to PUT. This is useful, non-obvious behavioral information. It does not cover authorization, error behavior, or exact merge semantics, but the most important caveat is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, purposeful sentences. It front-loads the core action, then adds the critical behavioral constraint, then defines the main parameter. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool, the description covers the core behavior, the partial-update scope, and the caller's responsibility for computed values. An output schema exists, so return-value documentation is not the description's job. It is slightly light on permission or error details, but overall it is sufficiently complete for a bridge update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that data is the dict of fields to PUT, which is the key non-obvious parameter. character_id is self-explanatory from its name and the update-a-character-sheet context. The description adds enough semantic value beyond the bare schema for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: partial update of a character sheet. It further distinguishes itself by explicitly saying the bridge does not perform rule calculations for SAN/HP/Luck/MP/spell slots, making it clear this is a persistence operation, not a game-logic one. This separates it from sibling tools like character_create, character_get, and token_hp.
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 gives clear context: use this tool when you want to partially update a character card with values already computed by the caller. The '局部更新' wording and the no-rule-calculation note make the intended use fairly explicit. It does not explicitly name alternatives or list when-not-to-use scenarios, but the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It covers authorization (DM-only), action behaviors, server-side roll derivation, expression fallback, and reorder overriding value order. It does not explicitly describe the effects of start / next / end, but the remaining behavioral context is strong.
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 dense but well-organized: a one-line scope statement followed by a compact per-action breakdown. Every sentence carries functional information, and the structure makes action-specific requirements easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is quite complete: it covers action-specific parameters, system-dependent roll derivation, CoC7e edge cases, and state retrieval via siblings. The only notable gaps are the undocumented character_name parameter and the implicit semantics of start / next / end, which are minor given the output schema and clear overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It maps most parameters to actions, explains optional expression semantics, and clarifies how value and ordered_token_ids affect ordering. However, character_name is present in the schema but not mentioned in the description, leaving one parameter 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 identifies the tool as initiative management ('先攻管理') restricted to DM-only use, and enumerates the full set of supported actions. It also distinguishes itself from siblings by noting that state is retrieved through initiative_state / events_poll, so there is no confusion with nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit per-action usage contracts, including which parameters each action requires, and provides system-specific guidance such as not using roll for CoC7e and instead using add then start or set. It also directs the agent to sibling tools for state retrieval, effectively explaining when this tool is not the right choice.
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

cozyvtt-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![cozyvtt-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/yanjingzhaisun/cozyvtt-mcp/badges/card.svg)](https://glama.ai/mcp/servers/yanjingzhaisun/cozyvtt-mcp)

Score Badge

Copy to your README.md:

[![cozyvtt-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/yanjingzhaisun/cozyvtt-mcp/badges/score.svg)](https://glama.ai/mcp/servers/yanjingzhaisun/cozyvtt-mcp)

shields.io Endpoint

For READMEs with an existing badge row. Append &style=flat-square (or any other shields.io style) to match the rest, and &metric=tools, &metric=maintenance or &metric=claim to badge a different dimension.

[![cozyvtt-mcp MCP server — quality and maintenance score on Glama](https://img.shields.io/endpoint?url=https%3A%2F%2Fglama.ai%2Fmcp%2Fservers%2Fyanjingzhaisun%2Fcozyvtt-mcp%2Fbadges%2Fshields.json)](https://glama.ai/mcp/servers/yanjingzhaisun/cozyvtt-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/yanjingzhaisun/cozyvtt-mcp'

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