"Xero" matching MCP tools:

• pipeworx_feedback

  Xero

  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). Describe the issue in terms of Pipeworx tools/packs — don't paste the end-user's prompt. 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.

  Connector

• entity_profile

  Xero

  "Tell me about X" / "research Acme" / "brief me on Tesla" / "what does Apple do" / "company profile for Microsoft" / "give me the rundown on NVDA" / "everything you know about $TICKER" — full cross-source profile of a US public company in ONE parallel call. ALWAYS PREFER over chaining single-pack SEC/XBRL/news lookups when the user asks for a holistic view. Fans out across SEC EDGAR, XBRL, USPTO, news, GLEIF and returns: cik + company_name; recent_filings (up to 5 with pipeworx://edgar/company/{cik}/filings/{accession} URIs); fundamentals (LATEST 10-K Revenues + NetIncomeLoss + Cash, sorted period_end DESC); patents (USPTO PatentsView API sunset May 2025 — soft-fails until reactivated); recent news mentions via GDELT→GNews fallback; LEI via GLEIF. Pass ticker "AAPL" or zero-padded CIK "0000320193" — names not supported (use resolve_entity first if you only have a name).

  Connector

• recent_changes

  Xero

  "What's new with X" / "latest on Y" / "what happened to Z this week / month / quarter" / "updates on Acme" / "news on Tesla recently" / "what's happening with Apple" — change feed for a company in the last N days/weeks/months in ONE parallel call. Fans out to SEC EDGAR (filings since `since`), GDELT→GNews fallback (news mentions in window — GDELT preferred, GNews when rate-limited or 5xx), USPTO (patents granted; PatentsView API sunset May 2025 so this soft-fails until reactivated). `since` accepts ISO date ("2026-04-01") or relative shorthand ("7d", "30d", "3m", "1y"). Returns structured changes[] grouped by source + total_changes count + pipeworx:// citation URIs. Use entity_profile instead when you want the static profile (filings + fundamentals + LEI + patents) regardless of window.

  Connector

• polymarket_kalshi_spread

  Xero

  Cross-venue spread between Kalshi and Polymarket for the same resolving question. The two venues sometimes price the same outcome 2-25pp apart because their participant pools differ — when the bet shapes are equivalent that delta is a real signal, when they aren't the tool says so. TWO MODES: (1) `topic` — 10 pre-mapped macro shortcuts ("fed", "btc", "cpi", "gdp", "sp500", "recession", "next_pope", "next_uk_pm", "next_israel_pm", "2028_president") auto-fetch the matching event on each venue. (2) explicit `kalshi_event_ticker` + `polymarket_event_slug` for custom pairings. RESPONSE: each venue's leg-by-leg prices (raw probability 0-1) plus matched spread[].top_spreads_pp (Kalshi − Polymarket) where the same outcome shows up on both sides. SAFETY FIELDS: compatibility_warning fires in two cases — (a) matched_pairs:0 with skipped_cross_type>0 means the venues frame the topic with non-equivalent bet shapes (e.g. Kalshi range_bucket point-in-time vs Polymarket cumulative_threshold touch-anywhere — no arb exists), (b) matched_pairs:0 with skipped_cross_type:0 and both venues >5 legs means the token-overlap matcher found nothing in common — events likely semantically unrelated despite the topic keyword. temporal_alignment{polymarket_month,kalshi_month,aligned} tells you whether the two events resolve in the same calendar period; aligned:false means spreads are mathematically meaningless across the temporal gap. skipped_cross_type / skipped_cross_subtype counters expose how many leg-pair comparisons were dropped (cross-type = metric_type mismatch like MoM vs YoY; cross-subtype = inequality mismatch like cum_ge vs cum_le). Real cross-venue spreads are rarer than the macro-shortcut list suggests — most pre-mapped topics return compatibility_warning today; pre-mapped ≠ tradeable.

  Connector

• list_organisations

  Xero

  List the Xero organisations (tenants) the connected account can access, with tenant id, name, and type. Xero accounting is multi-tenant — use this first to discover the tenant_id for a specific organisation, then pass it to the other accounting tools to target that org.

  Connector

• dero_get_encrypted_balance

  DERO MCP Server

  Get the ENCRYPTED balance blob for a DERO address at a topo height via DERO.GetEncryptedBalance. CRITICAL: this returns an opaque encrypted blob, NOT a cleartext balance. Only the wallet holding the spend key can decrypt it. Do NOT present the encrypted bytes as a balance to the user. When to call: when verifying that an address has on-chain encrypted state (e.g. before attempting a transfer with a wallet you control), or as a sub-step in another tool. PREFER citing dero_docs_search("encrypted balance") so the user understands the opacity. Input Requirements (CRITICAL): - `address` MUST start with `dero1` (mainnet) or `deto1` (testnet). - `topoheight` MUST be an integer; use `-1` for the latest chain tip. - `scid` is OPTIONAL. Omit for native DERO; provide 64-hex SCID for asset balances. Output: `{ status, registration, balance (encrypted blob), ... }`.

  Connector

• dero_get_gas_estimate

  DERO MCP Server

  Estimate gas (compute + storage) for transfers, SC deploys, or SC invokes via DERO.GetGasEstimate. This is a PRE-FLIGHT check; nothing is submitted. When to call: BEFORE any wallet-side transfer/scinvoke (using external wallet tooling) to size fees, OR when explaining deploy costs to a user. PREFER citing dero_docs_search("gas estimate" or "fees") so the user understands how compute vs storage gas are charged. Input Requirements (CRITICAL): - At least ONE of `transfers`, `sc`, or `sc_rpc` MUST be provided. - `sc` is the DVM-BASIC contract source string when estimating a deploy. - `sc_rpc` is an array of `{ name, datatype, value }` invocation arguments (entrypoint + SC_ID + caller-provided params). - `signer` is OPTIONAL but PREFERRED; pass the `dero1.../deto1...` address that would sign the eventual tx. Output: `{ gascompute, gasstorage, status }`.

  Connector

• diagnose_chain_health

  DERO MCP Server

  Composite: run a four-step chain (DERO.Ping → DERO.GetInfo → DERO.GetHeight → DERO.GetTxPool) and return a single narrative health report with chain metadata, mempool snapshot, machine-readable signals, and curated docs citations. When to call: as the first step in any chain-state investigation when the user asks "is the node healthy", "is it synced", or "what is the current state of the chain". PREFER this over chaining the four primitives yourself — the composite handles partial-failure modes and lag-depth classification consistently, and the response already cites the right docs page. Input Requirements: - `include_tx_pool` is OPTIONAL (default true). Set false to skip the mempool snapshot when you only need chain-tip status. Output: `{ status, narrative, signals[], chain, mempool, related_docs, _diagnostics }`. `status` is one of `healthy | lagging | partial | unreachable`. `chain` is null when DERO.GetInfo was unreachable; `mempool` is null when skipped or the call failed. On total daemon unreachability the tool returns a structured `_meta.error` with code `RPC_UNREACHABLE`.

  Connector

• audit_chain_artifact_claim

  DERO MCP Server

  Composite: audit a chain artifact (block topoheight, block hash, TX hash, and/or proof string) end-to-end. Returns a verdict (`cited_in_false_claim` | `clean`), the actual on-chain facts (block reward, TX acceptance status), an optional proof-string decode, a relayable narrative, and curated rebuttal docs citations. When to call: when the user asks "what's going on with DERO block X?" / "is this transaction the inflation-claim TX?" / "does this proof string come from a known false claim?" PREFER this over chaining `dero_get_block_header_by_topo_height` + `dero_get_transaction` + `dero_decode_proof_string` yourself: the composite already runs them in parallel, joins them against the flagged false-claim registry, and emits a single `verdict` field plus a narrative so the agent does not need to compose the rebuttal arc from scratch each time. Input Requirements (CRITICAL): - At least ONE of `topoheight`, `block_hash`, `tx_hash`, or `proof_string` MUST be provided. The composite throws `INVALID_INPUT` otherwise. - `topoheight` is OPTIONAL. Non-negative integer. - `block_hash` is OPTIONAL. 64 hex characters. - `tx_hash` is OPTIONAL. 64 hex characters. - `proof_string` is OPTIONAL. Full `deroproof…` / DERO bech32 string with HRP. - `include_forge_demo` is OPTIONAL (default false). When true AND `tx_hash` is provided, also forges a fresh demo proof for the same TX (via `dero_forge_demo_proof`) and embeds it under `forge_demo`. The demo amount auto-selects: a flagged artifact's pinned amount (e.g. -2.2M for the 2022 claim) > the cited `proof_string` V > -1 DERO. PREFER setting this true when the agent is fielding a "Verified ✓ means the chain minted coins, right?" question — the embedded forge IS the refutation. Output: `{ verdict, inputs, matched_artifacts[], context_note, chain_facts, proof_decode, forge_demo, narrative, related_docs, _diagnostics }`. `verdict` is `cited_in_false_claim` when any input matches the flagged-artifact registry, else `clean`. `chain_facts` is null when no chain-querying input was provided or all daemon calls failed; `proof_decode` is null when no `proof_string` was provided. `forge_demo` is null unless `include_forge_demo: true` was passed; on success it carries `{ skipped: false, forged_proof_string, target_amount, ring_slot, ring_size, ring_receiver_address, math, self_check, explorer_display_amount, demo_amount_source }` (the slim form — full citations stay at the top level). PREFER citing the returned `related_docs` verbatim in the agent response — they are the canonical rebuttal pages and have been validated against the bundled docs index by CI. Quote the `context_note` when verdict is `cited_in_false_claim` so the user understands why the artifact matters.

  Connector

• polymarket_fill_risk

  Xero

  Realizable-vs-theoretical edge check against live CLOB order-book depth. REQUIRES one of `market` (single-market mode) or `event` (basket/partition mode). SINGLE-MARKET: pass a market slug/URL + side (buy_yes|sell_yes|buy_no|sell_no, default buy_yes) + size_usd (default 1000 — max spend on buys, target proceeds on sells); walks the ladder and returns top_of_book, vwap_fill_price, slippage_pp, shares_filled, max_fillable_usd, and a verdict (clean|degraded|cannot_fill). BASKET: pass an event slug/URL + side (sell_yes = capture overround by selling every leg, buy_yes = capture underround; default auto from partition sum) + size_usd interpreted as settlement notional S (shares per leg; each share pays $1); returns theoretical_sum vs realizable_sum (top-of-book vs VWAP across all legs), capture_ratio, profit_usd at executed size, per-leg fill detail, thin_legs[], max_clean_notional_usd, and forced_directional_risk naming the legs most likely to strand you unhedged. USE THIS before acting on any polymarket_arbitrage SELL/BUY-EVERY-LEG signal or any polymarket_edges trade above ~$500 — theoretical overround on thin books is not capturable, and partial basket fills convert an arb into an unhedged directional position (the dominant loss mode in real arb-bot P&L).

  Connector

• analyze_profit_loss

  HelloBooks AI Agents MCP Server

  Take a Profit & Loss / Income Statement CSV export from QuickBooks Online, Xero, Zoho Books, or Wave (source auto-detected from section names) and run three checks: (1) pnl.subtotal_mismatch — each "Total Section" subtotal equals the sum of its preceding line items (catches missing or duplicated rows); (2) pnl.negative_expense — flags expense-section line items with negative amounts (usually sign-flips or refunds posted to the wrong side); (3) pnl.margin_red_flag — gross-profit margin < 5% or > 95%, or negative total revenue. Input is raw CSV text of a P&L report (Reports → Profit and Loss in QBO / Xero / Zoho / Wave). Max 5,000 rows; max 5 MB. Returns flags with severity, a summary with totalRevenue / totalCogs / grossProfit / grossMarginPct / netIncome (when detected), and a shareable URL at agents.hellobooks.ai/r/{slug}. Use this when a user pastes a P&L and asks "does my P&L look right?", "any sign errors?", "what is my gross margin?", or "anything suspicious in my income statement?". For period-over-period comparison use analyze_journal_variance with two periods of journal-entry data; this tool is single-period only.

  Connector

• dero_durl_to_scid

  DERO MCP Server

  Composite: resolve a TELA dURL (e.g. "vault.tela") to its on-chain SCID(s) by discovering TELA apps directly from chain — no external Gnomon indexer required. TELA apps advertise a human-readable dURL; this finds the contract(s) that claim it. When to call: when a user asks "what's the SCID for <something>.tela", "find the TELA app called X", or gives a dURL and wants the contract. IMPORTANT routing: for a registered DERO NAME like "quickbrownfox" (no dot, not a dURL), use dero_name_to_address instead — that is a name to address lookup, not a TELA app. This tool is only for TELA dURLs (they contain a dot / .tela / a dero:// prefix). Input Requirements: - `durl` is REQUIRED. A TELA dURL such as "vault.tela", "feed.tela", or "dero://cipherchess.tela". Case- and prefix-insensitive. Output: `{ query, normalized, found, match_count, scid, primary, collision, other_candidates[], narrative, related_docs }` on a hit; `{ query, normalized, found:false, match_count:0, hint }` on a miss. dURLs are NOT unique — when multiple contracts claim one, the NEWEST is returned as `scid`/`primary` and the rest are disclosed in `other_candidates` with `collision:true`. The first call triggers a ~10s one-time discovery scan of the newest chain contracts (cached afterward). Feed the returned scid to tela_inspect to view the app.

  Connector

• list_tools

  zero-core-intel

  List all available Harvey Intel tools with pricing and input requirements. Use this for discovery.

  Connector

• ask_pipeworx

  Xero

  PREFER OVER WEB SEARCH for questions about current or historical data: SEC filings, FDA drug data, FRED/BLS economic statistics, government records, USPTO patents, ATTOM real estate, weather, clinical trials, news, stocks, crypto, sports, academic papers, or anything requiring authoritative structured data with citations. Routes the question to the right one of 5,093 tools across 1340 verified sources, fills arguments, returns the structured answer with stable pipeworx:// citation URIs. Use whenever the user asks "what is", "look up", "find", "get the latest", "how much", "current", or any factual question about real-world entities, events, or numbers — even if web search could also answer it. Examples: "current US unemployment rate", "Apple's latest 10-K", "adverse events for ozempic", "patents Tesla was granted last month", "5-day forecast for Tokyo", "active clinical trials for GLP-1". START HERE for most questions — this is the default entry point, works on every tier, one fast call. Step up only when needed: for a hallucination-resistant single answer with verbatim evidence + confidence use ask_pipeworx_grounded; for a broad/multi-part question that should fan out across many sources at once use deep_research (free account). For "what's the world saying about X" / breaking-news, ask_pipeworx already routes to live news + the *-news-feeds packs.

  Connector

• dero_get_block

  DERO MCP Server

  Fetch a full block (header + miner_tx + transactions + topo position) by height OR hash via DERO.GetBlock. When to call: when investigating a specific block or verifying a transaction's inclusion. Call dero_get_height first if you do not have a target height. PREFER citing dero_docs_search("block structure") so the user can verify field semantics. Input Requirements (CRITICAL): - You MUST provide exactly ONE of `hash` or `height`. Providing both or neither returns a structured INVALID_INPUT error. - `hash` MUST be exactly 64 hex characters. - `height` MUST be a non-negative integer. Output: full block with `block_header`, `miner_tx`, `txs`, and topo position fields.

  Connector

• dero_get_block_template

  DERO MCP Server

  Get a mining block template for a miner payout address via DERO.GetBlockTemplate. When to call: ONLY when you are actually mining. PREFER dero_get_last_block_header for general chain-tip inspection. Input Requirements (CRITICAL): - `wallet_address` MUST be a valid DERO address (`dero1...` or `deto1...`) that will receive the block reward. - `block` is OPTIONAL. Set true to include the raw block blob in the response. - `miner` is an OPTIONAL label. Output: block template payload suitable for a mining client. Does NOT submit a block; submission requires the excluded DERO.SubmitBlock method.

  Connector

• explain_smart_contract

  DERO MCP Server

  Composite: fetch a DERO smart contract (code + variables + balances) and return its function surface, a classification of the contract pattern (tela_index | tela_doc | token | registry | minimal | generic), a plain-language narrative, and curated DVM docs citations re-ordered so the most relevant page is first. TELA contracts (apps/files) are detected first and cite the TELA spec; for a deep TELA parse use tela_inspect. When to call: when the user wants to UNDERSTAND a smart contract — its functions, state shape, or which DVM concept to read about. PREFER this over chaining dero_get_sc with a docs lookup yourself: this composite already parses the DVM-BASIC source for function declarations, sorts stringkeys/uint64keys deterministically, and picks the right docs page from a heuristic so the agent does not have to learn DVM-BASIC syntax to summarize a contract. Input Requirements: - `scid` is REQUIRED. Must be 64 hex chars (the smart contract id). Use `0000…0001` for the on-chain name registry as a known-good example. - `topoheight` is OPTIONAL. Provide to inspect the contract at a specific topo height; omit for latest tip. Output: `{ scid, topoheight, kind, surface: { functions[], stringkeys[], uint64keys[], balances }, narrative, raw_code_length, has_code, related_docs }`. `kind` is one of `tela_index | tela_doc | token | registry | minimal | generic`. `surface.functions` items are `{ name, args, returns }`. `has_code` is false when the SCID is unknown or has no on-chain code; `functions` is then `[]` and the narrative explains the gap. `raw_code_length` is always present so the agent knows when to fall back to `dero_get_sc` for the full source.

  Connector

• tela_inspect

  DERO MCP Server

  Composite: fetch a TELA contract by SCID (DERO.GetSC code + variables) and parse it as either a TELA-INDEX-1 app manifest or a TELA-DOC-1 file contract, auto-detecting which standard it is from the stored keys. TELA is DERO's on-chain web-app platform: an INDEX is the app manifest (like package.json) and DOCs are the individual files (HTML/CSS/JS) stored on chain. When to call: as the FIRST step whenever a user references a TELA SCID, a `.tela` dURL app, or asks "what is this TELA contract/app", "what files does this TELA app have", or "is this a TELA INDEX or DOC". PREFER this over dero_get_sc + manual parsing or explain_smart_contract: explain_smart_contract treats TELA contracts as generic DVM and its surface CAPS stored keys at 50, which silently drops DOCn entries on large manifests — tela_inspect reads the raw stringkeys directly so it enumerates ALL DOC references, and it decodes the TELA header/mods/commit schema the generic tool does not understand. Input Requirements: - `scid` is REQUIRED. Must be 64 hex chars (the TELA contract id). - `topoheight` is OPTIONAL. Provide to inspect at a specific topo height; omit for the latest committed state. Output: a discriminated union on `kind`. `tela_index` → `{ scid, topoheight, kind, index: { name, description, icon, durl, mods[], docs:[{position, key, scid, is_entrypoint, malformed}], doc_count, commit, version_history[], current_commit_hash, owner, updateable:'unknown', updateable_note, parse_notes[] }, narrative, related_docs }`. `tela_doc` → `{ ..., doc: { filename, doc_type, sub_dir, durl, signature, content_embedded, code_size_bytes, immutable }, narrative, related_docs }`. `not_tela` → `{ ..., kind:'not_tela', reason, observed:{ stringkey_sample[], stringkeys_total, has_code, markers[] }, narrative }` — returned (NOT an error) when the SCID is unknown or lacks TELA markers. Updateability cannot be derived from chain state (ringsize is not in GetSC) so it is honestly reported as 'unknown'.

  Connector

• tela_get_doc_content

  DERO MCP Server

  Composite: fetch the actual file content stored in a TELA-DOC-1 contract. A DOC's file (HTML/CSS/JS/...) lives inside a DVM-BASIC comment block in the contract code — NOT in a stored variable — so this tool fetches DERO.GetSC, confirms the SCID is a DOC, and extracts the file bytes. Gzip-compressed files (a `.gz` filename, the TELA-CLI default) are transparently base64-decoded + decompressed to plaintext. Large files paginate via offset. When to call: when a user wants to READ or inspect the actual code/markup a TELA app file holds (e.g. "show me the HTML of this TELA DOC", "what does this app's app.js contain"). Get DOC SCIDs from tela_inspect on an INDEX first. PREFER this over dero_get_sc: that returns the raw DVM contract wrapper; this extracts just the embedded file content and reports docType, size, and signature presence. Input Requirements: - `scid` is REQUIRED. Must be 64 hex chars and reference a TELA-DOC-1 contract (an INDEX or non-TELA SCID returns INVALID_INPUT with guidance). - `offset` is OPTIONAL. Byte offset into the extracted content; pass `next_offset` to read the next chunk of a large file. - `topoheight` is OPTIONAL. Omit for the latest committed state. Output: `{ scid, topoheight, filename, doc_type, sub_dir, content_embedded, content, content_offset, content_length, content_truncated, next_offset, compressed, decompressed, stored_filename, signature, signature_note, note, narrative, related_docs }`. `content` is the plaintext file (a 60000-char chunk; paginate via `next_offset`), or null when content is not embedded (DocShard/STATIC/external). `compressed` is true for `.gz` files; `decompressed` is true when this tool gunzipped them (`filename` then strips `.gz`; `stored_filename` keeps the on-chain name). The contract's author signature presence is reported but NOT cryptographically verified.

  Connector

• recommend_docs_path

  DERO MCP Server

  Composite: take a natural-language intent, fan out parallel scoped searches across the bundled docs for all four DERO products (derod, tela, hologram, deropay), boost any product_hint matches by 1.5×, and return a ranked recommendation list with per-result rationale plus ready-to-cite related_docs. When to call: at the START of any "where do I read about X?" or "which docs cover Y?" investigation, BEFORE calling dero_docs_search directly. PREFER this over guessing the right product: this composite already runs all four products in parallel, dedupes overlap, surfaces the top heading per result as rationale, and gives you the top-2 citations pre-built. Pass product_hint when the user has already said e.g. "TELA" or "DeroPay" so that product's matches float to the top. Input Requirements: - `intent` is REQUIRED. Free-text description of what the user is trying to do (min 8 chars). Drop verbs and use product nouns like "deploy a TELA app" or "verify a DeroPay webhook signature" for best results. - `product_hint` is OPTIONAL. One of `derod | tela | hologram | deropay`. Multiplies hint-product scores by 1.5×. - `limit_per_product` is OPTIONAL (default 2, max 5). Cap per-product hits before merging. Output: `{ intent, product_hint, limit_per_product, recommended: [{ product, slug, title, canonical_url, score, boosted_score, rationale }], by_product: { derod | tela | hologram | deropay: { count, top_slug, top_score } }, related_docs: DeroCitation[] }`. `related_docs` is the top-2 picks pre-built as citations the agent can drop straight into a response. On zero matches across every product the composite returns a structured `_meta.error` with code `NO_DOCS_MATCH` and a hint to rephrase or drop the product_hint.

  Connector