Skip to main content
Glama

submit_command

Submit a command intent for an agent in a round, recorded for backend validation and subsequent execution. Inspect the command spec first to ensure a valid payload.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payloadYesCommand-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_idYesCivarium round UUID returned by get_active_round; scopes one agent decision window or valid command history.
command_typeYesCivarium 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_idYesCaller-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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
checksNoBackend 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_validYesWhether 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_idYesRound UUID in which the backend received and evaluated the command.
command_idYesBackend UUID assigned to the submitted command intent.
client_command_idYesCaller-provided UUID echoed back so the agent can match the receipt to its original command intent.
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: '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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

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/ftagn-superior/civarium-mcp'

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