Skip to main content
Glama
cin
by cin

scoring_trends

Read-onlyIdempotent

Track average score vs par over time by month or season, using complete rounds and optional course or layout filters.

Instructions

Average score vs par over time, grouped by 'month' or 'season' (calendar year); complete rounds only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
courseNo
layoutNo
group_byNomonth

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond them by disclosing the 'complete rounds only' filter and the calendar-year interpretation of season, but says nothing about aggregation method, sample sizes, or output shape.

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?

Extremely compact single fragment with the metric front-loaded and the grouping options immediately after. Nothing is wasted, though the terse fragment style slightly hurts scannability for the filter clauses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, with zero schema description coverage and two unexplained parameters (course, layout), an agent cannot know how to scope the query, which leaves the definition short of complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load, but it only partially does: it explains group_by's allowed values and clarifies that 'season' means calendar-year grouping. The course and layout parameters are never mentioned, leaving two of three parameters undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific metric (average score vs par) and its time-series nature, which distinguishes it from static siblings like scoring_distribution and course_stats. It does not, however, explicitly name or contrast itself with the closest sibling, compare_seasons, which also aggregates over time.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no when-to-use or when-not-to-use guidance and names no alternative. The 'complete rounds only' clause is a scope constraint on the data, not guidance about when an agent should pick this tool over compare_seasons or scoring_distribution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.