Skip to main content
Glama
expenselm

expenselm-mcp-server

Official
by expenselm

get_latest_subscription_expenses

Fetch recent subscription expense records with optional date filtering, semantic search, and pagination. Helps agents retrieve recurring costs for insights and management.

Instructions

Get the latest expense records related to regular subscriptions.

Args: skip (int): The number of records to skip. Default is 0. limit (int): The maximum number of records to return. Default is 10. from_date (Optional[date]): The start date for filtering. Default is None. Format is YYYY-MM-DD. to_date (Optional[date]): The end date for filtering. Default is None. Format is YYYY-MM-DD. text_input (Optional[str]): The text for semantic search. Default is None.

Returns: list[ExpenseRecord]: The latest subscription expense records.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
skipNo
limitNo
to_dateNo
from_dateNo
text_inputNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does explain that the tool returns a list of expense records and supports optional date filtering, pagination via skip/limit, and semantic text search. However, it does not clarify result ordering, how semantic search interacts with filters, or whether the operation is read-only beyond the verb 'Get' implying it.

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?

The description is concise and front-loaded with the core purpose, followed by compact Args and Returns sections. Each parameter line adds value, especially given the empty schema descriptions. It is slightly formulaic but contains no filler or redundant explanation.

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?

The description is largely complete for a straightforward filtered read tool: all parameters are explained, defaults are given, and the return type is stated. It lacks only richer context such as result ordering, the relationship to subscription-specific filters, or when to prefer sibling tools, but the essential calling information is present.

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

Parameters5/5

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

The schema provides no parameter descriptions, so the description is essential. It meaningfully documents all five parameters, including skip, limit, from_date, to_date, and text_input, with defaults and the date format YYYY-MM-DD. This fully compensates for the 0% schema description coverage.

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?

The description begins with a specific verb and resource: 'Get the latest expense records related to regular subscriptions.' This clearly differentiates it from the sibling get_latest_expenses, which appears to cover all expenses, by adding the subscription scope. The purpose is immediately understandable without relying solely on the tool name.

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 explicit guidance about when to choose this tool over alternatives such as get_latest_expenses or the summary tools. The subscription scope implies when it might be appropriate, but the description does not state exclusions, preconditions, or alternative selection criteria. An agent must infer usage from the name and summary.

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