"Ram" matching MCP tools:

• ramp.compliance_screenA

  DPX — Institutional Cross-Border SettlementA

  Compliance pre-screen for Ramp accounting agent payments — run before issuing an Agent Card to eliminate unnecessary human approval queues. Performs 5 checks in parallel: (1) FATF country risk on source and destination country, (2) amount threshold flags (CTR-equivalent at $10K, large-payment at $100K), (3) OpenSanctions global sanctions screen by counterparty name, (4) OpenSanctions PEP screen for individual counterparties or payroll, (5) GLEIF UBO chain with sanctions at each beneficial ownership node (if LEI provided). Returns APPROVED / FLAGGED / BLOCKED with a humanRequired boolean — true only for FLAGGED cases. APPROVED: issue card automatically, no human needed. BLOCKED: halt, do not proceed, do not notify counterparty. FLAGGED: route to compliance queue. Removes human-in-the-loop for the ~95% of payments that are clean.

  ConnectorNo auth

• ramp.compliance_screenA

  DPX — Institutional Cross-Border SettlementB

  Compliance pre-screen for Ramp accounting agent payments — run before issuing an Agent Card to eliminate unnecessary human approval queues. Performs 5 checks in parallel: (1) FATF country risk on source and destination country, (2) amount threshold flags (CTR-equivalent at $10K, large-payment at $100K), (3) OpenSanctions global sanctions screen by counterparty name, (4) OpenSanctions PEP screen for individual counterparties or payroll, (5) GLEIF UBO chain with sanctions at each beneficial ownership node (if LEI provided). Returns APPROVED / FLAGGED / BLOCKED with a humanRequired boolean — true only for FLAGGED cases. APPROVED: issue card automatically, no human needed. BLOCKED: halt, do not proceed, do not notify counterparty. FLAGGED: route to compliance queue. Removes human-in-the-loop for the ~95% of payments that are clean.

  ConnectorNo auth

• get_resource_usageA

  DockholdA

  Show your account's compute, database-RAM, and storage pools: how much you've bought, how much is used, and how much is free, plus every app's current size. Call this before any resize tool (the allowed sizes come from its steps fields), and to explain to the user why an app ran out of memory or a deploy was refused for capacity.

  ConnectorNo auth

• list_channelsA

  Ray notificationsA

  List the delivery channels configured in this workspace (GET /channels). Call this FIRST before sending: each entry's `id` is the `channelConfigId` for send_notification and test_send_template, `kind` is the channel type (ses_email, smtp_email, fcm_push, slack_webhook, discord_webhook, telegram_bot, twilio_sms, sendsms_mn, generic_webhook), `templateKind` is the template channelKind it accepts, and `recipientSchema` is the exact JSON Schema of the `recipient` it expects. Channels and their provider credentials are set up in the Ray dashboard, not through this API; if the list is empty, ask the user to add one there.

  ConnectorNo auth

• create_templateA

  Ray notificationsA

  Create a template (POST /templates; write scope). `channelKind` is permanent and must match the channels you'll send through (list_channels `templateKind`). It is saved as an unpublished draft unless `publish: true`; sending by templateId needs a published version (publish_template). Names are unique per workspace including archived templates: a collision returns 409, so unarchive_template the old one instead. Returns `{ id, requiredParams }`. Designed (drag-and-drop) email templates can only be made in the dashboard.

  ConnectorNo auth

• update_template_draftA

  Ray notificationsA

  Replace a template's draft (PATCH /templates/{id}; write scope). This is a full replacement, not a partial patch: pass content, logTitle, logDescription and paramOverrides as they should end up (get_template first). `name`, `folder` and `channelKind` are required for validation but not changed (channelKind must equal the original). Live sends keep using the published version until you publish, either with `publish: true` here or publish_template. Fails on archived templates.

  ConnectorNo auth

