get_mileage_summaryTotal business miles and IRS mileage deduction for a calendar year, with a per-type breakdown. Answers "what is my mileage deduction so far this year?"
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year, e.g. 2026. Defaults to the current year. |
| Name | Required | Description | Default |
|---|---|---|---|
| year | Yes | ||
| basis | No | ||
| byType | Yes | ||
| tripCount | Yes | ||
| totalMiles | Yes | ||
| personalTripCount | Yes | ||
| totalDeductionValue | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the nature of the returned data (business miles, IRS deduction, per-type breakdown). However, it does not disclose additional behavioral aspects like data freshness, or any edge cases, but given the read-only nature, this is acceptable.
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?
The description is concise, using two sentences to cover functionality and an example query. No superfluous information or repetition, making it highly efficient for an agent to parse.
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?
Given the simple nature of the tool and the presence of an output schema (as indicated), the description covers the essential aspects. It could optionally explain what 'per-type breakdown' means, but this is a minor gap and does not hinder understanding.
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?
The sole parameter 'year' is well-documented with a description ('Calendar year, e.g. 2026. Defaults to the current year.'). The schema provides clear type and a concrete example, leaving no ambiguity about its meaning or default behavior.
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?
The description clearly states the tool computes total business miles, IRS mileage deduction, and per-type breakdown for a calendar year. It also provides an example question ('what is my mileage deduction so far this year?'), making the purpose unambiguous and distinct from sibling summary tools.
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?
The description implies usage for mileage-related queries but does not explicitly state when to prefer this tool over alternatives (e.g., other summary tools). No exclusions or conditions are given, leaving room for ambiguity in selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a specific financial, client, project, or tax aspect with clear, distinct descriptions. Overlaps like get_cost_summary vs get_expense_summary are resolved by explicit scope differences (costs include mileage and bills; expenses are line-item). No two tools serve the same purpose.
All 25 tools follow a strict `verb_noun` pattern: `get_` for detailed summaries and `list_` for enumerations. No mixed conventions (camelCase, abbreviations) are present, making the pattern predictable for an agent.
At 25 tools, the set is on the larger side but fully justified by the breadth of the domain (financial summaries, clients, projects, taxes, contacts, time, mileage). Each tool covers a distinct slice; minor redundancies (e.g., cost vs expense summary) are acceptable due to nuanced differences.
The surface covers essential business operations: revenue, costs, expenses, cash, invoices, bills, projects, clients, contacts, taxes, time, mileage, and goals. Notably missing are any mutation tools (create/update), but the server appears intentionally read-only (analytics/reporting). For that purpose, the coverage is strong.