Calculate contribution scores from PR weight, decision traces, and audit change size, grouped by person or workflow, with org_id filtering for cross-tenant queries. Read-only.
贡献度报表——人/数字员工同标准聚合（PR 权重分 + 决策留痕 + 审计变更规模 → 综合贡献分），按人/按 workflow 两维度输出，org_id 跨租户过滤（G7 联动）。纯读零写入。
| Name | Required | Description | Default |
|---|---|---|---|
| org_id | No | 组织/租户标识（可选——缺省 default；经 resolveTenantDataDir 分区隔离） | |
| data_dir | No | 数据根目录（缺省走租户解析链） | |
| window_days | No | 统计窗口天数（缺省 30） |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states '纯读零写入' (pure read, zero writes), which is a clear behavioral disclosure, especially important because annotations are absent. It also reveals the aggregation logic and cross-tenant filtering behavior. It does not cover permissions or rate limits, but for a read-only tool this is sufficient.
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 a single, dense sentence that front-loads the core purpose and ends with the read-only guarantee. It packs multiple pieces of information without being verbose, though the G7 linkage reference may be cryptic to an external agent.
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 the tool is a read-only report query, the description covers the essential purpose, aggregation logic, and read-only nature. However, without an output schema, it does not describe the return format or structure of the report, and 'G7 linkage' is left unexplained. For a query tool this is adequate but not complete.
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 100%, so all three parameters (org_id, data_dir, window_days) are already documented in the input schema. The description adds no new parameter-specific detail beyond what the schema provides—for example, the schema already explains org_id's tenant isolation. The baseline of 3 applies.
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 clearly states the tool produces a contribution report (贡献度报表) with a specific aggregation formula (PR weight + decision trace + audit change scale → comprehensive contribution score) and two output dimensions (by person, by workflow). It names the resource and action precisely, though it does not explicitly differentiate from sibling tools like cost_query or stats.
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 description does not provide any guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It mentions org_id cross-tenant filtering and G7 linkage as conditions, but these are parameter context rather than usage guidance. There is no 'use this when...' or 'not for...' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.