• map_ownershipA

  ARM Verify — Entity Intelligence APIA

  Trace the corporate ownership chain above a company and identify the natural persons who ultimately control it. RETURNS JSON with: ownership_chain (array of parent entities, each with name, relationship, jurisdiction and is_ubo_candidate), natural_persons (array of identified beneficial owners, each with name, nationality and natures_of_control such as "ownership-of-shares-75-to-100-percent"), lei of the subject entity, complexity ("SIMPLE", "COMPLEX" or "UNKNOWN"), data_confidence ("HIGH", "MEDIUM" or "LOW") and notes describing the chain depth found. SOURCES: GLEIF Relationship API for LEI parent-child records, Companies House PSC (People with Significant Control) Register for UK entities, and the OpenCorporates corporate network. USE WHEN beneficial-ownership disclosure is required under AML or KYC rules, or to detect ownership by a sanctioned parent. Called via MCP — usage is logged but not billed. For metered billing use the REST API with an API key.

  ConnectorNo auth

• search_productsA

  TrustRailsA

  HOW TO CALL THIS TOOL — read before every call: Decompose the user's request into filters first. Only what's left over goes in query. STEP 1: brand name → brand filter. STEP 2: product category → category filter. STEP 3: price → min_price/max_price. STEP 4: RAM, storage, screen size, resolution, refresh rate, wattage, Wi-Fi generation → constraints. STEP 5: what remains → query. BAD: query='Sony headphones under £200' | GOOD: brand='Sony', category='Headphones', max_price=200, no query. BAD: query='tablet' | GOOD: category='Tablets', no query. BAD: query='macbook neo' | GOOD: brand='Apple', category='Laptops', query='neo'. BAD: query='Samsung QLED TV' | GOOD: brand='Samsung', category='TVs', query='qled'. If brand+category alone cover what the user wants, omit query entirely. Only put differentiating terms in query: model lines (neo, ultra, oled), variants, model numbers (WH-1000XM5, s25 ultra). Query words must appear in the title, except words naming the category ('router' in Networking) and bare numbers or specs ('4070', '16GB'), which are ignored when finding products and only rank them. Put a model number with its prefix ('RTX 4070', not '4070') and check each title for it. Leave out use-case words like gaming, cheap or best. CROSS-CATEGORY NOTE: Gaming headsets → category='Headphones', query='gaming headset'. The Gaming category is consoles/controllers/accessories only. Always set lite=true. If 0 results, broaden the query or drop filters (but never present a near miss as meeting a requirement). Searches 26,000+ UK electronics products across 7 retailers with price comparison. Prices are in GBP. PRICE COMPARISON: if offer_count > 1, call get_product for the 1-3 products you will recommend, not for every result, and show the cheapest retailer, the other prices with the difference and the exact saving. Only claim a saving between offers of the same configuration: if an attribute is `conflicting`, check offers[].title first. For specs not in `attributes` (ports, weight, battery), call get_product on the top 3-5 results; don't guess them from titles. SPEC REQUIREMENTS: put exact requirements in `constraints`, not in query, and always set `category` (and brand if known) with them: a search of only specs is rejected. If a requirement is ambiguous (e.g. '16GB' could be RAM or storage), ask the user or search without that constraint. With constraints, every product has `constraint_status` per name: 'matched' = a retailer's title states a value that meets it. 'unverified' = not known to meet it: check `attributes[name]`, where `conflicting` means retailers disagree and missing means unknown. Never treat 'unverified' as a match or say a product meets a requirement because it was returned: tell the user it is unconfirmed. Products whose stated value fails are left out (`excluded_by_constraints`). Matched results come first, also with sort='price_asc'. To say how many products matched, use `matched_total`, not `total`. If it is 0, say no product is known to meet every requirement and offer the unverified ones only as unconfirmed. With lite=true, `attributes` holds only the constrained names, as {status, value} or {status, values} when conflicting: state the value from there, and call get_product for the rest. If `candidates_truncated` is true, the first 2,000 candidates in the chosen sort order were checked and more exist: add a brand or category, or a narrower query, and search again before saying nothing matches. If the search was already narrowed, tell the user the results may be incomplete. STOCK: When availability is out_of_stock, mention it as an alternative and suggest checking back — do not silently omit it.

  ConnectorNo auth

