Odometry Mileage Log

Generate mileage log

generate_mileage_log

Read-onlyIdempotent

Use this when the user wants a mileage log, mileage log template, mileage log for taxes, printable mileage log, mileage log in Excel, or mileage reimbursement report from trips they drove ("turn these trips into a mileage log for my taxes", "reconstruct my mileage log from my calendar"). Takes typed trips (date, from, to, purpose, miles or odometer start/end), recurring trips (for example weekdays in a month) and/or an attached CSV/XLSX file. Applies the IRS standard mileage rate for each trip's date (2025: 70 cents; Jan-Jun 2026: 72.5 cents; Jul-Dec 2026: 76 cents per business mile; medical, moving and charity rates) or a custom employer rate, checks odometer continuity, flags commuting and missing purposes, and totals by month, purpose and client. Returns a PDF mileage log and an XLSX file. Does not look up distances between addresses, track GPS, or give tax advice. Do not use for a single quick mileage total with no trip list (use calculate_mileage_reimbursement).

Input Schema

Name	Required	Description
`file`	No	Optional trip spreadsheet the user attached (CSV, TSV or XLSX) with columns such as Date, From, To, Purpose, Miles, or Odometer start and Odometer end, e.g. trips.xlsx.
`trips`	No	Typed trips, one per drive, e.g. [{"date":"2026-10-05","from":"Office","to":"Client A","purpose":"Sales meeting","miles":12.4}].
`vehicle`	No	Optional vehicle description printed on the log, e.g. "2021 Toyota Camry". No VIN or plate needed.
`log_title`	No	Title printed on the log, e.g. "October 2026 mileage".
`recurring`	No	Repeating trips, e.g. "every weekday in October, 18 mi to the clinic" -> [{"start_date":"2026-10-01","end_date":"2026-10-31","to":"Clinic","purpose":"Patient visits","miles":18}].
`skip_dates`	No	Dates to leave out of recurring trips (holidays, PTO), YYYY-MM-DD, e.g. ["2026-10-12"].
`driver_name`	No	Optional driver name printed on the log, e.g. "Dana Lee".
`regular_workplace`	No	Name of the user's regular office or workplace, e.g. "Main St office", to flag home-to-office commuting.
`year_end_odometer`	No	Odometer at the end of the year (or of the log period), e.g. 52120.
`year_start_odometer`	No	Odometer at the start of the year (or of the log period), e.g. 38500. With year_end_odometer it gives total miles and business-use percentage.
`custom_rate_per_mile`	No	Employer or contract reimbursement rate in US dollars per mile for business trips, e.g. 0.60. Leave out to use the IRS standard mileage rate for each trip date.
`home_office_is_principal_place`	No	true if the user's home office is their principal place of business (then trips from home are not flagged as commuting).

Output Schema

Name	Required	Description	Default
`kind`	Yes
`flags`	Yes
`notes`	Yes
`title`	Yes
`period`	Yes
`source`	Yes
`totals`	Yes
`preview`	Yes
`by_month`	Yes
`by_client`	Yes
`downloads`	Yes
`by_purpose`	Yes
`rate_basis`	Yes
`rates_used`	Yes
`vehicle_use`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only cover read-only/idempotent/non-destructive, so the description goes well beyond them: it discloses the IRS rate schedule applied per trip date (70c 2025, 72.5c Jan-Jun 2026, 76c Jul-Dec 2026), odometer continuity checks, commuting and missing-purpose flagging, monthly/purpose/client totals, and the two output artifacts. It also states boundaries (no distance lookup, no GPS, no tax advice), which is exactly the context annotations cannot convey.

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?

Front-loaded with the 'Use this when' trigger list, then inputs, then processing behavior, then outputs, then exclusions — good ordering. The synonym-heavy trigger list is long but functional for routing; a few phrasings ('mileage log', 'mileage log template', 'printable mileage log') are borderline redundant.

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

Completeness5/5

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

For a 12-parameter tool with nested objects and an output schema, the description covers what inputs are accepted, what processing occurs, what is returned, and what is out of scope. Nothing an agent needs to decide or call correctly is missing, and return-value detail is appropriately left to the output schema.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3; the description earns above baseline by explaining how the parameter families combine (typed trips + recurring occurrences + attached CSV/XLSX) and by naming the custom employer rate as an alternative to the IRS rate. It does not restate per-field syntax, which the schema already handles thoroughly.

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 opens with a precise verb+resource and enumerates the concrete deliverables (PDF mileage log, XLSX file) produced from typed trips, recurring trips, or an attached spreadsheet. It explicitly names the sibling tool calculate_mileage_reimbursement as the wrong fit for a single quick total, so an agent can distinguish the two 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?

It gives explicit trigger utterances ("turn these trips into a mileage log for my taxes", "reconstruct my mileage log from my calendar") plus an explicit when-not ("Do not use for a single quick mileage total with no trip list (use calculate_mileage_reimbursement)"). It also enumerates out-of-scope capabilities (distance lookup, GPS tracking, tax advice).

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

All Odometry Mileage Log tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?