"Xero" matching MCP tools:

• polymarket_arbitrageA

  XeroA

  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}. 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

• polymarket_fill_riskA

  XeroA

  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).

  ConnectorNo auth

• dero_get_block_templateA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• dero_docs_get_pageA

  DERO MCP ServerA

  Get a single bundled docs page by slug, with plain-text content and headings. When to call: AFTER dero_docs_search has returned a candidate slug, OR when you have a known slug from a prior citation. PREFER dero_docs_search first when you only have a topic in mind. Input Requirements (CRITICAL): - `slug` MUST be a non-empty doc slug relative to pages/ (e.g. `rpc-api/daemon-rpc-api`, `tutorials/first-app`, `dero-pay/quick-start`). - `product` is OPTIONAL but RECOMMENDED to disambiguate identical slugs across docs sites (`derod`, `tela`, `hologram`, `deropay`). - `offset` is OPTIONAL. Long pages (the Captain archive, deep RPC references) are returned in 60000-char chunks; if `content_truncated` is true in the response, call again with `offset: next_offset` to fetch the next chunk. Output: `{ product, slug, title, headings, content, content_offset, content_length, content_truncated, next_offset, canonical_url, last_updated, source_path }`. `content_length` is the total page size; `content_truncated` + `next_offset` signal whether to paginate.

  ConnectorNo auth

