Skip to main content
Glama

record_learning

Record match lessons and results into a cross-game learning library so future T1-T3 briefings auto-inject them; store standing rule insights separately.

Instructions

把本局教训写进跨局学习库(下局 T1-T3 简报自动注入)。

局末必调:lesson 写「这局最该被记住的一件事」(一句话,可操作);
result 写结果,如「失败(T384 美国文化胜利)」。事实字段(损失/探索率/
红警回合)由服务端从复盘日志自动提取,不用你报。
standing_insight 单独一层:跨局恒真的规则性教训(如「原版规则集下
法典完成前不能排政策卡」),不随局淘汰 —— 只在确认是规则而非局势时用。
局中也可以调(比如刚被教训过),重调同一局会覆盖而非重复。

Input Schema

NameRequiredDescriptionDefault
lessonNo
resultNo
standing_insightNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Only readOnlyHint=false is given, so the description carries the burden and does so well: it discloses overwrite-instead-of-duplicate semantics on repeat calls, that fact fields are auto-extracted server-side so the agent should not report them, and that standing_insight persists across games rather than being retired per game. These are exactly the behaviors an agent cannot infer from the annotation.

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?

Purpose and injection effect are front-loaded, then call timing, then per-field meaning. Dense but every sentence adds information; the only cost is slightly packed multi-clause lines that take a second read.

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?

For a mutation tool with minimal annotations and zero schema description coverage, the description covers when to call, what each field means, what the server fills in, and overwrite/persistence behavior; an output schema exists so return values need no explanation.

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?

Schema coverage is 0% — the schema is bare titles — and the description compensates for all three parameters: lesson is the single most memorable thing in one actionable sentence, result is the outcome with a concrete format example, and standing_insight is scoped to invariant rules-level lessons with a worked example.

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?

States a specific verb and resource — writing this game's lessons into a cross-game learning library — and adds the downstream effect (auto-injection into the next game's T1-T3 briefing). That effect alone distinguishes it from every read/side-effect sibling in the list.

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?

Explicitly says it is mandatory at end of game ('局末必调') and also permitted mid-game, and gives a clear decision rule for when to use standing_insight versus lesson ('只在确认是规则而非局势时用'). It does not name get_learnings as the read-side counterpart, so the sibling routing is left implicit.

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