The finance MCP tool: vocabulary first, then the question
Twelve read-only calls. Six teach the agent your finance vocabulary; six let it ask questions of the books. Zero touch the books themselves.
Twelve read-only calls. Six teach the agent your finance vocabulary; six let it ask questions of the books. Zero touch the books themselves.
Most “MCP tool walkthrough” posts list the calls and what they return. The finance MCP tool deserves better than that, because the shape of the surface tells you something useful before you’ve read a single signature.
The tool ships with twelve calls. Every one is read-only.
There is no record_revenue. No update_cost. No book_invoice. The books of record live in the books-of-record systems — the finance platform, the time-tracking system, the CRM. The MCP surface is strictly there to answer questions about what’s already in them. Finance authorship doesn’t move into the agent’s hands. Finance insight does.
That’s the design statement. Here’s how it’s split.
The first cluster teaches the agent your install’s finance language:
get_job_role_list — engineers, designers, fractional CFOs, …
get_cost_center_list — engineering, gtm, support, …
get_sku_list — what your team sells
get_billable_time_code_list — the codes that go on the invoice
get_non_billable_time_code_list — the codes that don't
get_crm_list — the customer records you'd group by
These are deliberately zero-parameter calls. The agent invokes each one once at the start of a session and now knows the dimensions it can slice on. No hallucinated cost centers. No “I’ll assume your SKUs are products” guessing. The single biggest failure mode for finance prompts is the agent inventing dimension values your install doesn’t have — this is the step that closes that loop.
Once the agent knows the vocabulary, the second cluster is what it asks:
get_profitability — revenue, cost, billable + non-billable hours, by dimension
get_item_billable_summary — per-item revenue, cost, gross margin
get_user_hours_summary — per-user billable %
get_weekly_time_logs — total / billable / non-billable per week
get_time_code_hours_logged — hours per time code
get_work_estimate_logged — items where logged time > estimate (the budget-blower flag)
get_profitability is the headline call. It takes a date range and one filterBy dimension — container | board | cycle | sku | jobrole | costcenter. Same underlying data, six different slices, one call. The agent picks the dimension based on the question. “Which projects are losing money?” is filterBy: container. “Which job roles are most under-utilised?” is filterBy: jobrole. Same primitive, different lens.
get_work_estimate_logged is the budget-blower flag — items where logged hours have already exceeded the estimate. Most finance dashboards bury this in a report nobody opens; an agent can ask it every Monday, unprompted.
The other MCP tools answer what and how. Finance answers how much. Same headless-ops architecture, applied to the part of the business where the numbers can’t be wrong.
Twelve read-only calls. Six to learn the vocabulary, six to ask the questions. Zero touch the books. That’s the contract.
Full reference: ekso.dev/mcp-tools/finance. Next Friday’s post — “Project profitability as a prompt” — walks through what these calls look like when an agent actually uses them. The whole MCP surface index is at ekso.dev/mcp-tools/introduction.
One workspace for tasks, tickets, time, and money. Free for unlimited users. Cloud, on-premise, or your own infrastructure.