• plan_deployA

  mcpA

  Turns YOUR repo classification (you scan the repo and pass what you found) into a complete, approvable deploy plan WITHOUT creating anything. ⚡ REDU NEEDS THREE FILES IF THEY EXIST - redu.md, the compose file, the Dockerfile - and there are two ways to give them. ⭐ BEST, for an upload-mode deploy: run prepare_upload FIRST and pass its `source_token`; redu reads all three straight out of the upload you already made, the upload stays deployable, and you emit nothing. Pasting the same files costs you 20-29 KB of output for bytes the server already has. Otherwise (git mode) paste `redu_md` (cat redu.md), `compose_yaml`, `dockerfile`. Either way you do NOT read or interpret them; redu parses them SERVER-SIDE and returns (a) a short digest, (b) `pin_dname` so a redeploy keeps the SAME public URL, and (c) `preflight` - preemptive fixes for known failure patterns found in YOUR repo, each learned from a real failed build. Giving redu these files is the single highest-value thing you can do for a first deploy. picks the VM + managed-Postgres sizes, prices them at the real pricing_rules rates, and checks they FIT your quota — so a plan that can't provision is caught HERE, before any spend. You pass what you detected in the repo (runtime, port, needs_postgres/redis/clickhouse/vector_db); it returns resources + £/hr + £/mo + a feasibility verdict + a checkpoint summary to confirm with the user. Defaults: app VM m1.medium, managed Postgres m1.small, managed ClickHouse m1.medium; pass single_vm to collapse the app + Postgres onto one VM. SET needs_clickhouse:true FOR ANY ANALYTICS-SHAPED APP (Plausible, PostHog, Langfuse, Matomo, SigNoz, or anything with a clickhouse image / CLICKHOUSE_* env / a ClickHouse client dep): those products keep config in Postgres and EVERY EVENT in ClickHouse, so the events tier is a second VM with a second line on the bill: measured 2026-08-07, omitting it quoted GBP 53.29/mo for a GBP 65.99/mo deployment. It is sized, quota-checked and priced here; unlike Postgres and Redis it is not auto-wired by deploy_app, so the plan tells you to run plan_managed_datastore engine:'clickhouse' -> create_clickhouse and pass CLICKHOUSE_* env yourself. Vector-DB needs are flagged, not provisioned. Any containerizable app works (node, python, go, ...) — it deploys as a container, so the language doesn't gate it. Set serves_http:false for a non-web repo (a library, CLI, or language runtime with no HTTP server) and it returns a clean not-a-web-service verdict instead of a costed VM plan. Set heavy_build:true for resource-heavy builds (compiled-from-source native code, a monorepo/turborepo build, a large Node heap) and it raises the app VM to a build-capable floor so the on-VM build doesn't get OOM-killed. Set memory_heavy:true for a RAM-forward app whose persistent state lives in a MANAGED DB / external store (Next.js like cal.com/cal.diy, Rails, Django, JVM/Java apps) — it sizes onto a memory-optimized SMALL-DISK flavor (m1.mem16/m1.mem32: full RAM, a lean 40 GB disk instead of 160 GB) that costs less and snapshots/clusters far faster; do NOT set it if the app keeps lots of data on local disk. Also returns a brand-named markdown report (Mermaid diagram + cost) to save as redu-deploy-plan.md and show the user. Every deploy leaves TWO MANDATORY files at the repo root with DIFFERENT purposes: redu-deploy-plan.md = THIS run's plan/estimate, and redu.md = the DURABLE deploy memory the NEXT deploy reads. If a redu.md exists, READ it FIRST and reuse its known-good plan + recorded fixes; if NONE exists, one MUST be created at the end of the deploy (get_deployment returns redu_md_bootstrap_markdown for exactly that case; when a redu.md DOES exist, pass it as redu_md and write the merged redu_md_markdown). They are SEPARATE files — even if your own memory/notes from a prior deploy call redu-deploy-plan.md 'the record', the durable record is redu.md, so do not skip creating it.

  ConnectorNo auth

