Report session metrics to EVC Mesh before ending a session to get compliance scores and usage stats.
Report session metrics. Call before session end. Returns compliance score and session stats.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | LLM model used (e.g. 'claude-sonnet-4'). | |
| tokens_in | No | Total input tokens this session. | |
| tokens_out | No | Total output tokens this session. | |
| estimated_cost | No | Estimated cost in USD. |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose the safety profile (not read-only, not destructive, not idempotent), so the bar is lower. The description adds that a compliance score and stats are returned, but it does not explain what a repeat call does despite the non-idempotent hint, nor whether the session must be open or what state this writes to.
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?
Three short sentences, front-loaded with the core action, then timing, then return value. No filler or restatement of the tool name.
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?
For a simple single-purpose reporting tool with full schema coverage and no output schema, the description covers purpose, invocation timing, and the shape of the return. Gaps remain around repeat-call/idempotency behavior and its relationship to sibling reporting tools, but nothing critical for correct invocation is missing.
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% and all four parameters (model, tokens_in, tokens_out, estimated_cost) are documented inline. The description contributes nothing about parameter meaning or expected formats, so the baseline 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?
States a specific verb and resource: 'Report session metrics', and adds the outputs ('compliance score and session stats'). It is clearly distinguishable in intent from task-CRUD siblings, but it never explicitly differentiates itself from adjacent reporting tools like publish_summary, report_error, or heartbeat.
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?
'Call before session end' gives explicit timing guidance, which is genuinely useful sequencing information for an agent. However, it names no alternatives and gives no exclusion criteria for when this should be skipped or replaced by publish_summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.