Skip to main content
Glama
archi-max

civ6-mcp

by archi-max
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_policies

Assign policy cards to government slots by specifying slot indices and policy IDs, keeping unlisted slots unchanged. Use NONE to clear a slot; wildcard slots accept any policy type.

Instructions

Set policy cards in government slots.

Args:
    assignments: Comma-separated slot assignments, e.g.
        "0=POLICY_AGOGE,1=POLICY_URBAN_PLANNING"
        Slots not listed keep their current policy. Use NONE to
        explicitly clear a slot (e.g. "2=NONE"). Use get_policies to
        see available policies and slot indices.

Wildcard slots can accept any policy type. Military slots accept
military policies, economic slots accept economic policies, etc.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
assignmentsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.11

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description discloses slot behavior: unlisted slots retain current policy, and NONE clears slots. It also explains slot type restrictions (wildcard, military, economic). Missing are potential side effects like cost or turn limitations, but overall transparency is good.

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, front-loading the purpose, then detailing the argument format with examples. Every sentence adds value, and the structure with bullet points aids readability.

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 output schema exists, the description need not explain returns. It covers argument format, slot interaction, and references get_policies for discovery. Minor omission: it might assume the user knows government slots are active, but this is implied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'assignments' has no schema description (0% coverage), but the description fully compensates with a clear format, examples, and slot-specific semantics, making the parameter meaning completely clear.

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 sets policy cards in government slots, with a specific verb and resource. It distinguishes itself from the read-only sibling tool get_policies and explains the assignment format, 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context by referencing get_policies for policy discovery and explaining how to keep or clear slots. However, it does not explicitly state when to use this tool versus alternatives, though no other sibling directly conflicts.

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