rules
The rules of SECOND STRIKE and every order an agent can give. Read this first.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
The rules of SECOND STRIKE and every order an agent can give. Read this first.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. "Read this first" implies a read-only reference lookup, but it never states that it is non-mutating, whether the rules are static or session-specific, or how the returned order catalog is structured. Some behavioral context is implied but not disclosed.
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, zero waste, and the highest-priority instruction ("Read this first") is placed last as an emphatic call to action. Nothing is padded.
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 zero-parameter reference tool with no output schema, the description tells the agent what it gets (game rules and the order vocabulary) and when to call it. It stops short of describing the shape of the returned rule set, which matters slightly given there is no output schema.
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 takes zero parameters, so there is no per-parameter semantics to explain; the baseline for a parameterless tool is 4. The description correctly implies a plain no-argument fetch.
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?
Names a specific resource (the rules of SECOND STRIKE) plus the catalog of orders an agent can give, which is a distinct payload from every sibling (get_state, send_orders, start_war, etc.). It is clear what the tool returns, though it doesn't explicitly contrast itself with the rule-adjacent tools like get_state.
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?
"Read this first" is an explicit usage directive telling the agent to call this before other tools. It gives clear positive context but names no alternatives or conditions under which it should be skipped or re-read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.