Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@civarium-mcp show me the current visible state"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Hermes-compatible local stdio MCP adapter for Civarium agent HTTP APIs.
The adapter is intentionally agent-owner only. It reads a Civarium base URL and
agent API key from environment variables, exposes player-facing MCP tools and
static Civarium context resources, and calls the public /api/v1/agent/...
gameplay contract plus the public read-only /api/v1/rules/... catalog. The
bearer token selects the agent identity for gameplay calls; clients do not pass
agent_id or session_id as tool input.
get_civarium_context - return the static Civarium overview as Markdown for
clients that expose tools but do not surface MCP resources.
list_civarium_docs - list static Civarium Markdown documents available
through tool calls and MCP resources.
read_civarium_doc - read one static Civarium Markdown document by doc_id.
get_civarium_rule_catalog - return a compact index of registered command,
entity, and event types plus the canonical MCP resource URIs for the catalog.
list_civarium_command_types - list command types currently registered by the
backend.
get_civarium_command_spec - read one command type specification, including
payload JSON Schema, validators, and statically discovered emitted event
types.
list_civarium_entity_types - list entity types currently registered by the
backend.
get_civarium_entity_spec - read one entity type specification, including
the JSON Schema for records in that entity library.
list_civarium_event_types - list event types currently registered by the
backend.
get_civarium_event_spec - read one event type specification, including
payload JSON Schema, validators, and projection modificator metadata.
get_active_round - return the current decision round for the authenticated
agent.
get_visible_state - return the agent's visible slice of the world.
submit_command - submit a command intent for backend validation and later
round execution.
list_queued_submitted_commands - list valid submitted command intents queued
for the agent in a round; this is not a list of available command types.
wait_next_round - poll until the active round changes, without advancing the
session.
The MCP server also provides stable server instructions and field descriptions that explain the current Civarium domain contract:
commands are intentions, not immediate world mutations;
world state changes through events and projection;
the runtime rules catalog is the source of truth for registered command, entity, and event types;
command payload schemas, entity schemas, validators, and projection metadata should be read from the catalog before acting on a mechanic.
Related MCP server: ai-mcp
civarium://docs/overview - canonical high-level Markdown overview explaining
what Civarium is, how agents relate to the game world, and how to interpret
rounds, visible state, and command intents.
civarium://docs/tools - Markdown specification of the MCP tools available to
an agent, including their game-world meaning, key inputs and outputs, and
suggested decision loop.
civarium://docs/world-model - formal explanation of sessions, rounds,
visible state, entity libraries, events, projection, and why submitted
commands do not immediately mutate the world.
civarium://docs/agent-knowledge - epistemic rules for agents, including
visible-state limits, hidden-state boundaries, and separating facts from
hypotheses.
civarium://docs/command-lifecycle - detailed lifecycle from command intent
to receipt, validation, valid queued command, round advancement, execution, and
later visible state.
civarium://docs/current-mechanics - how agents should discover current
mechanics through the runtime rules catalog and stay inside the exposed MCP
surface.
civarium://docs/glossary - stable definitions for Civarium terms used by the
docs, tools, and schemas.
civarium://rules/catalog - compact JSON index of registered command, entity,
and event types reported by the backend rules catalog.
civarium://rules/commands - JSON list of registered command types.
civarium://rules/commands/{command_type} - JSON specification for one
registered command type.
civarium://rules/entities - JSON list of registered entity types.
civarium://rules/entities/{entity_type} - JSON specification for one
registered entity type.
civarium://rules/events - JSON list of registered event types.
civarium://rules/events/{event_type} - JSON specification for one registered
event type.
Clients with resource support should read the civarium://docs/... URIs
directly. Clients that expose only tools can call list_civarium_docs and
read_civarium_doc to discover and read the same Markdown documents. The
get_civarium_context tool remains a shortcut for the overview document.
Likewise, clients with resource support should prefer the civarium://rules/...
catalog resources; clients that expose only tools can use
get_civarium_rule_catalog and the list_civarium_* / get_civarium_*_spec
tools.
The adapter does not expose session creation, agent-key management, health, readiness, metrics, or MCP prompts.
Required:
CIVARIUM_BASE_URL=https://api.civarium.example
CIVARIUM_AGENT_API_KEY=<agent key>Optional:
CIVARIUM_HTTP_TIMEOUT_SECONDS=30
CIVARIUM_WAIT_POLL_INTERVAL_SECONDS=2
CIVARIUM_WAIT_MAX_TIMEOUT_SECONDS=300Validate local configuration without starting MCP stdio:
civarium-mcp --check-configValidate configuration and credentials with one agent-only HTTP call:
civarium-mcp --check-config --pingBoth diagnostics write human-readable output to stderr. The stdio server mode writes MCP protocol messages to stdout only.
Preferred public configuration uses a pinned uvx package:
mcp_servers:
civarium:
command: "uvx"
args: ["civarium-mcp@0.1.6"]
env:
CIVARIUM_BASE_URL: "https://api.civarium.example"
CIVARIUM_AGENT_API_KEY: "<agent key>"
CIVARIUM_WAIT_POLL_INTERVAL_SECONDS: "2"
CIVARIUM_WAIT_MAX_TIMEOUT_SECONDS: "300"
timeout: 330
connect_timeout: 10
supports_parallel_tool_calls: false
tools:
include:
- get_active_round
- get_visible_state
- submit_command
- list_queued_submitted_commands
- wait_next_round
- get_civarium_context
- list_civarium_docs
- read_civarium_doc
- get_civarium_rule_catalog
- list_civarium_command_types
- get_civarium_command_spec
- list_civarium_entity_types
- get_civarium_entity_spec
- list_civarium_event_types
- get_civarium_event_spec
prompts: false
resources: trueFor local development from this checkout:
mcp_servers:
civarium:
command: "uv"
args: ["run", "civarium-mcp"]
env:
CIVARIUM_BASE_URL: "http://localhost:8000"
CIVARIUM_AGENT_API_KEY: "<agent key>"
timeout: 330
connect_timeout: 10
supports_parallel_tool_calls: false
tools:
include:
- get_active_round
- get_visible_state
- submit_command
- list_queued_submitted_commands
- wait_next_round
- get_civarium_context
- list_civarium_docs
- read_civarium_doc
- get_civarium_rule_catalog
- list_civarium_command_types
- get_civarium_command_spec
- list_civarium_entity_types
- get_civarium_entity_spec
- list_civarium_event_types
- get_civarium_event_spec
prompts: false
resources: trueProduction Hermes configs should pin a package version. Running unpinned uvx civarium-mcp can silently pick up a newer adapter at startup.
Releases are published to PyPI from GitHub Actions via PyPI Trusted Publishing.
The PyPI project must have a trusted publisher configured for the
release.yml workflow and the pypi GitHub environment.
To publish a new version:
uv run ruff check
uv run pytest
uv build --no-sources
git tag v0.1.6
git push origin v0.1.6The release workflow verifies that the Git tag matches the version in
pyproject.toml, builds the source distribution and wheel, and uploads them to
PyPI. After PyPI accepts the release, users can run the adapter with:
uvx civarium-mcp@0.1.6 --versionuv run pytest
uv run ruff check
uv build --no-sourcesUse the MCP inspector against a local checkout:
npx @modelcontextprotocol/inspector uv run civarium-mcpThe server supports both the installed command and module execution:
civarium-mcp --version
python -m civarium_mcp --versionThe package supports Python 3.12 and newer.
Return the active Civarium round for the authenticated agent. Use this to know which round is currently open for the agent's decisions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| round_id | Yes | Active round UUID. Use this value when submitting commands for the current decision window. |
| round_idx | Yes | Non-negative backend round index used to order rounds within the session. |
| session_id | Yes | Civarium session UUID that owns the active round and scopes the agent's visible game context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds that the round is specific to the authenticated agent and open for decisions, giving useful behavioral context beyond the annotations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core purpose and usage guidance with zero superfluous content. The description is front-loaded and instantly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, existing output schema, and thorough annotations), the description fully covers what the agent needs to know about the active round and why it matters. No gaps remain for this straightforward getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter burden. The schema coverage is complete at 100%, and the baseline for zero-parameter tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'active Civarium round' with the scope 'for the authenticated agent'. It is specific and unambiguous, but it does not explicitly differentiate from sibling tools like wait_next_round or get_visible_state, so it stops short of the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Use this to know which round is currently open for the agent's decisions' provides clear context on when to invoke the tool. It does not mention when not to use it or name alternatives, but the primary use case is well conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the backend rules catalog specification for one command type, including payload JSON Schema, validators, and statically discovered emitted event types.
| Name | Required | Description | Default |
|---|---|---|---|
| command_type | Yes | Registered Civarium command type to inspect. Use list_civarium_command_types or get_civarium_rule_catalog to discover available values. |
| Name | Required | Description |
|---|---|---|
| events | Yes | Event types statically discovered from the command handler. This is documentation of the current implementation, not a command execution result. |
| validators | Yes | Validators applied by the backend for this command type. |
| description | No | Docstring-derived command payload description, when available. |
| command_type | Yes | Registered Civarium command type. |
| payload_schema | Yes | JSON Schema for the command payload expected by the backend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive, so the description is not responsible for safety disclosure. The description adds contextual detail about the retrieved content ('statically discovered emitted event types') but does not disclose additional behavioral traits such as pagination or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and directly lists the important content categories. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup tool, the description covers the main purpose and returned content. An output schema exists, and annotations handle safety, so no critical information is missing for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter, and the description adds meaningful context by specifying that command_type must be 'registered' and pointing to sibling tools for discovery. This goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Read' and clearly identifies the resource: the backend rules catalog specification for one command type. It also enumerates the contents (payload JSON Schema, validators, emitted event types), which differentiates it from sibling tools like list_civarium_command_types (which lists types) and get_civarium_rule_catalog (which returns the catalog).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parameter description explicitly instructs to use list_civarium_command_types or get_civarium_rule_catalog to discover available values, offering clear guidance on when those alternatives are needed. However, the main description does not explicitly state when not to use this tool or contrast it with the catalog getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the static Civarium overview as Markdown. This read-only fallback exists for MCP clients that expose tools to agents but do not surface MCP resources or server instructions. Prefer the civarium://docs/overview resource when resource reading is available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| uri | Yes | Canonical MCP resource URI for this Civarium reference document. Clients with resource support should prefer reading this URI directly. |
| title | Yes | Human-readable title of the Civarium reference document. |
| content | Yes | Markdown content explaining the high-level Civarium game context, agent role, world model, and command semantics. |
| mime_type | Yes | MIME type of the returned reference document content. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context: it's a 'static' overview, a 'fallback' for clients without resource support, and returns Markdown. This goes beyond the structured annotations and provides a reason for the tool's existence and behavior, though it doesn't detail edge cases or error handling, which is acceptable for a read-only static tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the core purpose in the first sentence and usage context in the second. Every word earns its place; there is no fluff or repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description provides all necessary context: what it returns (overview as Markdown), why it exists (fallback for clients without resource access), and when to prefer the alternative. It is fully complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the description carries no burden of explaining parameter semantics. The baseline of 4 applies because there are no params to document, and the description adequately clarifies what the returned overview contains (static Civarium overview in Markdown), fully compensating for the lack of schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return the static Civarium overview as Markdown' — a clear, specific verb (Return) describing the tool's action and output (overview as Markdown). It also distinguishes itself from the resource alternative and from siblings by positioning itself as a fallback, making it unambiguous what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'This read-only fallback exists for MCP clients that expose tools to agents but do not surface MCP resources or server instructions.' It also gives a clear alternative: 'Prefer the `civarium://docs/overview` resource when resource reading is available.' This is textbook usage guidance with a when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the backend rules catalog specification for one entity type, including the JSON Schema for records in that entity library.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | Registered Civarium entity type to inspect. Use list_civarium_entity_types or get_civarium_rule_catalog to discover available values. |
| Name | Required | Description |
|---|---|---|
| description | No | Docstring-derived entity description, when available. |
| entity_type | Yes | Registered Civarium entity type. |
| entity_schema | Yes | JSON Schema for records in this entity library. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds that the response includes the JSON Schema for records, which is useful return-content context beyond the annotations. However, it does not disclose any additional behavioral traits such as error conditions, latency, or access requirements, so it stays at the baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is both concise and informative. It avoids redundancy and communicates the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, strong annotations, and an output schema, the description is largely complete. It explains what is returned (the spec and JSON Schema) and the scope (one entity type). It does not define the term 'backend rules catalog specification,' but that is not essential for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the only parameter (entity_type) with 100% coverage, including a hint to use other tools for discovery. The description adds 'one entity type' but does not enrich parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Read') and a specific resource ('backend rules catalog specification for one entity type'). It also notes the inclusion of JSON Schema, which distinguishes it from sibling tools like list_civarium_entity_types or get_civarium_rule_catalog that operate on the full catalog or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or conditions. Although the parameter schema suggests using list_civarium_entity_types to discover entity types, that is outside the description and not a usage guideline for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the backend rules catalog specification for one event type, including payload JSON Schema, validators, and projection modificator metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| event_type | Yes | Registered Civarium event type to inspect. Use list_civarium_event_types or get_civarium_rule_catalog to discover available values. |
| Name | Required | Description |
|---|---|---|
| event_type | Yes | Registered Civarium event type. |
| validators | Yes | Validators applied by the backend for this event type. |
| description | No | Docstring-derived event payload description, when available. |
| modificator | Yes | Projection callable that applies this event to world state. |
| payload_schema | Yes | JSON Schema for the event payload expected by the backend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds context about the return contents (payload schema, validators, projection metadata), which is useful but does not disclose additional behavioral traits like error conditions or rate limits. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with the verb 'Read' front-loaded, immediately conveying the action and resource. It is concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter input, strong annotations, and presence of an output schema, the description is complete. It covers the essential purpose, and return values are not needed in the description since the output schema exists. The parameter description adds discovery context, rounding out the tool's usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description goes beyond the basic type by explaining what the event_type is for and how to discover valid values. This adds meaningful guidance, exceeding the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the backend rules catalog specification for one event type, listing specific contents (payload JSON Schema, validators, projection modificator metadata). This specific verb+resource combination distinguishes it from siblings like get_civarium_command_spec and get_civarium_entity_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description (use when you need the spec for a specific event type), but the description does not explicitly state when not to use it or mention alternatives. However, the parameter description does advise using list_civarium_event_types or get_civarium_rule_catalog for discovery, providing some guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a compact JSON index of the current Civarium rules catalog from the backend: registered command, entity, and event types plus the canonical MCP resource URIs for reading the same catalog through resources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| resources | Yes | Canonical MCP resources and resource templates exposing the same rule catalog data. |
| event_types | Yes | Registered event types. |
| entity_types | Yes | Registered entity types. |
| command_types | Yes | Registered command types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-mutating operation. The description adds 'from the backend' and 'current' to indicate a live fetch, but does not disclose additional behavioral constraints like pagination or auth requirements. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main action ('Return a compact JSON index') and then specifies the contents. Every clause adds information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a rich set of annotations, and an output schema present, the description fully conveys what the tool does and what the response contains. It even notes the inclusion of resource URIs for further reading, which is a thoughtful contextual detail. Nothing important appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema trivially covers everything. The description adds no parameter-specific details because none are needed. Baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a compact JSON index of the full rules catalog, listing registered command, entity, and event types plus resource URIs. This distinguishes it from sibling tools like list_civarium_entity_types which return only one type category. The verb 'Return' and specific resource make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for obtaining a complete index of all rule types in one call, as opposed to the more granular sibling tools. It does not explicitly name alternatives or state when-not-to-use, but the 'compact JSON index' phrasing provides clear context that this is the all-encompassing option. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the visible Civarium state for the authenticated agent. This is the agent's observable slice of the world; hidden or unseen state is not included. Use list_civarium_entity_types and get_civarium_entity_spec to inspect currently registered entity libraries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| entities | No | Dictionary of visible entity libraries by entity type. Use list_civarium_entity_types or `civarium://rules/entities` to discover currently registered entity types; only entities visible to the authenticated agent are included. |
| round_id | Yes | Round UUID for which this visible state snapshot was produced. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context by clarifying that the result is the agent's observable slice and excludes hidden/unseen state, which goes beyond the annotation signals. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first front-loads the primary action and scope, the second adds a clarifying boundary and a pointer to related tools. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with strong annotations and an output schema, the description is complete enough for correct invocation. It explains what is returned (visible state), what is excluded (hidden state), and where to go for entity library details, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has 100% description coverage by virtue of being empty. Per the baseline for 0 params, the description correctly focuses on return-value semantics rather than inputs, so no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return'), names the resource ('visible Civarium state'), and clarifies scope ('for the authenticated agent', 'hidden or unseen state is not included'). It clearly distinguishes the tool from sibling entity-library tools by directing users to those for that purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the core use case and implicitly excludes inspecting entity libraries by pointing to list_civarium_entity_types and get_civarium_entity_spec. However, it does not explicitly compare against similar context tools like get_civarium_context or get_active_round, so usage guidance remains somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List command types currently registered by the Civarium backend. Use get_civarium_command_spec for the payload schema before submit_command.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| command_types | Yes | Registered command types accepted by submit_command when paired with a payload matching the corresponding command spec. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds behavioral nuance by noting the list reflects the current backend registry and importantly clarifies that payload schemas are not included (pointing to a separate tool). This goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: the first states the core purpose, the second gives targeted cross-tool guidance. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters), has robust annotations, and an output schema. The description effectively covers what it does and what to do next, making it fully sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100% vacuously. Baseline 4 applies because the description has no parameters to document, so it is not expected to add parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('command types'), with scope ('currently registered by the Civarium backend'). This clearly distinguishes it from sibling tools like list_civarium_entity_types and list_civarium_event_types by resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use get_civarium_command_spec for the payload schema before submit_command, providing clear context for when this tool is needed (discovering valid command types) and naming the next step. This acts as an alternative for a different concern, fulfilling the 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the static Civarium Markdown documents available to the authenticated agent. Use this when looking for Civarium documentation through tools; resource-aware clients may also read the returned MCP resource URIs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| docs | Yes | Static Civarium docs available through read_civarium_doc and, for resource-aware clients, the corresponding MCP resource URI. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that documents are 'static' and 'available to the authenticated agent,' plus mentions resource URIs, providing some context beyond annotations. However, it does not detail return structure or pagination, which would be richer behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('List...') and followed by when to use it. Every sentence adds value, with no filler or repetition of schema or annotation data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless listing tool with a read-only annotation and an output schema, the description fully covers purpose, usage, and a hint about resource URIs. It is complete and well-suited to the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description carries no parameter-documentation burden. Per the rubric, a baseline of 4 is appropriate for 0 params. The description clarifies what the list contains, which indirectly explains why no parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists static Civarium Markdown documents available to the authenticated agent, using a specific verb ('list') and resource ('Civarium Markdown documents'). This distinguishes it from sibling tools like read_civarium_doc, which reads a specific document, and get_civarium_context, which retrieves context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool when looking for Civarium documentation through tools, providing clear context. It does not explicitly name alternative tools or exclusions, but the phrase 'resource-aware clients may also read the returned MCP resource URIs' hints at related capabilities, making it clear when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List entity types currently registered by the Civarium backend. These are the entity library keys that visible state snapshots may contain.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| entity_types | Yes | Registered entity types that may appear in visible state snapshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behaviors. The description adds value by clarifying that the return values are 'entity library keys' and that they are 'currently registered', implying dynamic registry state. This complements the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, and the second adds essential context about the return values. Every phrase earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, parameterless list tool with an output schema available. The description adequately explains what the tool does and what the returned values represent (keys for state snapshots), making it complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. The baseline for zero parameters is 4, and the description appropriately focuses on the output semantics instead of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with a clear resource ('entity types currently registered by the Civarium backend'). It further differentiates from sibling tools like list_civarium_command_types by noting these are 'entity library keys that visible state snapshots may contain', which is a precise and distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when you need to know the registered entity types, particularly as they relate to interpreting visible state snapshots. It doesn't explicitly name alternatives or exclusions, but the relationship to state snapshots implies its role among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List event types currently registered by the Civarium backend. Events are backend facts projected into world state; agents cannot submit them directly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| event_types | Yes | Registered event types emitted and projected by the backend. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds meaningful context that events are backend facts projected into world state and cannot be submitted by agents, which is not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. Every clause adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description fully covers what the tool does and the nature of the data. It also clarifies a key constraint (agents cannot submit events) that helps contextualize the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Schema coverage is trivially 100% and there is nothing for the description to add about parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('List') and resource ('event types'), and clarifies they are registered by the backend. It also distinguishes from siblings by noting events are backend facts projected into world state, not directly submittable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to know available event types and explains agents cannot submit them directly, but it does not explicitly state when to use this tool versus alternatives like list_civarium_entity_types or get_civarium_event_spec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List submitted command intents that the backend has validated and queued for later execution for the authenticated agent in a Civarium round. Use this after submit_command to confirm which submitted intents are queued; this does not list available command types. Invalid submissions can still have receipts but are not listed here.
| Name | Required | Description | Default |
|---|---|---|---|
| round_id | Yes | Civarium round UUID returned by get_active_round; scopes one agent decision window or valid command history. |
| Name | Required | Description |
|---|---|---|
| commands | No | Valid submitted commands admitted for later execution for the authenticated agent in this round. These are queued intents, not available command types and not proof that world state has changed yet; invalid submissions may have receipts but are not included here. |
| round_id | Yes | Round UUID whose accepted submitted commands are listed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context by explaining that only validated and queued intents are listed, and that invalid submissions have receipts but are not shown. This goes beyond the structured annotations to clarify the tool's filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence stating purpose, a second sentence with usage context, and a final sentence clarifying what is excluded. No wasted words; front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple one-parameter tool, rich input schema, and helpful annotations, the description fully completes the picture: it explains when to use it (after submit_command), what it includes (validated/queued intents), and what it excludes (command types, invalid submissions). No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already provides a detailed explanation of `round_id`. The description doesn't add new semantics for the parameter, so the baseline 3 is appropriate. It does mention 'in a Civarium round' but this is redundant with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('submitted command intents that the backend has validated and queued'). It also distinguishes this tool from `list_civarium_command_types` by explicitly saying it does not list available command types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this after submit_command to confirm which submitted intents are queued' and provides a clear exclusion ('this does not list available command types'). It also notes that invalid submissions are not listed, which helps the agent understand the expected workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one static Civarium Markdown document by doc_id. This tool bridges MCP resources for clients that expose tools to agents but do not surface resource-reading operations.
| Name | Required | Description | Default |
|---|---|---|---|
| doc_id | Yes | Static Civarium document id to read. Use list_civarium_docs first when discovering available documentation. |
| Name | Required | Description |
|---|---|---|
| uri | Yes | Canonical MCP resource URI for this Civarium reference document. |
| title | Yes | Human-readable title of the Civarium reference document. |
| doc_id | Yes | Stable document id accepted by read_civarium_doc, such as `overview` or `tools`. |
| content | Yes | Markdown content of the requested Civarium reference document. |
| mime_type | Yes | MIME type of the reference document content. |
| description | Yes | Short explanation of what this document covers and when an agent should read it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context about the static nature of the content and the Markdown format, which goes beyond the annotations, though it doesn't detail return structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, and the second sentence justifies the tool's existence without fluff. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter, read-only tool with a rich schema and output schema, the description is complete. It covers what the tool does, why it exists, and the parameter description covers discovery workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter documentation, including an enum and a description that advises using list_civarium_docs first. The tool description adds no additional param semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Read) and the specific resource (one static Civarium Markdown document by doc_id). It distinguishes itself from siblings like list_civarium_docs by focusing on a single document retrieval, and from other get_* tools by targeting Markdown docs specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when this tool is needed via the MCP resource bridge context, and the parameter description directs users to 'Use list_civarium_docs first when discovering available documentation.' This provides clear alternative and sequencing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a command intent for the authenticated agent in a round. The command is recorded for backend validation and later round execution; it is not an immediate mutation of the world. Use get_civarium_command_spec to inspect the payload schema before submitting a command type.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Command-specific payload describing the agent's intended game action. Shape depends on command_type and is validated by the Civarium backend command registry; inspect get_civarium_command_spec before submitting an unfamiliar command type. | |
| round_id | Yes | Civarium round UUID returned by get_active_round; scopes one agent decision window or valid command history. | |
| command_type | Yes | Civarium command type to submit. Use list_civarium_command_types and get_civarium_command_spec to discover currently registered values and their expected payload shapes. | |
| client_command_id | Yes | Caller-generated UUID used as the idempotency key for one submitted command intent; choose a fresh value for each new intent and reuse it only when retrying the same intent. |
| Name | Required | Description |
|---|---|---|
| checks | No | Backend validation results keyed by rule or check name. Values explain accepted constraints or validation failures for the submitted command. Use get_civarium_command_spec for command validator metadata. |
| is_valid | Yes | Whether backend validation admitted the command for later round execution. False means the command was received and has a receipt, but it is not queued for execution. |
| round_id | Yes | Round UUID in which the backend received and evaluated the command. |
| command_id | Yes | Backend UUID assigned to the submitted command intent. |
| client_command_id | Yes | Caller-provided UUID echoed back so the agent can match the receipt to its original command intent. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that submission is not an immediate mutation, but a recorded intent for later rounds—key behavior not captured by annotations. It also notes backend validation, implying commands may be rejected. This is valuable given annotations only carry false hints; the description effectively explains the operation's async nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then adding the crucial non-mutation caveat and the pointer to the spec. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4-parameter schema, nested payload, and output schema, the description sufficiently covers the tool's role in the round lifecycle. It explains what happens on submission (recorded, validated, executed later), which is essential for an agent. The instruction to inspect command specs fills the only potential gap in understanding payload construction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with detailed descriptions for each parameter, including the idempotency purpose of client_command_id. The description adds strategic value by directing to get_civarium_command_spec for payload shapes and to list_civarium_command_types for valid types. This enhances understanding beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Submit a command intent for the authenticated agent in a round.' It uses a specific verb and resource, and differentiates from siblings by noting the command is recorded for later execution rather than immediate mutation. This distinguishes it from read-only or listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to consult get_civarium_command_spec before submitting a command type, indicating a prerequisite. The context of 'recorded for backend validation and later round execution' clarifies when to use the tool in the turn cycle. However, it doesn't explicitly list competing alternatives or exclusion criteria, though no direct substitutes exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for the active round to change from after_round_id or until a bounded timeout expires. This is only polling for session progress; it never advances the Civarium session.
| Name | Required | Description | Default |
|---|---|---|---|
| after_round_id | Yes | Active round UUID already observed by the agent; the tool waits until the active round changes from this value. | |
| timeout_seconds | No | Maximum seconds to wait for the active round to change; capped by adapter config and never used to advance the session. |
| Name | Required | Description |
|---|---|---|
| round | No | Current active round observed at the end of polling. Present on both changed and timeout results when the backend returned a round; on timeout it is usually still after_round_id. |
| status | Yes | `changed` when the active round differs from after_round_id; `timeout` when the bounded wait expired first. |
| timed_out | Yes | True when polling ended because the timeout expired before a round change. |
| after_round_id | Yes | Previously observed active round UUID that the polling wait compared against. |
| elapsed_seconds | Yes | Measured seconds spent polling before returning this result. |
| timeout_seconds | Yes | Effective maximum seconds used for this wait after adapter limits were applied. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, reducing the burden. The description adds the blocking/bounded-timeout behavior and reinforces the non-mutating nature ('never advances'), which is valuable context beyond the annotations. It does not mention return format, but the output schema likely covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and condition, and no unnecessary words. Every phrase earns its place, combining purpose, behavior, and limitation efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with two well-described parameters and an available output schema, the description fully explains the tool's behavior and constraints. It covers the wait condition, timeout bound, and non-mutating nature, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both after_round_id and timeout_seconds are already well-documented in the schema. The description adds only minimal reinforcement (e.g., 'from after_round_id', 'bounded timeout') but nothing substantially new, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wait') and resource ('active round') and clearly defines the condition (change from after_round_id or timeout). It distinguishes itself from siblings like get_active_round by explicitly noting it only polls and never advances the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('polling for session progress') and when not to use it ('never advances the Civarium session'). This gives clear guidance against using it as a mutation tool, effectively differentiating it from submit_command without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.6get_active_roundget_civarium_command_specget_civarium_contextget_civarium_entity_specget_civarium_event_specget_civarium_rule_catalogget_visible_statelist_civarium_command_typeslist_civarium_docslist_civarium_entity_typeslist_civarium_event_typeslist_queued_submitted_commandsread_civarium_docsubmit_commandwait_next_roundScored across 15 tools
Most tools have clearly distinct targets: each list/get tool addresses a different registry (entity types, command types, event types, docs, queued commands). The main ambiguity is get_civarium_rule_catalog, which duplicates the individual list_* commands as a combined index, and get_civarium_context/read_civarium_doc overlap slightly for documentation access.
The pattern is mostly verb_noun with a civarium prefix, but several tools (get_active_round, get_visible_state, submit_command, wait_next_round) omit the prefix, and read_civarium_doc uses 'read' while get_civarium_context uses 'get' for similar doc access. The long list_queued_submitted_commands also breaks the concise style.
At 15 tools, the count is at the upper bound of typical well-scoped servers. Each tool serves a distinct introspection or lifecycle need, but the granularity is fine-grained—many list/get pairs could be consolidated into a single catalog tool, though the separate endpoints provide flexibility.
The tool surface covers the core loop for a round-based simulation: inspect registered types and specs, read visible state, submit commands, verify queued intents, and wait for the next round. Minor gaps include no direct history of executed commands or agent identity information, but the visible state and round polling cover the essential workflow.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
MCP server for agentverse documentation, generated by doc2mcp.
