Skip to main content
Glama
735,886 tools. Updated 2026-11-02 14:13

"Xero" matching MCP tools:

  • Retrieve every publicly published VA Heroes PH Hero Path — the career and training tracks a Filipino virtual assistant can start with or specialise in — so an agent can help a visitor identify a suitable path. Use it when someone asks what programs, tracks, specialisations or career options VA Heroes PH offers, or to obtain a slug before calling get_hero_path. Requires no input; optional filters are 'type' ('training' for VA skill paths, 'sales' for the Loan Officer path), 'featured' (only the recommended starting path) and 'limit' (1-100). Returns { total, count, items[] } where each item has slug, name, label, tagline, description, intro, highlights, type, featured, externalUrl and canonical url. It does NOT return pricing, schedules, enrolment status, applicant records or any private data, and it cannot submit an application.
    ConnectorNo auth
  • Balance Sheet report from Xero for the current organisation, as at a date. Read-only. `columns` gives the as-at period label(s); `rows` are flattened from Xero's nested section layout (`section` names the enclosing group, e.g. "Assets" or "Liabilities"; `rowType` "SummaryRow" marks a subtotal/total, not a line item). `currency` comes from this organisation's own Xero settings, never assumed - state it whenever relaying a figure from this report. If `date` was supplied, Xero reports the balance sheet as at the END OF THAT MONTH, not the exact day given - say "as at [end of month]", not the literal date requested. This organisation's financial year is NOT necessarily the calendar year (added 11 September 2026 - see lib/xero/financial-year.ts). `financialYear` in the result names the organisation's real financial year end and its exact current/previous dates, or says the year end is unknown. Never answer "this financial year", "last financial year", or "year to date" from the calendar year or the organisation's country - use financialYear's current.toDate (or previous.toDate) as `date`, and state the period you actually used when relaying a figure.
    ConnectorAPI key
  • Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FEES: every opportunities[] row and partition_check.arbitrage carry edge_pp_gross (== gap_pp / overround_pp), fees_pp, edge_pp_net, net_positive, plus polymarket_fee_pp, fee_basis and fee_categories[]. BOTH cost components are modeled: Polymarket's own per-category TAKER FEE (fee = shares × rate × p × (1-p), rates crypto 0.07 / sports-economics-culture-weather-other 0.05 / finance-politics-mentions-tech 0.04, geopolitics and world events fee-free; verified against Polymarket's own docs as of 2026-09-13) and Polygon gas (~$0.02/leg). The taker fee dominates: ~$1.75 per 100 shares on a crypto market at 50c versus $0.02 of gas, so rows that looked profitable before fleet #1927 may now show net_positive:false — that is the correction, not a regression. Each leg is priced at ITS OWN market's rate and price (the fee curve peaks at 50c and falls toward both extremes). fee_basis says where the rate came from: 'payload' (read off the market, the normal case), 'category' (mapped from its fee category), 'fee_free', or 'fallback' (rate unknown — charged at the modal 0.05 rather than assumed free, so an unreadable market is never reported as costless). Where fill_check reprices against live depth, this does NOT double-count that spread cost. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.
    ConnectorNo auth
  • Retrieve the full published detail of one VA Heroes PH Hero Path, identified by its slug (for example 'general-va'), so an agent can explain that specific track to a visitor. Use it after get_hero_paths when the user asks about one track — what it covers, who it suits, or where to read more. Requires 'slug': the exact lowercase slug of an existing path; an unknown or misspelled slug returns a NOT_FOUND error that lists the valid slugs. Returns one record with slug, name, label, tagline, description, intro, highlights, type, featured, externalUrl and canonical url. It does NOT return pricing, schedules, enrolment or applicant data, and it cannot submit an application.
    ConnectorNo auth
  • Search the published VA Heroes PH FAQ entries (About VA Heroes page) so an agent can answer applicant questions with the organization's own wording. Use it for questions about who can apply, required experience, needed skills, equipment and internet, how to apply, what happens after submitting, interviews, working hours, earnings, and whether applying costs anything. Requires no input; optional 'query' is case-insensitive text matched against both question and answer (max 200 characters) and optional 'limit' caps results (1-100). Returns { total, count, items[] } with id, question and answer verbatim. It does NOT generate answers: when nothing matches, the list is empty — say so or use another tool rather than inventing an answer.
    ConnectorNo auth
  • List the Xero organisations this connector token is currently authorised to read AND that this call is permitted to know about (organisation names only - never an internal id). Account-wide: it does not take an `organisation` argument and answers the same regardless of which organisation you were just discussing - use it to find the exact name to pass as `organisation` on another tool, when this connection reaches more than one. `withinPlanLimit: false` on an entry means it is authorised on Xero but outside this account's current Xero-connector plan limit - a call naming that organisation will be refused; say so plainly rather than trying it anyway. A restricted connector token may not see every organisation on the account - that is by design, not an omission. `organisations` may come back empty - `status` says exactly why, never leave that unexplained: "not_connected" (no active Xero connection at all - Xero has not been connected in Settings, or the connection was disconnected), "no_organisations" (Xero is connected but currently authorises zero organisations on it - reconnecting in Settings is the fix), "none_authorised_for_you" (organisations exist on this connection, but this specific connector token is restricted to a set that does not include any of them - ask the account owner to check Settings > Xero > Team), or "connected" (the ordinary case, whether or not the list happens to be empty for another reason).
    ConnectorAPI key

