Ask AI about Simpro, Xero, Deputy, Employment Hero, Dialpad, ELMO, Moveware and fleet data you own.
Scored across 20 tools
Most tools target clearly distinct actions: discovery (discover_questions, discover_operations) is separated from execution (ask_question, call_read_operation, call_write_operation), and preview_report vs run_report vs save_report vs run_sql vs summarize_records are each explained by when to use them. There is still residual overlap among the read paths (run_sql, summarize_records, search_records, preview_report all return data), but the descriptions give explicit selection guidance.
Names are uniformly snake_case with a verb_noun shape (get_record, list_connections, save_report, switch_company), so the pattern is predictable. The only deviation is the idiomatic 'whoami', which is a minor break rather than an inconsistency.
Twenty tools is on the heavy side, but the surface covers several genuinely different jobs (onboarding, tenant switching, source discovery, record reads, SQL, reporting, feedback), and the generic call_read_operation/call_write_operation pair absorbs the long tail instead of spawning dozens of per-endpoint tools. Only a couple of tools (whoami vs list_companies) feel marginally redundant.
Coverage is strong: onboarding, multi-company switching, connection/resource discovery, record read/search/aggregate, raw SQL, and full report lifecycle (list, preview, save, run), plus feedback. Minor gaps remain — no way to delete or archive a saved report, and connection management is read-only — but generic operation discovery provides an escape hatch for most missing actions.
Answer one of the questions the instructions name (discover_questions describes them) in one call, reading the source's copy server-side. arguments are the question's own; a missing or wrong one answers with the arguments it takes. Without connection_id every source that answers the question answers it, each under answers with its connection_id, connection, source and as_of: two sources measure different ledgers, so read them side by side and never add them. connection_id narrows to one source.
Inputs: name (required), arguments, connection_id.
Run one of the read-only operations discover_operations lists, with the arguments it named. A path argument goes at the top level ({"id": 7}). It changes nothing. You never name a company: the tenant comes from your token.
Inputs: operation (required), params.
Run one of the write or destructive operations discover_operations lists, with the arguments it named. It changes data in TradieBridge. A path argument goes at the top level ({"id": 7}); a write's fields go nested under the key discover_operations printed them against ({"connection": {"name": "Main"}}). You never name a company: the tenant comes from your token.
Inputs: operation (required), params.
What a source's backup holds. Without resource: every resource key with what it means, how many records it holds and what it hangs off, and the keys that hold none. Name one resource or several to add when each last synced and the columns search_records filters and orders by and summarize_records sums and groups by.
Inputs: resource, connection_id.
Search everything else TradieBridge can do, beyond the tools listed here — every screen and action in the app, named as "controller#action", with the arguments each one takes and the tool that runs it: call_read_operation for a read, call_write_operation for a write. Each refuses the other kind. Use it when no dedicated tool fits. Search by word: "export", "sync", "member".
Inputs: query.
The questions ask_question answers in one call, for the sources this company holds: each one's name, what it answers and the arguments it takes, as a JSON schema. A question two sources share is listed under each, answered from that source's own records. Filter by source, or by a word or topic (money, tax, jobs, customers, sales, schedule, staff).
Inputs: topic, source.
Records from a source's backup, whatever the system, exactly as the source sent them, with the records each one names (links) and the records hanging off it (related, first 50 of each). id is the source's own ID, or the id search_records returned; ids reads up to 20 at once. fields keeps only those keys of each document: top-level keys or dotted paths such as Contact.Name.
Inputs: resource (required), id, ids, fields, +2 more.
Where this business is in setting up TradieBridge: the systems connected, whether a backup holds records yet, and the one next step. Call it first when nothing is connected, when the person has just signed up, or when they ask how to start. next_step.say is what to tell the person, in your own words; when next_step.url is present, give them that link to open. Systems are connected, and API keys, passwords and card details entered, only on TradieBridge's own pages: never ask for one in chat or pass one to a tool. Call it again once they say they are done.
Inputs: no named parameters.
List the companies this connection reaches, with the person's role in each and which one it is acting in now. Every other tool answers about that one company; switch_company moves it.
Inputs: no named parameters.
List the company's sources, each a copy of one system: id (pass it as connection_id to the other tools), name, source, web address, the company or organisation backed up, sync health, when it last synced and how many records the backup holds.
Inputs: no named parameters.
The reports saved in TradieBridge for this company, pinned first: each one's id, title, description, address when the company has Reports pages, who made it and its blocks exactly as saved, to change one and save it again with save_report's report_id. A block reading a source or area you cannot read is left out and counted in hidden_blocks.
Inputs: no named parameters.
Run a report the user asked for, such as "invoiced per month this year against last year" or "most profitable jobs this financial year by manager", and answer each block's figures. It saves nothing: show the user what it found, adjust, then save_report. A report is blocks, each one figure, chart or table. A block reads sql (one SELECT, as run_sql runs it: the most flexible, any calculation, across sources), a resource (describe_resources; a sum or count by up to two columns, as summarize_records reads it) or a question (discover_questions; the curated reads, such as profit per job). Each block answers its layout: width, its share of the row, and note, when it has one. A block that cannot run says why in place of figures.
Inputs: report (required).
Run one saved report (list_reports names them) and answer every block's figures, worked out from the copy now: its columns, rows and, when it compares, the earlier period's figures beside them. Each block answers its layout: width, its share of the row, and note, when it has one. A screen that shows a report, such as a dashboard, calls this with the report's id rather than carrying its own query, so a fix to the saved report reaches every screen. period replaces the period of each block saved with one; a block saved for all time stays all time. A block reading a source or area you cannot read is left out and counted in hidden_blocks. A block whose source changed since its figures were worked out answers those figures at once, with their as_of and refreshing: true, while they are worked out again: call again shortly for the new ones. A block that cannot run says why in place of figures.
Inputs: report_id (required), period.
Run one PostgreSQL SELECT over this company's copy and answer its rows, to explore the data and to write a
report's sql block. Each source is a schema named by list_connections' sql_schema (simpro, xero, verizon_connect, the_fleet_office, deputy, moveware, dialpad, elmo, employment_hero, emailed_reports),
holding one view per resource named and shaped as describe_resources lists it, plus data, the whole
document as the source sent it (jsonb: data->>'Name', data#>>'{Customer,ID}'). Name the sources read with
connection_ids; the first one's schema is also the default, so jobs reads simpro.jobs. Joins, CTEs, window
functions and every read-only function work. period_start() and period_end() answer a report block's period.
Tax file numbers, bank details and birth dates are removed from every document. Nothing can be written, and
a query runs at most 15s. Dates a source sent as text compare as text: date_issued >= '2026-07-01'.
At most 200 rows answer at once, and truncated true means more remain: read on with ORDER BY and
OFFSET in the SQL, and count or total with COUNT(*), SUM and GROUP BY rather than reading every row.
Inputs: sql (required), limit, connection_ids.
Save a report to TradieBridge, where it is worked out again from the copy each time, so it stays current, and run_report runs it. Takes the same report as preview_report; preview it and show the user first. report_id replaces that report's title, description and blocks (list_reports names them). Every block must run, or nothing is saved. Answers the report's address in TradieBridge when the company has Reports pages.
Inputs: report (required), report_id.
Find records of one resource in a source's backup, whatever the system, highest source ID first, or largest first by order_by (ascending: true for smallest or oldest; empty values last). query matches a source ID as a prefix or a name holding every word; filters and order_by take the columns describe_resources lists. Answers the total that match and, when more remain, next_before_id to pass back as before_id (with order_by, raise limit instead). Each result's id is what get_record takes. For totals and counts use summarize_records instead of paging.
Inputs: resource (required), limit, query, filters, +5 more.
Send TradieBridge's builders an idea or a problem in the user's own words; they read every one. Use it when the user wishes TradieBridge did something it does not (a source, a field, a question, a report), when a question cannot be answered from the copy, or when something looks wrong (a missing record, a figure that differs from the source, an error). Read the title and details back to the user and send only once they agree. details says what they were doing, what they expected and what happened, naming the source and record IDs involved. Never include a password, API key or token.
Inputs: kind (required), title (required), details (required).
Count, sum, average, min or max over one resource's records in one call, of any source, optionally per group. Takes the same query and filters as search_records. column is a number column from describe_resources (min and max also take a date), or data. for a top-level key of the record's document: a number there sums, a YYYY-MM-DD date buckets, anything else counts for nothing. measures asks several figures at once, e.g. ["count", "sum", "avg"] over column, or "sum:" for another column; the answer is then values, keyed as asked. group_by is a column, week:/month:/quarter:/year:<date column or data.>, or a list of two, e.g. ["", "month:"]. A week is named by its Monday. Groups come largest first, or in date order when a date is bucketed, at most 100.
Inputs: resource (required), limit, query, column, +6 more.
Point this connection at another of the companies list_companies gives. Every tool after it answers about that company until it is switched again. Takes the company by name or id.
Inputs: company (required).
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Read-only by architecture: ask AI about QuickBooks, Xero and NetSuite, across every entity.
Read-only by architecture: ask AI about your Xero data, across multiple entities at once.
Query your books, company data, business health, and ship invoices from your AI assistant.
Ask your customer portal and CRM anything, in plain English
Add one secure layer between your agents and this server.
