Skip to main content
Glama

Yomio

compare_periods

Read-only

Compare spending between two time periods.

Input Schema

NameRequiredDescriptionDefault
period1EndDateYesEnd of first period YYYY-MM-DD
period2EndDateYesEnd of second period YYYY-MM-DD
period1StartDateYesStart of first period YYYY-MM-DD
period2StartDateYesStart of second period YYYY-MM-DD

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.2/5.0
Behavior3/5

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

readOnlyHint=true already establishes this as a safe read, so the description is not the sole carrier of the safety profile. It adds no further behavioral context, however: nothing about whether periods may overlap, must be equal length, or whether the result is a delta, ratio, or raw side-by-side totals. With annotations covering safety, a 3 is the right level.

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?

A single sentence with no filler, and the core purpose is front-loaded. It is efficient, though borderline terse for a tool with four required date parameters.

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?

For a comparison tool with no output schema, the description states the metric (spending) but not the shape of the comparison (delta vs. percentage vs. per-category breakdown) or constraints relating period 1 to period 2. Adequate to call it, but not complete.

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

Parameters3/5

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

Schema description coverage is 100% — all four date parameters are documented with format and role in the schema. The description adds nothing beyond this (no ordering rules, no equal-length requirement), so the baseline 3 applies.

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?

The description names a specific verb (compare) and resource (spending) with a clear scope: two time periods. It distinguishes itself implicitly from list-style siblings like get_expenses or get_spending_summary, but never explicitly contrasts with them.

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?

There is no guidance on when to choose this over get_spending_trends or get_spending_summary, nor any stated prerequisites or exclusions. The agent must infer that this is the two-period delta tool from the name and description alone.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources