Retrieve strategy notes for a chosen civ or leader, covering unique units, combat strength gaps, era windows, and principles to plan your game or anticipate opponent play.
查本文明套件:特色单位/战力代差/窗口开关时代 + 策略库原理(若收录)。 civ_or_leader 留空 = 查自己的文明。也可查对手文明来理解他会怎么打。
主路径是【运行时从 gamedata 推导】,所以任意随机文明都有输出;
手写策略库(3 个文明)只作为覆盖层追加。| Name | Required | Description | Default |
|---|---|---|---|
| map_type | No | ||
| civ_or_leader | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint=true, it discloses important behavioral context: the primary path is derived at runtime from gamedata, so any random civ produces output, while the handwritten strategy library covers only 3 civs and is an overlay. This coverage caveat is exactly the kind of context annotations do not carry, and it is consistent with readOnlyHint.
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 front-loaded with the resource being queried, then parameter usage, then the data-source caveat, with no filler. It is dense but organized, and every sentence carries 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?
Given that an output schema exists, the description needn't explain return values, and it adequately covers purpose and data-source reliability. However, with zero schema coverage and a sibling set full of strategy/advisory tools, leaving map_type and sibling differentiation unaddressed is a meaningful completeness gap.
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 0%, so the description must compensate. It clarifies civ_or_leader (blank = own civ, or an opponent civ), but says nothing about map_type, leaving one of two parameters undocumented everywhere.
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 gives a specific verb and resource: retrieve this civilization's kit (unique units, combat-strength differential, timing windows) plus strategy-library principles. It is clear what the tool returns, but it never differentiates itself from advisory siblings such as get_expert_playbook or get_opening_assessment, which likely overlap.
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 explains parameter usage well: civ_or_leader blank means your own civ, and you may query an opponent to understand their likely play. It stops short of saying when to use this tool versus alternatives — no exclusions, no routing to get_expert_playbook or get_power_balance — so usage is implied rather than fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.