• upgrade_to_clusterA

  mcpA

  THE WAY TO MAKE AN EXISTING APP HIGHLY AVAILABLE. If the user asks for high availability, redundancy, no single point of failure, surviving a host or VM failure, or 'stay up if a machine dies', this is the tool: point it at their running VM and pass high_availability:true. It needs no rebuild and no redeploy, and the URL does not change. Turns a single running instance into a horizontally-autoscaling cluster: snapshots the instance and puts your SOURCE VM behind a load balancer as its ALWAYS-ON BASELINE MEMBER, then an autoscaling group adds EXTRA members (booted from that snapshot) on CPU load and scales them back down to zero. FLAVOR — LEAD WITH A MEMORY-OPTIMIZED SMALL-DISK FLAVOR (m1.mem16/m1.mem32) for the cluster, and ideally have the SOURCE VM on one too: clustering snapshots the source VM's FULL disk, so DISK size (not RAM) drives how long the cluster takes to build and to add each member under load — a 40 GB mem flavor is several times faster to snapshot and scale than a 160 GB standard flavor (m1.xlarge) and costs less for the same RAM. If the source VM is on a big-disk flavor, RECOMMEND migrating the app onto a mem-flavor VM first (a root disk cannot be shrunk in place), even though it is extra work — it pays off on every scale-out, and a clustered app is stateless anyway (state in the managed DB) so the lean disk fits. Expect a DRASTICALLY better clustering experience on a mem flavor: far faster cluster-create, snapshots, and every scale-out. The user can override with any flavor. At rest ONLY your source VM serves — there is NO idle extra VM to pay for (the source VM is the cluster's minimum, so the floor is 0 extra members). Use it to LOAD-SCALE a stateless app tier while managed services hold state: it becomes highly-available UNDER LOAD (multiple members behind the LB), but at rest a SINGLE source VM serves — and that source VM is a plain VM, not an autoscaled member, so it is NOT auto-replaced if it fails while idle (only the autoscaled extra members are ASG-managed and self-healed). If you need always-on redundancy, keep the app under enough load to hold >=1 extra member, or use a separate always-on setup. BILLED — at rest it costs just your source VM (which you already run) plus the load balancer; under load it adds up to max_size EXTRA members at the member flavor (flavor_id), billed only while they run. In guided mode show the cost that way (now: source VM already running + the LB; under load: up to max_size x the member flavor) and get the user's explicit go first. redu automatically repoints the extra members from the old single-VM URL to the load-balancer URL across app config. It REFUSES a STATEFUL VM with 409 cluster_needs_stateless unless confirm_stateless:true. To have redu FIX a stateful VM for you instead of refusing, pass auto_restructure:true — for a single_vm Postgres it fully-automatically provisions a managed DB + migrates the data + repoints the members; for a compose-stack DB it provisions the matching managed DB (set restructure_engine, e.g. 'mysql'/'mariadb' for WordPress) and returns migration commands to run from the app VM. WordPress/WooCommerce is not generic autoscaling: managed DB alone is not enough because wp-content/uploads is file state. Use app_profile:'wordpress'/'woocommerce', cluster_media_mode:'media_space', and either media_space_id or create_media_space:true so all members mount the same uploads filesystem; otherwise the backend refuses with 409 cluster_needs_media_space. PUT THE CLUSTER ON THE SAME private network as the managed DB and media space. HA: cluster members are spread across DIFFERENT physical hosts automatically, and an autoscaled member that is destroyed is REBUILT AUTOMATICALLY in 1.5 to 5 minutes depending on how it failed with no action from you (the always-on source/hero VM is a plain VM and is NOT covered by that). CRITICAL for members: the app must start on EVERY boot (systemd unit or container restart policy) - if it only starts from a first-boot cloud-init script, a rebooted or resized member comes back with no app, silently never rejoins the load balancer, and the cluster quietly loses capacity with nothing reporting an error. Pass startup_command if the app does not already auto-start on boot, and have it bind its port only once it is genuinely ready to serve (the health check can only see whether the port is open). SEQUENCING - this catches people: the snapshot is taken IMMEDIATELY, and every member boots from it, so the source VM's app must already be RUNNING before you call this. Clustering a freshly-created VM whose cloud-init has not finished captures an image with no enabled service, and all members then come up ACTIVE while failing the load-balancer health check forever - a cluster that looks built and serves nothing. Verify the app answers on its port first (get_ssh_command, or just fetch the VM's URL). The snapshot upload can take several minutes; poll list_clusters until CREATE_COMPLETE.

  ConnectorNo auth

• create_clickhouseA

  mcpA

  Provisions a managed ClickHouse database (OLAP / columnar analytics engine, Apache-2.0) on a dedicated VM on your private network — its OWN resource, NOT a relational database. Requires a recent plan_managed_datastore. Use it for analytics / observability workloads that need a column store (PostHog, Langfuse, event analytics, time-series). It is PRIVATE — reachable only from another instance on the same private network, via the DB's internal/private IP on the ClickHouse HTTP port 8123 (CLICKHOUSE_HOST/PORT/USER/PASSWORD/DB env, http://host:8123). Get the ids from plan_managed_datastore/list_flavors (use m1.small+ — ClickHouse needs >=2GB RAM), list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_clickhouse_databases until status='ready'. HIGH AVAILABILITY: pass ha:true to get THREE machines on three different physical hosts behind a load balancer instead of one: all three take reads and writes, so losing a machine costs no failover and no write pause, and the replacement refills itself from the survivors before it serves again. It costs about 3x the hourly rate (three machines instead of one) and provisions more slowly. Default is a single machine; show the user the price difference and get an explicit yes before turning HA on.

  ConnectorNo auth

• resize_databaseA

  DockholdA

  Change how much memory an app's managed database gets. Call this when the database is slow or out of memory. db_ram_mb must be one of the sizes get_resource_usage reports under db_ram.steps_mb and fit your database-RAM pool. WARNING: the database restarts briefly to apply the new size, so the app loses its database connection for a few seconds. Only works if the app has a managed database.

  ConnectorNo auth

• dispatch_to_llmA

  Nervous SystemB

  Spawns a background LLM agent to handle a task. Checks RAM (needs 500MB+), enforces max 2 concurrent dispatches. Returns PID and log file path.

  ConnectorNo auth

• price_checkA

  PCBLT — Live ChecksA

  Judge whether a specific asking price for a PC part is good, by comparing it against tracked market data. Use when someone asks 'is $X a good price for Y' or wants a listing sanity-checked. Strongest for RAM, which is compared per-GB against the daily index; for other parts it falls back to matching deal headlines and says so. Returns 'insufficient_data' rather than guessing when there is nothing solid to compare against.

  ConnectorNo auth

• test_send_templateA

  Ray notificationsA

  Send a real test of a template's PUBLISHED version to one recipient (POST /templates/{id}/test-send; write scope). It goes through the provider for real, so use a recipient the user controls. Test sends don't count toward the monthly quota (a small daily allowance applies instead) and never appear in feeds. Returns `{ sendId }` for get_send_status.

  ConnectorNo auth

• search_filesA

  Razuna DAM MCPB

  PRIMARY TOOL: Search for files using natural language. Prefer plain natural-language queries because the Razuna Files AI Chat planner handles semantic intent, sorting, limits, and file-type intent. Use API-compatible scoped search only when explicit folder/search_filters/collect_plus values are needed. Valid search_filters ids are folders, extensions, types, tags, keywords, date_added, and date_modified.

  ConnectorOAuth

• zfs_ramA

  calc.engineerA

  Calculate recommended RAM and ARC sizing for a ZFS storage pool based on workload type, pool size, deduplication status, and L2ARC cache size. Computes minimum and recommended RAM in gigabytes, ARC target size, and dedup table overhead. Accounts for workload-specific IO patterns: NAS (sequential, 1GB/TB), database (random, 2GB/TB), virtualization (mixed, 1.5GB/TB). Deduplication adds approximately 5GB per TB for the DDT. L2ARC index requires 1GB RAM per 10GB of L2ARC. Essential for TrueNAS, FreeNAS, and custom ZFS server builds.

  ConnectorNo auth

• ramp.agent_cardA

  DPX — Institutional Cross-Border SettlementA

  Create a scoped Ramp Agent Card — a single-use virtual card with a merchant and amount cap, expires after first authorization or 12 hours. Used to fund the fiat leg of a DPX settlement without pre-funding a crypto wallet. Returns a task ID; poll ramp.agent_card_status to get PAN/CVV once ready. Requires cards:read_agentic scope (granted via ramp.connect).

  ConnectorNo auth

• list_plansA

  AgentMetalA

  Step 1 of renting a real Linux server. Lists AgentMetal VPS plans (vCPU/RAM/disk, USD/day + USD/mo, included egress). After you pick a plan, call `get_payment_options` for the exact payment, then provision by POSTing to the API 402 or running the local @agentmetal/mcp (which pays from your wallet).

  ConnectorNo auth

• screen_sanctionsA

  ARM Verify — Entity Intelligence APIA

  Screen a company or person against consolidated government sanctions lists and a politically-exposed-person dataset. RETURNS JSON with: screening_result (one of "MATCH", "POSSIBLE_MATCH", "CLEAR"), risk_level ("CRITICAL" for a confirmed match, "HIGH" for a possible match, "LOW" when clear), recommendation ("DO_NOT_PROCEED", "ENHANCED_DUE_DILIGENCE" or "PROCEED"), matches (array, each with list, matched_name, confidence as a percentage string such as "100%", type and id), pep_screening (separate PEP verdict with its own matches), sanctions_lists_checked, total_entries_screened, data_freshness (ISO timestamp of the last refresh) and screening_date. SOURCES: OFAC SDN (US Treasury), UN Security Council Consolidated List, EU Financial Sanctions List, and the UK FCDO UK Sanctions List (UKSL) — approximately 32,600 designations in total, plus roughly 1,000,000 PEP names from OpenSanctions. All lists are re-downloaded from the official government endpoints daily at 03:00 UTC. USE WHEN you must clear a counterparty before payment, onboarding, or any transaction with sanctions exposure. Called via MCP — usage is logged but not billed. For metered billing use the REST API with an API key.

  ConnectorNo auth

• score_riskA

  ARM Verify — Entity Intelligence APIA

  Produce a composite 0-100 financial-crime risk score for a company from its jurisdiction, sector and sanctions exposure. RETURNS JSON with: risk_score (integer 0-100, where 0 is lowest risk and 100 is highest), risk_level ("LOW", "MEDIUM", "HIGH" or "CRITICAL"), recommendation ("PROCEED", "ENHANCED_DUE_DILIGENCE" or "DO_NOT_PROCEED"), fatf_status (the FATF listing state of the jurisdiction, e.g. "BLACKLIST", "GREYLIST" or "NOT_LISTED"), basel_aml_score (Basel AML Index country score, roughly 0-10 where higher is worse), sector_risk, and notes explaining which factors drove the score. SOURCES: FATF high-risk and increased-monitoring lists, Basel AML Index 2025, live sanctions-screening output, and the ARM sector risk classification. USE WHEN you need a single comparable risk figure for onboarding thresholds, portfolio ranking or periodic review. Called via MCP — usage is logged but not billed. For metered billing use the REST API with an API key.

  ConnectorNo auth