Retrieve paginated stored matchups for a specific report, filtered by faction, opponent, or release, to inspect dated Warhammer 40K matchup records. Results are not cross-report summaries.
按所选报告的日期、规则、地区和赛制查询已存对阵；不是跨期MFM汇总，每页20条。
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| report_id | Yes | ||
| faction_id | No | ||
| release_id | No | ||
| opponent_id | No |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds real value with the 20-records-per-page pagination fact and the aggregation exclusion, but says nothing about ordering, total counts, or what a page beyond the last returns.
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?
A single tight sentence with the resource and scope front-loaded and the pagination constraint appended; every clause carries information. Slight awkwardness in packing the exclusion and the page size into the same run-on line.
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?
Five parameters with zero schema descriptions, no output schema, and no annotation gaps to hide behind — the description should at minimum explain the id filters and pagination edge behavior. It covers the page size only, leaving an agent unable to use faction_id, opponent_id or release_id confidently.
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 carries the full burden and largely fails: page, faction_id, opponent_id and release_id are never mentioned or explained. Worse, '按所选报告的日期、规则、地区和赛制查询' suggests filtering comes from the report, which obscures the fact that the caller can narrow results with three separate id filters.
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?
States a specific verb and resource ('查询已存对阵') scoped to a selected report, and explicitly contrasts itself with a cross-period MFM aggregation. Siblings (list_reports, get_roster, get_data_notes) are unrelated resources, so no naming is needed, but the object '对阵' is never defined in domain terms.
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?
The clause '不是跨期MFM汇总' rules out one adjacent use case, and the mention of report-scoped date/rules/region/format implies the report_id prerequisite. There is no positive guidance on when to pick this over re-querying the report itself, and no alternative tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.