plunk_get_event_statsAggregate statistics for tracked events to summarise project event volume. Returns aggregate event figures, not a ranking of top events.
Purpose: Aggregate statistics across tracked events.
Not for: A ranking of the busiest events, which is plunk_get_top_events.
Returns: Aggregate event figures.
Use when: Summarising event volume for the project.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive behavior, so the safety profile is covered. The description adds only that it returns aggregate figures; it does not mention auth needs, rate limits, or what dimensions are aggregated. With annotations carrying safety, this is a minimal but acceptable addition.
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?
Four bolded lines, front-loaded and telegraphic, with no filler. Each line adds purpose, exclusion, return type or trigger.
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?
Simple zero-parameter read tool with rich annotations, so the description is nearly complete. The only gap is that without an output schema, 'aggregate event figures' remains vague about the exact metrics returned; minor for a stats endpoint.
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?
Zero parameters; per rubric baseline is 4. Schema coverage is 100% and there are no parameters for the description to clarify.
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 'Aggregate' and resource 'tracked events', and explicitly distinguishes itself from plunk_get_top_events. However, 'aggregate statistics'/'aggregate event figures' is generic and does not say which statistics, leaving some ambiguity versus the sibling plunk_get_event_usage.
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?
Explicit 'Use when' line gives context (summarising event volume for the project) and a 'Not for' exclusion routing to plunk_get_top_events. This is exactly when-to-use and when-not guidance; other siblings are not excluded, but the primary confusion is handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.