• diagnose_chain_healthA

  DERO MCP ServerA

  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`.

  ConnectorNo auth

• explain_smart_contractA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• tela_get_doc_contentA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• recommend_docs_pathA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• estimate_deploy_costA

  DERO MCP ServerA

  Composite: send a DVM-BASIC contract source to the daemon's gas estimator, then return the raw estimate alongside a plain-text breakdown (what each gas number means), the parsed contract surface, and curated DVM deploy docs as citations. When to call: BEFORE asking a wallet to broadcast a deploy transaction, OR when explaining the cost of a contract to a user. PREFER this over chaining dero_get_gas_estimate yourself: this composite already explains gascompute vs gasstorage in plain language, parses the SC source to show what functions the user is about to deploy (reusing extractScSurface from explain_smart_contract), and protects against fabricating a breakdown when the daemon reports 0/0 with a non-OK status. Input Requirements: - `sc` is REQUIRED. The full DVM-BASIC contract source — must contain at least one `Function ... End Function` block. A function body alone will fail with INVALID_INPUT. - `signer` is OPTIONAL. A dero1.../deto1... address that will sign the eventual deploy tx. The daemon uses it for fee context; omitting it still returns a meaningful estimate. - `include_breakdown` is OPTIONAL (default true). Set false when you only need the raw numbers (e.g. piping into a fee table). Output: `{ estimate: { gascompute, gasstorage, status }, breakdown: { compute_note, storage_note, total_units } | null, signer_used, include_breakdown, sc_surface: { functions, stringkeys, uint64keys, raw_code_length, function_count }, related_docs }`. `breakdown` is null when `include_breakdown=false` OR when the daemon returned 0/0 with a non-OK status (never fabricated). On DVM compile failure the composite returns a structured `_meta.error` with code `INVALID_INPUT` and the daemon's exact compile message in `_meta.error.raw`.

  ConnectorNo auth

• audit_chain_artifact_claimA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• convert_statementA

  BankstatementlyA

  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

• send_report_to_accountingA

  ExpenseBotA

  Review and then post an ExpenseBot report to the owner's accounting destination. STEP 1: call with provider, reportId, and optional mode/mappings, without confirm. The server reads the live report and destination, applies Omit/Personal/split/date/currency rules, checks Zoho bank-feed matches, and returns the complete proposal plus proposalId. NOTHING is posted in step 1. Show the complete proposal and ask for approval. STEP 2: call with only provider, proposalId, and confirm:true. The server posts only the frozen, account-bound proposal, revalidates live state, and rejects changed reports or mappings. Never add mapping fields to the confirmation call. Owner accounts only; acting for a client is not supported. Agent-driven posting is currently available only for Zoho Books (zoho_books); QuickBooks Online, Xero, Wave, and FreeAgent are intentionally not accepted by this tool yet because their previews cannot freeze/revalidate the canonical provider plan that shareReport executes. Use those providers' web flows until they satisfy the full push contract.

  ConnectorNo auth

• deep_researchA

  XeroA

  ACCOUNT REQUIRED (free — sign in via GitHub at https://pipeworx.io/signup; depth:"thorough" needs a paid plan). If you are not signed in, use ask_pipeworx instead — it works on every tier. Grounded multi-source research across Pipeworx's 1517 STRUCTURED data sources (SEC filings, FRED/BLS economics, FDA, USPTO patents, markets, science, government records, etc.) in ONE call — this is NOT open-web search. Decomposes your question into focused facets, routes each to the right one of 5,798 tools IN PARALLEL, and returns a findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding, with explicit gaps[] for facets the data couldn't answer (never invented). Best for broad/multi-part questions over structured data ("compare X and Y's regulatory + financial exposure", "research the filings + market picture for ACME"). For a single lookup use ask_pipeworx (one LLM call, not many). For BREAKING or colloquial CURRENT-NEWS / "what's the world saying about X" topics, prefer ask_pipeworx — it routes to live news APIs and the *-news-feeds packs; deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog. Second-hop iteration: depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads from the first pass — so multi-step questions resolve in one call. Every finding carries a `hop` field and a citation_uri — a resolvable pipeworx:// record URI, present only when the source emits one that resources/read can actually serve, so a citation you get back is always fetchable. "standard" and "thorough" also return contradictions[] flagging findings that disagree. Large records are semantically excerpted to the passages relevant to each facet (not head-truncated), so answers deep in a long filing/series aren't missed. Expect 15-60s (thorough with its follow-up + contradiction pass: up to ~90s).

  ConnectorNo auth

• dero_daemon_pingA

  DERO MCP ServerA

  DERO daemon connectivity check via DERO.Ping. When to call: as the first step in any chain investigation to confirm the daemon is reachable. Call before dero_get_info if you are unsure whether DERO_DAEMON_URL is correctly configured. Input Requirements: none. Output: a "Pong" string when the daemon is healthy. On failure this tool returns a structured _meta.error with code RPC_UNREACHABLE and a retry hint.

  ConnectorNo auth

• dero_durl_to_scidA

  DERO MCP ServerA

  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.

  ConnectorNo auth

• set_revenue_channelsA

  freedom-mcpA

  Declare where this business makes money — stripe, xero, shopify, amazon, ebay, manual invoicing, "none_yet" (pre-revenue), or other (name it). This is OPERATOR TRUTH an agent cannot derive, so it is gated: an autonomous agent CANNOT declare it — only a human (chat) or a graduated MCP operator can. Once declared, agents stop asking to connect Stripe for businesses that don't use it and are routed to the right revenue tool for this company's actual channel(s). Call get_setup_state first — if "Revenue channels" already shows done, only call this again when the operator says it changed. [sensitive-tier — company managers (executive/gm) run this without a card. Other members ask once; a from-now-on approval makes future calls seamless. Connecting a connector still needs the OAuth/connect card (request≠grant).]

  ConnectorNo auth

• verify_supplyA

  DERO MCP ServerA

  Composite: recompute DERO total supply offline via CalcSupply (premine + one-time launch credit + Σ CalcBlockReward epochs — DEROFDN community-dev / dero-docs schedule), optionally cross-check against DERO.GetInfo.total_supply. When to call: when the user asks "what is the total supply", "does GetInfo match the schedule", "verify the supply", or wants an independent recompute that does not trust a node. PREFER this over reading GetInfo alone — GetInfo on older builds can undercount after halvings (display quirk, not inflation). PREFER citing the returned related_docs (`integrity/verify-the-supply`). Input Requirements: - `height` is OPTIONAL. Non-negative integer topoheight/height. Default: tip topoheight from DERO.GetInfo. - If the daemon is unreachable you MUST pass `height` — otherwise the tool returns RPC_UNREACHABLE / INVALID_INPUT. Output: `{ height, height_source, calc_supply_atoms, calc_supply_dero, block_reward_atoms, block_reward_dero, getinfo_total_supply, match, formula_note, narrative, related_docs, _diagnostics }`. `match` is true/false when GetInfo.total_supply is present, else null. Scope is schedule CalcSupply only — NOT a UTXO census.

  ConnectorNo auth

• get_statementA

  BankstatementlyA

  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

• recent_changesA

  XeroA

  "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.

  ConnectorNo auth

• validate_claimA

  XeroA

  "Is it true that…" / "fact check" / "verify the claim that…" / "did X really…" / "was Y actually…" / "confirm or refute" / "true or false" — natural-language claim verification against authoritative sources. Use whenever the agent needs to check whether something a user said is factually correct. Company-financial claims (revenue, net income, cash for public US companies) verify via the structured SEC EDGAR + XBRL fast path with exact percent-delta math; ANY OTHER factual claim (macro statistics, rates, prices, drug data, records) automatically falls through to the grounded pipeline — routed to the right live source, answered with verbatim evidence, then judged. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported / could_not_verify), the grounded or structured actual value with pipeworx:// citation, and reasoning. IMPORTANT for callers: could_not_verify means the check did not happen (our LLM or source failed) and carries verification_error{stage,detail} — it is NOT evidence for or against the claim, and must not be shown as one. unsupported means we looked and cover no source for it. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).

  ConnectorNo auth

• pipeworx_feedbackA

  XeroA

  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