"BIM" matching MCP tools:

• deep_research

  Bis

  Grounded multi-source research in ONE call. Decomposes your question into focused sub-questions, routes each to the right one of 3,754 tools across 886 authoritative sources IN PARALLEL, and extracts a grounded answer per facet — verbatim evidence, confidence, source, fetched_at, and a stable pipeworx:// citation on every finding, with explicit gaps[] for facets the data couldn't answer (never invented). Returns a structured findings packet you can synthesize for your user; the facts arrive pre-verified. Use for broad or multi-part questions ("compare X and Y's exposure to Z", "research the regulatory + financial + market picture for ACME"); use ask_pipeworx for single lookups — it's one LLM call instead of many. Requires a Pipeworx account (sign in via GitHub at https://pipeworx.io/signup); depth:"thorough" requires a paid plan. Expect 15-60s.

  Connector

• recent_alerts

  Bnm My

  Pull fired events from your subscription feed. Returns the most recent alerts the evaluator has written to your persisted feed — each carries source, citation_uri (pipeworx:// when available), and the raw event payload. Filter by type (e.g. "sec_8k") and/or since (ISO timestamp). Set mark_read:true to flag returned events read so the next call only shows newer ones. Polls work fine; the same feed is also at GET registry.pipeworx.io/alerts.json for scripts and dashboards.

  Connector

• pipeworx_feedback

  Tinder Bio

  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

• scan_dependency

  Tinder Bio

  Composite "should I add this npm package to my project" check in ONE call — fans out across deps.dev (license + advisories + version history) and bundlephobia (gzipped/minified bundle size, dependency count, ESM/tree-shake support). Use whenever an agent asks "is X safe / popular / small" or "what does adding lodash cost me". Returns a summary block (is_latest, license, published_at, advisory_count, bundle_kb_min, bundle_kb_gz, dependency_count, has_esm, tree_shakeable), per-advisory detail, links, and a list of recent alternative versions. NPM ecosystem only in v1; PyPI / Maven / Cargo / Go fall under deps.dev:version directly. Partial failures degrade gracefully — bundlephobia's first measurement on a new version can take 5-30s; sources_failed will list it if it times out, the rest still returns.

  Connector

• polymarket_fill_risk

  Tinder Bio

  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

• recent_changes

  Tinder Bio

  "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

• pipeworx_feedback

  Bis

  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

• polymarket_fill_risk

  Bis

  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

• polymarket_arbitrage

  Tinder Bio

  REQUIRES one of `event` (single-event mode) OR `topic` (cross-event mode) — call with no args fails. Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. `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.

  Connector

• recent_changes

  Bnm My

  "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

• acc_project_summary

  ACC MCP

  Fetch the full ACC project metadata record (name, type, status, dates, extension attributes) for a single project via APS Data Management. If hub_id is omitted the tool picks the first accessible hub, which may be wrong on multi-hub tenants. When to use: The user asks 'tell me about project X' or an agent needs project metadata (start/end dates, type, Forma/BIM 360 flavor) before deciding which downstream tool to call. When NOT to use: Do not use as a cheap existence check — prefer acc_list_projects which returns hub_id with every project and is one call regardless of tenant size. APS scopes: data:read account:read. Forma / BIM 360 hubs endpoints only require data:read. Rate limits: APS default ~50 req/min per endpoint; BIM 360 hubs endpoints pageable (limit 200). Cache results for the session. Errors: 401 (APS token expired — refresh); 403 (user lacks project view or app not in account); 404 (project not in the chosen hub — supply the correct hub_id, or call acc_list_projects first); 422 (malformed project_id — confirm 'b.' prefix); 429 (rate limit — back off 60s); 5xx (ACC upstream — retry). Side effects: None. Read-only and idempotent.

  Connector

• search_within

  Tinder Bio

  Semantic search INSIDE a fetched record. Pass the text you already pulled (e.g. a SEC 10-K body, an article, a long tool result) plus a natural-language query; get back the top-N passages with character offsets and similarity scores. Use when the record is too big to cram into the prompt — search_within saves context, returns only the passages that matter, and every passage carries an offset so the agent can verify a verbatim quote. Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document. BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).

  Connector

• acc_list_projects

  ScanBIM MCP

  List every Autodesk Construction Cloud (ACC) / BIM 360 project the configured APS 2-legged app has access to, flattened across all hubs, with hub_id, hub_name, project_id, project_name, and project type. When to use: you need a project_id to pass into acc_create_issue, acc_list_issues, acc_create_rfi, acc_list_rfis, acc_search_documents, or acc_project_summary. When NOT to use: you already have the b.xxxx project_id. This tool makes N+1 API calls (one per hub) so avoid calling it in tight loops. APS scopes: data:read account:read Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; OSS uploads size-limited per file to 100MB for direct upload, larger via resumable. Errors: 401 APS token expired/invalid — refresh; 403 scope or resource permission denied (app not provisioned for any hub in ACC Account Admin → Custom Integrations); 404 no hubs found — check APS app provisioning; 429 rate limited — backoff and retry; 5xx APS upstream outage — retry with jitter. Side effects: READ-ONLY. Inserts a row into D1 usage_log. Idempotent.

  Connector

• nwd_upload

  Navisworks MCP

  Upload a Navisworks file (.nwd/.nwf/.nwc) to Autodesk Platform Services (APS) Object Storage and start an SVF2 translation job so the model becomes queryable by the other nwd_* tools. When to use: at the start of a coordination workflow — e.g. the GC hands off a federated NWD combining MEP + structural + architectural models and the agent needs to stage it for clash review before issuing an RFI, or when a subcontractor publishes a new NWC model revision that must be ingested for weekly BIM coordination. Always the first call in a session for any new model. When NOT to use: do not call for already-translated models (re-use the returned model_id/URN); do not use for raw Revit .rvt, IFC, or DWG — those go through a different MCP. APS scopes required: data:read data:write data:create bucket:read bucket:create viewables:read. The worker acquires a 2-legged client-credentials token; the caller does not supply one. Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation job submission ~60 req/min. NWD bundles can be large (hundreds of MB); the upload PUT and translation can take minutes — translation is asynchronous, poll via nwd_export_report (manifest) with exponential backoff (e.g. 5s, 10s, 30s, 60s) before calling clash/properties tools. Errors the agent should handle: 401 invalid/expired APS token (surface as auth failure — do not retry with same creds); 403 missing scope (report scope gap, do not retry); 404 source file_url unreachable (ask user for a fresh public URL); 409 bucket already exists (handled internally, safe to ignore); 413/422 unsupported Navisworks version — APS Model Derivative supports NWD/NWC from Navisworks 2015 and later (state the unsupported version to the user); 429 rate limited (exponential backoff, retry); 5xx APS upstream (retry once, then surface). Side effects: creates a fresh transient OSS bucket (scanbim-nwd-<timestamp>, 24h TTL) and uploads the file as an object, then POSTs a Model Derivative translation job. NOT idempotent — each call creates a new bucket/URN even for the same file_url. Logs usage to the D1 usage_log table.

  Connector

• polymarket_arbitrage

  Bis

  REQUIRES one of `event` (single-event mode) OR `topic` (cross-event mode) — call with no args fails. Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. `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.

  Connector

• compare_entities

  Bnm My

  "Compare X and Y" / "X vs Y" / "X versus Y" / "which is bigger / better / larger / more profitable" / "rank these companies" / "head to head" — side-by-side comparison of 2–5 companies or drugs in ONE parallel call. ALWAYS PREFER over sequential single-pack lookups when comparing entities. type="company" pulls LATEST 10-K revenue + net income + cash + long-term debt from SEC EDGAR/XBRL (off-calendar fiscal years handled correctly — AAPL Sep, NVDA Jan, etc.). type="drug" pulls FAERS adverse-event counts, FDA approval counts, active trial counts. Results sorted by primary metric so "largest" / "most" / "biggest" reads off the top of the response. Returns paired data + pipeworx:// citation URIs per entity. Replaces 8–15 sequential lookups.

  Connector

• bet_research

  Tinder Bio

  Research a Polymarket bet by pulling the relevant Pipeworx data for it in one call. Pass a market slug ("will-bitcoin-hit-150k-by-june-30-2026"), a polymarket.com URL, or a question text. The tool resolves the market, classifies the bet, fans out to category-specific data packs in parallel, and returns an evidence packet + simple market-vs-model comparison. Use for "should I bet on X", "what does the data say about Y", or "is there edge in Z". CLASSIFIERS: crypto_price, fed_rate, geopolitical, sports, sports_championship, drug_approval, election_candidate, tech_launch, space_launch, corporate, corporate_earnings, corporate_event, public_figure_speech, weather, other. FAN-OUT EXAMPLES: BTC bet → coingecko + fred + gdelt+gnews; Fed bet → fred (DFEDTARU + EFFR + CPIAUCSL) + kalshi_macro (KXFED implied probs) + recent_fed_actions (federal-register rules, last 365d); Hormuz bet → imf_portwatch + airspace + gdelt; Yankees WS → mlb_stats_standings + parent_event partition + news; hottest-year bet → climate_projection_nyc + gistemp_latest (NASA global anomaly, rank since 1880) + news; NVDA-vs-AAPL → finnhub get_quote + edgar shares-outstanding (derived market cap) + edgar filings + news. RESPONSE SHAPES: result.market carries best_bid/best_ask/spread_pp/liquidity/price_change_1h/1d/1w; result.analysis carries model_probability/edge_pp/kelly_fraction_half when a closed-form model fires PLUS a 24h-move warning ("Market moved X.Xpp in 24h, comparable to model edge — your edge may already be priced in") when relevant; result.evidence is keyed by source. RESOLVER CONTRACT: result.market_match_confidence ∈ {high, medium, low, none}, market_match_score (0-1 token-overlap), market_match_alternatives[] (other candidate markets the resolver considered), and suggestions[] (explicit re-query hints when the match is fuzzy) — ALWAYS inspect these before trusting the analysis block, because medium/low matches can still surface other fields. PARENT_EVENT EXTRACTOR: when the bet is one leg of a partition (Yankees WS, Romania election), result.parent_event{matched_candidate, top_legs_by_price[], partition_size, placeholders_filtered} gives you the peer prices in one place — that's the headline for elections/championships. NEWS FIELDS: news entries carry _fallback_attempted / _fallback_failed_reason / retry_after_sec when GDELT 429s and GNews backfill ran or failed. SAFETY: low-confidence resolutions short-circuit with status:"low_confidence_match" and suppress analysis fields so agents can't accidentally size on phantom matches. Closed/dead markets that ARE still indexed by Polymarket (yes_price≈0, no volume, no liquidity) return status:"market_closed_or_inactive" and skip fan-out. In practice resolved markets are usually de-indexed and instead surface via the low_confidence_match path above — both routes are BLOCKING, just different mechanisms. Wide-spread markets (>10pp) carry tradeability:"illiquid_wide_spread" + an explanatory note. RESOLUTION-RULE RISK: market.cancellation_rule parses the void/postponement settlement out of the resolution text — refund_50_50 (shares settle flat 50¢ on void; EV-material for any entry away from 50¢, with ev_impact quantified), resolves_no_on_cancel, resolves_yes_on_cancel, carries_to_reschedule, or mentioned_unclear. null means the description never mentions cancellation. Check this before sizing sports/esports/event-occurrence bets — audited arb-bot ledgers show flat-50¢ void settlements are a recurring pure-rules loss.

  Connector

• compare_entities

  Tinder Bio

  "Compare X and Y" / "X vs Y" / "X versus Y" / "which is bigger / better / larger / more profitable" / "rank these companies" / "head to head" — side-by-side comparison of 2–5 companies or drugs in ONE parallel call. ALWAYS PREFER over sequential single-pack lookups when comparing entities. type="company" pulls LATEST 10-K revenue + net income + cash + long-term debt from SEC EDGAR/XBRL (off-calendar fiscal years handled correctly — AAPL Sep, NVDA Jan, etc.). type="drug" pulls FAERS adverse-event counts, FDA approval counts, active trial counts. Results sorted by primary metric so "largest" / "most" / "biggest" reads off the top of the response. Returns paired data + pipeworx:// citation URIs per entity. Replaces 8–15 sequential lookups.

  Connector

• tm_import_rvt

  Twinmotion MCP

  Import a Revit/BIM model into the Twinmotion visualization pipeline: downloads the source file from a public URL, uploads it to an APS OSS transient bucket, and kicks off an SVF2 + thumbnail translation job. Returns the base64 URN (project_id) used by every other tm_* tool. When to use: when a user wants to prepare a Revit (.rvt), IFC (.ifc), or other BIM/CAD model for real-time visualization in Unreal Engine / Twinmotion — typically the first step before rendering stills, defining scenes, or exporting FBX/glTF/OBJ geometry for a UE import. Also use when you need thumbnails or view metadata from a source file that has not yet been translated by APS. When NOT to use: not for MEP clash review (use navisworks-mcp), not for quantity takeoff or cost estimation (use qto-mcp), not for Twinmotion presets editing — Twinmotion itself has no public REST API, so scene/material authoring must happen manually in the UE editor after FBX/USD export. APS scopes required: data:read data:write data:create bucket:read bucket:create viewables:read. Uses Model Derivative API (translation) + OSS (upload). Twinmotion has no public REST API; all automation is APS Model Derivative + manual Unreal Engine export. Rate limits: APS default ~50 req/min per app per endpoint; Model Derivative translation jobs ~60 req/min; large .rvt/.nwd/.ifc files are often multi-GB and translation can take 5–60 min — poll the manifest with exponential backoff (start 5s, cap 60s) rather than retrying this tool. Worker request ceiling is ~100MB body; extremely large files may need signed-URL upload instead. Errors: 401 = APS token failed (check APS_CLIENT_ID/APS_CLIENT_SECRET, re-auth); 403 = scope missing (bucket:create/data:write not granted — have user re-consent); 404 = file_url unreachable; 409 = bucket key collision (rare — retry, tool uses timestamp); 413/507 = file too large for worker memory (advise signed-URL upload); 422 = unsupported source format (only Autodesk-accepted types: rvt, ifc, nwd, dwg, dgn, 3dm, stp, etc.); 429 = back off 60s before retrying; 5xx = APS upstream outage, retry with backoff. Side effects: CREATES a new transient OSS bucket (scanbim-viz-<timestamp>, auto-expires in 24h), CREATES an object in OSS, STARTS a translation job consuming APS cloud credits. NOT idempotent — each call creates a new bucket + URN. Writes a row to usage_log D1 table.

  Connector

• nwd_export_report

  Navisworks MCP

  Build a coordination report for a translated Navisworks model: translation status/progress, derivative outputs, available views (2D sheets / 3D viewables), total element count, and a per-category element breakdown. Doubles as the canonical way to poll translation status after nwd_upload. When to use: after nwd_upload to check whether translation has completed before calling clash/object tools; at the end of a coordination session to generate a status snapshot for the weekly BIM report; when auditing a model revision to confirm expected element counts per discipline. When NOT to use: do not use for a per-element property dump — use nwd_list_objects; do not use for clash results — use nwd_get_clashes. APS scopes required: viewables:read data:read bucket:read (read-only). Rate limits: APS default ~50 req/min per endpoint; this tool issues up to 4 sequential APS calls (manifest, metadata, properties — two with retry). When polling for translation completion, backoff: 5s, 10s, 30s, 60s, 120s — Model Derivative NWD translation typically completes in 1-10 min but large federated models can take 20+ min. Errors: 401 APS token expired (retry); 403 missing scope (report); 404 URN not found (model was never uploaded or bucket TTL expired); 409 N/A; 422 translation failed permanently — inspect report.translation_status == "failed" and report.derivatives[].status; 429 rate limit (backoff); 5xx APS upstream (retry once). Property extraction may legitimately 202 "isProcessing" — the tool handles retry and then silently swallows to still return manifest/metadata (element_count will be 0 until properties index is built). Side effects: none. Pure read. Idempotent — report reflects current APS state. Logs usage to D1 usage_log.

  Connector