Skip to main content
Glama
GeiserX

cashpilot-mcp

by GeiserX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Hybrid

Daily earnings

get_earnings_daily
Read-onlyIdempotent

Retrieves daily earnings in USD across all services for the last N days, ordered oldest first, to support trend analysis and charting.

Instructions

Total earnings per day across all services for the last N days, in USD, oldest first. Use it for trends and charts; get_earnings_summary has the headline totals.

Input Schema

NameRequiredDescriptionDefault
daysNoHow many days back, 1 to 365. Default 7.

Output Schema

NameRequiredDescriptionDefault
earningsYesOne record per day: date and amount

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / days / default
      Added value: +7
    • changedInput schema / properties / days / description
      Previous value: -"Number of days to retrieve (default 7, max 365)"New value: +"How many days back, 1 to 365. Default 7."
    • addedInput schema / properties / days / maximum
      Added value: +365
    • addedInput schema / properties / days / minimum
      Added value: +1
    • changedInput schema / properties / days / type
      Previous value: -"number"New value: +"integer"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "earnings": {
+      "description": "One record per day: date and amount",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "earnings"
+  ],
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/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 context annotations can't express: the result is ordered oldest-first, denominated in USD, and aggregated across all services rather than per-service. It does not discuss day-boundary/timezone semantics or windowing beyond the param, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler; the scope and unit are front-loaded and the disambiguation clause follows. Every clause carries information.

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

Completeness4/5

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

With an output schema present, return shape needn't be explained, and annotations cover the safety profile, leaving the description appropriately lean. The one thing an agent might still need for a per-day series is how day boundaries are defined (timezone/UTC), which is unstated.

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% and the single 'days' parameter documents its range and default fully, so the baseline applies. The description only restates 'last N days' without adding format, timezone, or boundary meaning beyond the schema.

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

Purpose5/5

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

States a specific verb+resource ('Total earnings per day'), the aggregation scope ('across all services'), the unit ('USD'), the window ('last N days'), and the ordering ('oldest first'). It also names the sibling it is not, so an agent can distinguish it from get_earnings_summary without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit use case ('trends and charts') and routes the agent to the named alternative ('get_earnings_summary has the headline totals') with the condition that selects it. Nothing about tool choice is left to inference.

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

Deploy Server

Other Tools