Matching MCP Servers

  • A
    license
    Not graded
    quality
    B
    maintenance
    Enables natural-language interaction with Xero accounting data, including invoices and intents, with role-based access control and audit trail.
    149 npm
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    A local MCP server for Xero that lets you search contacts, list and fetch invoices, and create draft invoices. It includes guardrails to prevent approving, sending, or deleting invoices.
    149 npm
    MIT

Matching MCP Connectors

  • Xero (Accounting) MCP Pack

  • Every Xero organisation you run, in one AI session. Writes wait for a person to approve them.

  • Lists the changes YOU (or another assistant on this account) have proposed against Xero - across every organisation this token may reach, not just the current one. Read-only; nothing is created or changed. Three groups: "pending" rows are still awaiting approval or rejection; "needsAttention" rows are not (a write that failed, or one stuck mid-execution) but are worth mentioning because something the person authorised did not visibly happen; "history" is the most recent already-resolved rows (approved-but-not-yet-sent, sent, rejected, expired, or cancelled) - use it to answer "what happened to the thing I approved last week" rather than telling the user to go check Xero. A row whose approval window has simply run out is reported here too, as status "expired" - Invio moves it into history on its own within about an hour, and this tool already reports it that way immediately, before that background sweep gets to it; it never counts as still "pending" and never counts toward maxOpenPendingChanges below. A failed or stranded row in needsAttention/history carries errorMessage/errorCode explaining why, and a sent one carries result with the id/number Xero assigned. Every row carries approvalUrl - the same link a draft-creating tool's own result carries - point the user at it rather than inventing a path. Use this when asked "what am I waiting to approve" or "what happened to X", after drafting several changes in one conversation to summarise what is now queued, or before drafting another change against the same invoice/contact to check whether an earlier one is still unresolved. If truncated is true, more pending/needsAttention changes matched than were returned - say so rather than presenting the two lists as everything waiting, and suggest approving or rejecting some before asking again. maxOpenPendingChanges is the most "pending" changes this account may have open at once before drafting a new one is refused - if pending.length is getting close to it, mention that to the user before it becomes a failed draft.
    ConnectorAPI key
  • Build a profit and loss (compte de résultat) and a balance sheet (bilan) from the trial balance of the workspace's connected Pennylane. Pennylane shares no ready profit and loss or balance sheet, only its trial balance (`getTrialBalance`). Well reads every page of it and computes the totals itself, account class by account class of the French chart of accounts (PCG). Every amount is a decimal string in euros, such as `"5000.00"`. State each amount exactly as returned and name the source: "computed by Well from the Pennylane trial balance". Never add, round or recompute an amount, and never call `getTrialBalance` yourself to rebuild one. Use it when the user asks for a profit and loss, an income statement, a compte de résultat, a balance sheet or a bilan, and the workspace's accounting tool is Pennylane. Do not use it for QuickBooks or Xero, whose own reports `well_invoke_connector_tool` reads. **Inputs.** `workspace_connector_id` is the Pennylane accounting row's id from `well_get_connector_coverage`. `statements` is `income_statement`, `balance_sheet` or `both`. `to` is the last day, YYYY-MM-DD, never after today: the profit and loss ends on it and the balance sheet is dated on it. `from` is the first day of the profit and loss, required for `income_statement` and `both`. The period must sit inside one Pennylane fiscal year. **Output.** `income_statement` gives `revenue` (class 7) and `expenses` (class 6), each with its `total` and its two-digit PCG `groups`, and `net_result` (revenue minus expenses, negative is a loss). `balance_sheet` gives `assets` and `equity_and_liabilities`, each with its `total` and `sections`, and `result_for_the_year` (from the fiscal year start to `to`, inside equity). The two totals are equal. `source` names the connection, the tool, the chart and each trial balance read with its dates and row count. `opening_balances` says how the balance sheet was shown to include the opening balances: carried from the closed previous year, or an opening entry on the first day of the fiscal year. `fiscal_year.status` is the year's status in Pennylane: `open` or `reopen` means entries can still be booked in it, so the figures can still change; say so once. **Refusals carry no statement.** `opening_balances_unverified`: Well cannot show that the balance sheet includes the opening balances (à-nouveaux) of the fiscal year, usually because the previous year is not closed in Pennylane yet or its opening entry is not imported yet; the profit and loss alone still works. `trial_balance_semantics_unproven`: Well cannot show that Pennylane's trial balance holds only the movements of the dates asked for. Before every profit and loss and every balance sheet, Well splits the trial balance at one day (the day before `from` for a profit and loss that starts after the fiscal year start, otherwise the day before `to`) and checks that the two parts add up to the whole on every class 6 and 7 account. The check failed, or a statement dated on the first day of the fiscal year left no day to split at. Well then builds neither statement, and the refusal carries `trial_balance`: Pennylane's trial balance for the dates asked for, with its full `row_count` and at most its first twenty rows, each exactly as Pennylane returned it. `closing_entries_suspected`: either every profit and loss account nets to zero on `to` although the earlier days of the year moved some, or the result of the year (chapter 12) moves on `to` (checked on the last day of the span, and on the last day of the fiscal year for a later period), which means Pennylane probably booked the closing entries of the fiscal year on that day; Well builds no statement and the refusal carries `trial_balance` the same way. Show those rows as Pennylane's trial balance, never as a profit and loss or a balance sheet, and add nothing up; when `row_count` is above the rows returned, say the full trial balance is in Pennylane. `connection_not_found`: no Pennylane connection matches `workspace_connector_id` in this workspace. `unsupported_source`: the connection is not a Pennylane input connection served over MCP (`pennylane` or `pennylane-token`). `unsupported_currency`: the workspace's base currency is not EUR. `unsupported_framework`: the Pennylane company does not use a French chart of accounts. `framework_not_reviewed`: the company uses a French sector chart (agriculture, non-profit or notary) that Well's statements do not cover yet. `scope_missing`: the connection was not granted the trial balance; it needs a reconnect. `tool_not_read_only`: Well's record of the connection does not mark a Pennylane read as read-only, so Well calls nothing. `connection_not_readable`: the connection is not enabled, or its grant expired during the read (`connection_status` says which state). When the connection is in the state `need_reconnect` or `error`, a `scope_missing` or `connection_not_readable` refusal carries `reconnect_url`, the link that reconnects this Pennylane connection: give it to the user as a clickable link, exactly as returned, and never build a connector link yourself. Without `reconnect_url`, give no link. `read_incomplete`: the trial balance did not come back whole. `invalid_trial_balance`: the trial balance came back whole but does not balance or holds a row Well cannot read (`defect` says which). `fiscal_year_not_found` and `invalid_period`: the dates do not fit one Pennylane fiscal year. `failed`: the read failed and nothing is known. Say each refusal in one plain line and state no figure, except the `trial_balance` rows of `trial_balance_semantics_unproven` and `closing_entries_suspected`, shown as returned. When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.
    ConnectorNo auth
  • Find live software by keyword before building from scratch. Public, no sign-in needed. Returns descriptions, USD license prices, tech stacks and listing links. Example: {"search": "invoice", "limit": 5}. Empty search browses recent software. When hasMore is true without nextCursor, narrow the search. Matching is lexical. Errors set isError; retry a rate limit later. Use z2h_compare_marketplace_listings for a shortlist or z2h_show_marketplace for cards. A result does not guarantee suitability or purchase availability.
    ConnectorNo auth
  • Prices Kalshi daily high-temperature markets against the NWS forecast for the market's OWN settlement station, and measures whether that forecast actually beats the market. Two modes. LIVE (default): returns the full strike ladder for one city and settlement date with market_prob (mid), forecast_prob, and edge_pp per strike, plus the settlement clause verbatim. BACKTEST (`backtest_days: N`): scores an archived gridded forecast against the market on settled days and returns brier_market vs brier_forecast with a plain-English `verdict`, so the edge is MEASURED rather than asserted. READ THE WARNINGS — they are not boilerplate. (1) These markets DO NOT settle on the NWS. They settle on The Weather Company (weather.com) at a Kalshi station code such as CLINYC, which the response quotes verbatim; so part of every edge_pp is NWS-vs-Weather-Company disagreement about the same day at the same station, which is not mispricing and not tradeable. `settlement_vs_forecast_basis_f` from backtest mode is that part as a number. (2) The station is DERIVED from the settlement clause, never from the city name: Chicago settles at MIDWAY and New York at CENTRAL PARK, so a city-centre forecast would misprice a whole ladder. A station that cannot be resolved yields rows with no forecast and a reason, never a guessed coordinate. (3) forecast_prob assumes a normal distribution around the NWS high whose width is ASSUMED, not fitted (stated in `distribution_assumption`) — run backtest mode to see whether it is calibrated. (4) edge_pp is gross: no Kalshi fees, no bid-ask. MEASURED RESULT, AND IT IS NOT THE FLATTERING ONE: on the first backtest (KXHIGHNY, 13 settled days to 2026-09-11, 58 market observations) the MARKET beat the forecast — Brier 0.1008 for the market against 0.1594 for the archived gridded forecast, lower being better. So on that sample there is NO forecast edge to sell, and a large edge_pp is more likely to be the model disagreeing with a better-informed market than an opportunity. The measured settlement-vs-forecast basis was 1.7F mean absolute over 8 pinnable days, slightly warm-biased, which is a big share of a typical edge_pp on a 2-degree bracket. Re-run backtest_days before believing any edge; if a later sample reverses this, the numbers say so. NWS is US-only, so the ~30 international Kalshi weather series (London, Paris, Tokyo) return market prices with forecast_unavailable rather than a forecast. Precipitation series are listed but not yet priced. Cities: nyc, chicago, los angeles, miami, austin, houston, denver, philadelphia — or pass `series_ticker` for any other (e.g. "KXHIGHTBOS").
    ConnectorNo auth
  • Claygent-style per-row research: answer ONE question about ONE company and return a JSON object matching your output_schema, with every field wrapped in its own evidence — {value, evidence_url, quote, status}. status is NEVER self-reported by the model: "found" means this code independently verified the model's quote is a VERBATIM substring of text actually fetched; "inferred" means a value was given but the quote could not be verified; "not_established" means no source answered the field, and its value is always null — never guessed, never a blended score. Sources: "web" fetches the company's own site (entity.domain required — homepage, /about, /leadership) via fetch_url; "catalog" checks entity_profile (SEC EDGAR; resolved:false for a private company is expected, not a failure); "both" (default) tries both. max_cost (USD, default 0.02, max 0.50) scales how many pages are fetched and refuses up front if it is too small to pay for even one extraction call (floor $0.002) — never silently overspends. A row where every source comes back empty costs nothing: every field is mechanically not_established with NO model call made. For a boolean/derived field (e.g. "does this company sell to healthcare"), the quote only has to SUPPORT the value — a descriptive sentence about customers/products counts, the source need not state the answer verbatim. leadership_page_status ("fetched"|"not_found"|"not_attempted", plus leadership_note) says plainly whether a leadership/team page was actually read, so a named-person field (head_of_sales) coming back not_established is distinguishable from "this company just doesn't publish one" vs. "we never checked". model_output_empty:true means the model returned nothing usable (a transport/budget problem) — every field is not_established for THAT reason, never read as 20 individual "no" judgments. Use with a fixed question + schema across many rows for "Claygent over N companies with a hard cost cap" (composes with batch callers). For picking from a fixed label list instead of extracting open fields, use classify_row (cheaper, one model call).
    ConnectorNo auth
  • Tell the Pipeworx team something is broken, missing, or needs to exist. Use when a tool returns wrong/stale data (bug), when a tool you wish existed isn't in the catalog (feature/data_gap), or when something worked surprisingly well (praise). ONLY for tools served by this Pipeworx connection — if the tool came from a different MCP server in your client (another vendor's Gmail, Splunk, Slack, etc. connector), we cannot fix it and reporting it here only delays you; file it with that server instead. Not sure? Pipeworx tool names are the ones this connection lists. Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. Filing without an account returns a `claim_token`; pass it back later as pipeworx_feedback({claim_token:"pwfb_…"}) to read whether it was fixed and what changed. The team reads digests daily and signal directly affects roadmap. Rate-limited to 5 per identifier per day. Free; doesn't count against your tool-call quota.
    ConnectorNo auth
  • Run one tool on a connected provider's own MCP server, on behalf of this workspace's connection: an action the user asked to take there (create a record in Attio), or a read of content Well does not sync (a page in a docs tool, a note in a CRM, a file the user pasted a link to). It is NOT a way to read financial data: Well already syncs invoices, transactions, accounts and the accounting graph from every connected provider — read those with well_query_records instead of calling a provider's own list/read tools. The one exception is a report the accounting tool builds and Well does not sync, such as a QuickBooks or Xero profit and loss or balance sheet: read that report with this tool, and state its lines as returned. WORKFLOW: 1. well_list_connectors() → pick the connected provider (connection_status "enabled" or "processing": a connection whose sync was started still serves its tools) and read its workspace_connector_id directly off the row. A workspace_connector_id the user pasted is fine to use as-is: it is resolved inside this workspace, and an id that does not belong here fails server-side. 2. well_list_connector_tools({ workspace_connector_id }) → the live tool names + input schemas that connection actually exposes right now. 3. well_invoke_connector_tool({ workspace_connector_id, tool: "<one of the names from step 2>", args: { ... } }). Only works on connectors that expose an MCP server (e.g. Attio, Notion, Linear) and whose connection is enabled or processing (a sync was started on it). A read-only tool runs at once. A write tool that Well reviewed for that provider waits for the user's approval in Well: the first call runs nothing and returns status "pending_confirmation" with a confirmation_request_id. Tell the user to approve the request in Well, then call again with the same arguments and that confirmation_request_id. A confirmation_request_id runs one call only: never reuse it, and never pass one the user did not approve. Any other write tool is refused: tell the user that the action is not available and do not retry it. Returns the provider's tool result, or { success: false, error } if the tool failed / is not granted.
    Connector
    Destructive
    No auth
  • Scan a Xero "Manual Journals" CSV export for cleanup issues — unbalanced journals, duplicate journals (same date + same totals), and schema problems (invalid dates, malformed amounts, missing account code/name, missing group key). Input is the raw CSV content the user pastes after exporting from Xero via Accounting → Advanced → Manual Journals → Export. Xero-specific idioms handled: signed Amount column (positive = credit, negative = debit), explicit Debit/Credit fallback shape, Reference-or-Narration+Date grouping, account code preferred over name. Max 5,000 rows; max 5 MB. Returns structured flags with severity, a roll-up summary, parse diagnostics, and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes Xero manual-journal data, asks "check my Xero books", or "find issues in my Xero journal". The funnel CTA routes to /migrate/from-xero for users who want to fix at scale.
    ConnectorNo auth
  • Scan a Xero "Manual Journals" CSV export for cleanup issues — unbalanced journals, duplicate journals (same date + same totals), and schema problems (invalid dates, malformed amounts, missing account code/name, missing group key). Input is the raw CSV content the user pastes after exporting from Xero via Accounting → Advanced → Manual Journals → Export. Xero-specific idioms handled: signed Amount column (positive = credit, negative = debit), explicit Debit/Credit fallback shape, Reference-or-Narration+Date grouping, account code preferred over name. Max 5,000 rows; max 5 MB. Returns structured flags with severity, a roll-up summary, parse diagnostics, and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes Xero manual-journal data, asks "check my Xero books", or "find issues in my Xero journal". The funnel CTA routes to /migrate/from-xero for users who want to fix at scale.
    ConnectorNo auth
  • ACCOUNTING EXPORT: turn the verified receipts into an accountant-ready CSV that QuickBooks / Xero / Excel import (the export finance teams need to adopt). Every row carries its own txHash + Basescan link, so the accountant re-verifies each amount on Base themselves — the export is a POINTER to the chain, never a book to trust. Non-custodial (BIII moved no funds). Columns: date, receipt_no, reference, description, payer, gross_usdc, tip_usdc, charged_usdc, token, chain, tx_hash, basescan_url, status. Dedup by txHash; optional block-time window; brand slugs the filename. WINDOW HONESTY: a receipt with no on-chain block time cannot be proven to fall inside a dated window, so it is excluded from one — and summary.undatedExcluded reports HOW MANY were, with the same warning prepended to `disclosure`. If that count is non-zero the CSV is short by those rows: re-run with no window to see them all.
    ConnectorNo auth
  • Convert a bank statement PDF into structured data or a spreadsheet. When the user attaches a PDF in the conversation, it arrives automatically as pdf_file — never encode it yourself. Otherwise, pass pdf_url for a public HTTPS link. If your host has no way to reference the attached file at all (no pdf_file/pdf_url equivalent), call request_upload first and pass its upload_id here instead. The base64 pdf parameter is a last resort only, for a caller with no other way to reference the file. To convert several statements in one call, pass upload_ids (the array from a single request_upload call made with count set) instead of pdf/pdf_url/pdf_file/upload_id — mutually exclusive with those four. This batch form only ADMITS each file (queues it, or reports an already-completed duplicate) and returns immediately with a compact per-file status list plus a summary — it never waits for conversion, so call get_statement per document_id once ready rather than expecting inline results here. Returns accounts, transactions, and metadata. output_format "json" (default) returns the data inline, renderable in chat. The other formats (csv, xlsx, qbo, xero) return a time-limited download link instead: present it as a normal link. Every response includes a "summary" field: use it as the single source of truth for what happened. If the conversation is not in English, translate it faithfully into the conversation language; never add details it doesn't contain. Never echo raw status values (e.g. "completed") or field names. Consumes credits (1 per page). Page limit depends on your plan.
    ConnectorNo auth
  • Fetch the full converted data for a previously processed document. Use this after convert_statement returns a "processing" status, or to re-fetch results. output_format "json" (default) returns the data inline, renderable in chat. The other formats (csv, xlsx, qbo, xero) return a time-limited download link instead: present it as a normal link. data_mode selects which projection of the data you get: omit it for each output_format's existing default behavior. "normalized" is the cleaned, interpreted view; "original" includes each transaction's raw column values exactly as printed on the source PDF (originalData); "enhanced" is a reformatted view of the original columns (csv/xlsx only for now). Fetch data_mode: "original" when you plan to submit results to evaluate_benchmark — pass its originalData through verbatim; an absent originalData scores that benchmark's raw-fidelity dimension 0 for this document. Every response includes a "summary" field: use it as the single source of truth for what happened. If the conversation is not in English, translate it faithfully into the conversation language; never add details it doesn't contain. Never echo raw status values (e.g. "completed") or field names.
    ConnectorNo auth
  • Retrieve a single structured overview of how the VA Heroes PH program works: the training Hero Paths, the separate sales (Loan Officer) path, the published community impact statistics, and the page where candidates apply. Use it when a visitor asks broadly what VA Heroes PH offers, how the training works, or how to get started, instead of asking about one specific track. Requires no input. Returns { applicationUrl, trainingPrograms[], salesPrograms[], impactStats[] }, where each program carries slug, name, tagline, description, highlights, featured and url. It does NOT expose pricing, class schedules, enrolment status, batch dates or any applicant data — programs in this project are the Hero Paths and no separate course catalogue exists.
    ConnectorNo auth
  • Who owes this business money in Xero right now, and how much - aggregated per contact from unpaid and partially-paid sales invoices (Type ACCREC, Status AUTHORISED). Read-only. Chosen over Xero's own AgedReceivablesByContact report because that report requires naming ONE contact per call and cannot answer an organisation-wide question. Amounts are grouped by currency (a Xero organisation can invoice in more than one) - if `currencies` has more than one entry, report each currency total separately rather than adding them together. `truncated: true` means more unpaid invoices exist than this tool scanned; say so rather than presenting the totals as exhaustive. `unusableAmountCount` (when greater than 0) means that many AUTHORISED sales invoices had no reliable amount-due figure from Xero and were EXCLUDED from every total, count and contact below - say so too, and never treat them as paid off just because they are absent from the numbers. OVERDUE MEANS THE DUE DATE IS STRICTLY BEFORE `overdueAsOf`, the calendar day this call was measured against: an invoice due ON that day is NOT overdue and is not in `overdueTotal`, because the customer still has that whole day to pay. `timeZone` is the zone that day was computed in and `timeZoneSource` says where it came from: 'organisation' means it is the organisation's own timezone from Xero, and any other value means Xero did not give one and the day was computed in UTC instead, so an invoice due within a day of now may be classified against a date up to a day away from the organisation's own. Do not recompute overdue yourself from `oldestDueDate` and your own clock - your clock is not the organisation's.
    ConnectorAPI key
  • Proposes a change to an EXISTING Xero contact - it does NOT change anything in Xero itself, and never will on its own. This queues a pending change that a human must explicitly approve (your Xero MCP connector - the exact link is this response's own approvalUrl field) before Xero is touched at all; you have no way to approve it yourself. contactId must come from list_xero_contacts (never invented). Provide at least one of name, emailAddress, or phone - only the fields you provide change, everything else on the contact is left exactly as it is.
    ConnectorAPI key