Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

stage_coup

Attempt to take over a city-state's alliance by coup using a spy already surveilling it; returns coup chance, outcome, and whether you become its ally, or a refusal reason.

Instructions

Attempt a coup against a city-state's current ally with a spy that has established surveillance there (spies()'s can_stage_coup). Returns the chance the confirm printed, the outcome notification and succeeded (the city-state's ally is now us); a refusal says why_not.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and does disclose the refusal path (`why_not`) and the outcome fields. It omits cost, cooldown, failure/detection consequences, or reversibility, so the safety/mutation profile is only partially characterized.

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?

Two dense sentences, front-loaded with the action and precondition, followed by the return/refusal contract. Efficient, though the parenthetical backtick mentions add slight clutter.

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 one-parameter game action with no output schema, it explains the prerequisite and the shape of both success and refusal results. The only real gap is the unexplained agent_id parameter.

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 coverage is 0% and the single parameter agent_id is never explained in the description. The description references 'a spy' conceptually but does not tie agent_id to that spy or clarify its role, so it fails to compensate for the coverage gap.

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?

States a specific verb+resource (stage a coup against a city-state's current ally) plus the gating precondition of a spy with established surveillance. It is clear enough to distinguish from siblings like espionage_intrigue or city_state_action, though it doesn't name an alternative explicitly.

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?

It gives a real precondition (a spy with established surveillance, via spies()'s can_stage_coup), which functions as implied when-to-use guidance. However it names no alternatives or when-not-to-use cases, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools