"namespace:io.github.bmlt-enabled" matching MCP tools:

• buy_domain_crypto

  instadomain

  Start the purchase flow for a domain using USDC crypto payment (x402 protocol). Autonomous two-step payment flow — no browser required: Step 1: Call this tool to reserve the domain and get a pay_url. Step 2: Pay the pay_url using your x402 wallet: - If you have Coinbase Payments MCP: call its x402 payment tool with the pay_url. - Otherwise: run `curl -L <pay_url>` — your x402-enabled HTTP client will handle the 402 handshake and USDC payment on Base automatically. After payment succeeds, call get_domain_status(order_id) to poll until registration is complete (usually under 60 seconds). The registrant contact details are required because the domain will be registered in the buyer's name (they become the legal owner). WHOIS privacy is enabled by default, so these details are not publicly visible. IMPORTANT: Before calling this tool, you MUST first call check_domain to get the price and confirm it with the user. Args: domain: The domain to purchase (e.g. "coolstartup.com"). first_name: Registrant's first name. last_name: Registrant's last name. email: Registrant's email address. address1: Registrant's street address. city: Registrant's city. state: Registrant's state or province. postal_code: Registrant's postal/zip code. country: 2-letter ISO country code (e.g. "US", "GB", "DE"). phone: Phone number in format +1.5551234567. org_name: Organization name (optional, leave empty for individuals). Returns: Dict with order_id, pay_url (full URL to pay via x402), price_usdc, price_cents, network, and USDC contract address.

  Connector

• automation_list

  Perspective AI

  Lists every automation configured on a perspective with its trigger, channel (sensitive details redacted), execution mode, enabled state, schedule description, and recent error/success metadata. Behavior: - Read-only. - Errors when the perspective is not found or you do not have access. - Sensitive parts of channel delivery (e.g., webhook auth headers, full URLs) are redacted before being returned. - has_error / last_error / last_error_at / failure_count appear only when there have been recent failures. When to use this tool: - Auditing what's wired up on a perspective before adding more automations. - Finding an automation_id to feed into automation_update, automation_delete, or automation_test. - Diagnosing a failing automation via last_error / failure_count. When NOT to use this tool: - Creating a new automation — use automation_create. - Toggling enabled or changing config — use automation_update. - Verifying delivery actually works — use automation_test.

  Connector

• account_show_infos

  Kash.click

  Retrieve all current settings of the authenticated shop account as a JSON object. Returns the full shop configuration: name, address, legal numbers, receipt options, order requirements, enabled features, delivery methods, webshop colours, and third-party integration settings. Use this to verify invoice prerequisites before creating orders: shopName, adressline1, and companyRegistrationNum must all be set for legally valid invoices. If any are missing, prompt the user to fill them in via account_edit.

  Connector

• queryPointInTimeMetrics

  Cortex

  Execute point-in-time queries for one or more engineering metrics. Returns current metric values for specified time periods, with support for batch queries and optional period-over-period comparisons. Time range (startTime/endTime) cannot exceed 6 months (180 days). PREREQUISITES - Follow this workflow: 1. Discover all available metrics ONCE: Call listMetricDefinitions (view='basic') - cache this response 2. Get metric query metadata ONCE per metric: Call listMetricDefinitions (view='full', key=METRIC_KEY) - supportedAggregations: Valid aggregation methods - orderByAttribute: Attribute path for sorting by metric values - groupByOptions[].key: Valid groupBy keys (use exact values, do NOT guess) - filterOptions[].key: Valid filter keys (use exact values, do NOT guess) Cache the full view response for each metric. Reuse the metadata from cached responses for subsequent queries on the same metric. 3. Construct query: Use the query metadata from the full view responses in step 2 to build valid point-in-time requests IMPORTANT: Cache only results from listMetricDefinitions. Do NOT cache point-in-time query results - always execute fresh queries for current data. Only refresh cached listMetricDefinitions responses if no longer in your context window or explicitly requested. Do NOT guess attribute names - always use exact values from listMetricDefinitions responses. Response includes: - Lightweight metadata: Column definitions optimized for programmatic use - Row data: Actual metric values and dimensional data - No heavy schemas: Source definitions excluded (get from listMetricDefinitions instead) Error responses: - 400: Invalid metric names, date range, validation errors, or unsupported metric combinations - 403: Feature not enabled (contact help@cortex.io)

  Connector

• automation_create

  Perspective AI

  Creates an automation on a perspective. Triggers: per_interview (fires on every completed conversation) or scheduled (daily/weekly digest). Channels: webhook, email, slack, hubspot. Execution modes: direct (fast, deterministic) or agent (LLM-powered). Behavior: - Each call creates a new automation — even if name/config matches an existing one. - Once enabled, the automation starts firing on real events: per_interview sends on every completed conversation going forward; scheduled sends a real message on the configured cadence (daily/weekly). - Webhook URLs are validated. For HubSpot, the workspace's HubSpot connection is required — errors with "Could not resolve HubSpot portal ID — please reconnect HubSpot" if not connected. - Errors when the perspective is not found or you do not have access. When to use this tool: - The user wants ongoing notifications on every completed conversation (per_interview). - Building a daily/weekly digest delivered to Slack, email, HubSpot, or a webhook (scheduled). When NOT to use this tool: - Trying a one-off send before going live — create the automation, then use automation_test (use override_email / override_webhook to avoid hitting real recipients). - Editing or toggling an existing automation — use automation_update. - Connecting Slack or HubSpot — use integration_manage first; the provider must be connected before slack/hubspot channels work. Example — per-conversation Slack notify: ``` { "perspective_id": "...", "automation": { "name": "Notify Slack", "trigger": { "type": "per_interview" }, "execution_mode": "agent", "channel": { "type": "composio", "delivery_config": { "provider": "slackbot", "tool_slug": "SLACKBOT_SEND_MESSAGE", "params": { "channel": "#research" }, "resource_id": "...", "resource_name": "..." } } } } ``` Typical flow: 1. integration_manage (operation: "list"/"connect") → ensure Slack / HubSpot is connected (only needed for those channels) 2. automation_create → create the automation 3. automation_test (with overrides) → verify delivery before relying on it

  Connector

• get_session_dossiers

  VaultCrux Memory Core

  Retrieve pre-synthesized per-session memory dossiers (typed: experience | fact | preference; with When/Involving/To-purpose metadata). Use for multi-session or preference-style questions where stitching across conversations is the bottleneck — the dossier already summarises each session's key events. Two modes: mode='search' with a query (BM25-ish ranking over summary+purpose, optional type_filter), or mode='list' returns the tenant's most-recent dossiers chronologically. Tenants without FEATURE_SESSION_DOSSIERS enabled return an empty list (no error).

  Connector

• automation_update

  Perspective AI

  Updates fields on an existing automation. Pass a partial updates object with only the fields you want to change; omitted fields are preserved. Toggling enabled or changing schedule/channel/condition takes effect on the next scheduled run. Behavior: - Saves the change to the same automation record. Scheduled automations with an active workflow are restarted on update so the next run picks up the latest config. - Errors when the perspective or automation is not found, or you do not have access. - Webhook URLs in updates are validated. For HubSpot, the workspace's HubSpot connection is re-checked — errors with "Could not resolve HubSpot portal ID — please reconnect HubSpot" if disconnected. - For scheduled automations: changes to channel, condition, execution mode, instruction, or message template apply starting from the next run, not the one currently in flight. When to use this tool: - Toggling enabled on or off (also pauses/resumes scheduled sends). - Changing schedule, channel, condition, instruction, or message_template on a live automation. When NOT to use this tool: - Removing the automation entirely — use automation_delete. - Verifying a config change actually delivers — follow up with automation_test. - Listing what's configured — use automation_list.

  Connector

• list_editions

  Tripitaka MCP (hosted)

  List the translation editions available, with coverage stats. 💡 **Use this tool when:** - Before calling `compare_translations` or `get_sutta(edition=...)`, so you know which edition values are valid and worth comparing. - The user asks which editions are loaded in the DB. 🔍 **Filtering:** Filtered by the server's `TRIPITAKA_ENABLED_LANGUAGES` — when Thai is disabled the list is empty. Only enabled languages are returned. ⚠️ **Current state:** the DB mostly holds Pāli (default from SuttaCentral bilara) and English (Sujato). Thai editions (`dhiranandi`, `jayasaro`, `mbu`, `royal`) aren't indexed yet — the list returns empty until they're loaded. Returns: List of edition objects, each containing: - edition: edition code, e.g. "sujato", "dhiranandi", "mbu" - translator: translator's name - language: ISO code ("pi", "en", "th") - segment_count: how many segments have a translation in this edition - sutta_count: how many suttas have a translation.

  Connector

• list_structure

  Tripitaka MCP (hosted)

  Show the structure of all three pitakas with coverage statistics. 💡 **Use this tool when:** - The user asks for an overview of the Tipiṭaka (what's in it / which collections). - You need to check coverage before promising a search will find something — `segment_count > 0` is the active-loaded signal. - Verifying scope when compiling an artifact. 📊 **Current state (v1.1+, at parity with SuttaCentral bilara-data):** - **Sutta Piṭaka** complete: DN 37, MN 155, SN 1,829, AN 1,419, KN 2,351 sections (~284,702 segments) — Pāli + Sujato EN - **Vinaya Piṭaka** complete: Bhikkhu Vibhaṅga 222, Bhikkhunī Vibhaṅga 127, Khandhaka 22, Parivāra 51 + Pātimokkha 2 (~71,557 segments) — Pāli + Brahmali EN - **Abhidhamma Piṭaka** complete: 7 books (ds, vb, dt, pp, kv, ya, patthana) ~88,414 segments — Pāli only (bilara has no English for any Abhidhamma book) - **Total ~444,673 segments** in the DB ⚠️ **Known quirks:** - The schema carries duplicate legacy + SC-modern codes side by side: - Vinaya: `vin-v/vin-m/vin-c/vin-p` (legacy, segment_count = 0) alongside `pli-tv-bu-vb/pli-tv-bi-vb/pli-tv-kd/pli-tv-pvr` (active, populated). - Abhidhamma: `ym/pt` (legacy = 0) alongside `ya/patthana` (active). - **Always pick the code with `segment_count > 0`** — the others are metadata placeholders from an older migration. 🌐 **Languages:** Returns Pāli + Thai + English labels regardless of enabled set (these are metadata, not segment text). Text content follows ENABLED_LANGUAGES. Thai translations aren't loaded yet — Thai users can fall back to the cross_reference 84000.org link. Returns: Hierarchical structure: - pitakas{vinaya/sutta/abhidhamma} → nikayas[] - Each nikaya: code, name (3 languages), sutta_count, segment_count.

  Connector

• buy_domain_mpp

  instadomain

  Start the purchase flow for a domain via Stripe's Machine Payments Protocol (MPP). MPP lets autonomous agents pay with fiat (cards, Link) or stablecoins via Shared Payment Tokens, with no browser checkout. Two-step flow: Step 1: Call this tool to get an order_id and pay_url. Step 2: Make an HTTP GET request to the pay_url with an MPP-enabled HTTP client. The server responds with HTTP 402 + WWW-Authenticate; the client creates a Shared Payment Token and retries with an Authorization header. The server charges the SPT through Stripe and kicks off domain registration. After payment, call get_domain_status(order_id) to poll until complete. Requires: An MPP-compatible client configured to mint SPTs against the server's advertised Stripe Business Network profile. Args: domain: The domain to purchase (e.g. "coolstartup.com"). first_name: Registrant's first name. last_name: Registrant's last name. email: Registrant's email address. address1: Registrant's street address. city: Registrant's city. state: Registrant's state or province. postal_code: Registrant's postal/zip code. country: 2-letter ISO country code. phone: Phone number in format +1.5551234567. org_name: Organization name (optional). Returns: Dict with order_id, pay_url (full URL), price_cents, price_display, network_id, and payment_method_types.

  Connector

• list_webhooks

  Trillboards DOOH Advertising

  List all webhook subscriptions for the partner account. WHEN TO USE: - Viewing all configured webhooks - Auditing webhook subscriptions - Finding a webhook to update or delete RETURNS: - webhooks: Array of webhook objects with: - webhook_id: Unique identifier - url: Endpoint URL - events: Subscribed events - enabled: Whether webhook is active - created_at: Creation timestamp - last_delivery: Last successful delivery time EXAMPLE: User: "Show me all my webhooks" list_webhooks({})

  Connector

• gcpinspect

  InsideOut (Riley)

  INSPECTION: Inspect GCP infrastructure for a deployed project ⚠️ **PREREQUISITE**: This tool requires a prior deployment ATTEMPT (successful or failed). Check convostatus for hasDeployAttempt=true before calling. Works even after failed deploys to inspect orphaned resources. Inspect deployed GCP resources after a deployment attempt. Use this tool when the user asks about the status or details of their deployed GCP infrastructure. It fetches temporary read-only credentials securely and queries the GCP API directly. RESPONSE TIERS (default is summary for token efficiency): - Summary (default): Key fields only (~500 tokens). Set detail=false, raw=false or omit both. - Detail: Full metadata for a specific resource. Set detail=true + resource filter. - Raw: Complete unprocessed API response. Set raw=true. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: apigateway, bastion, billing, cloudarmor, cloudbuild, cloudcdn, cloudfunctions, cloudkms, cloudlogging, cloudmonitoring, cloudrun, cloudsql, compute, firestore, gcs, gke, identityplatform, loadbalancer, memorystore, pubsub, secretmanager, vertexai, vpc For a specific service's actions, call with action="list-actions". METRICS: Use list-metrics to see available Cloud Monitoring metrics for any service (no credentials needed — progressive disclosure). Use get-metrics to retrieve time-series data. Optional filters JSON: {"hours":6,"period":300}. Label breakdowns: Cloud Functions (by status), Load Balancer/API Gateway (by response_code_class), Cloud CDN (by cache_result). Secret Manager get-metrics returns operational health (version count, replication, create time) — no time-series. Bastion is an alias for Compute Engine metrics (SSH connection count not available as a GCP metric). BILLING: Use service=billing to inspect GCP billing. Actions: get-billing-info (check if billing enabled, which billing account), get-budgets (list budget alerts for the project — auto-fetches billing account). Requires roles/billing.viewer IAM role. Required IAM roles: Monitoring Viewer (roles/monitoring.viewer) for metrics, Secret Manager Viewer (roles/secretmanager.viewer) for secret health, Billing Viewer (roles/billing.viewer) for billing. EXAMPLES: - gcpinspect(session_id=..., service="compute", action="list-instances") - gcpinspect(session_id=..., service="gke", action="list-clusters") - gcpinspect(session_id=..., service="cloudsql", action="get-metrics", filters="{\"hours\":6}") - gcpinspect(session_id=..., service="billing", action="get-billing-info")

  Connector

• list_available_capabilities

  Whatcanido — MCP Server for Service Businesses

  Return a compact roster of every capability with at least one enabled provider, grouped by category, with the best current conformance per capability. Use this as a self-introspection step: call once at the start of a task to know what is and isn't available, before deciding whether to attempt or to tell the user 'this isn't possible here'.

  Connector

• automation_delete

  Perspective AI

  Permanently deletes an automation. Pauses any scheduled sends first, then removes the automation. Behavior: - DESTRUCTIVE and irreversible — the automation cannot be recovered. No undo. Confirm with the user before calling. - Errors when the perspective or automation is not found, or you do not have access. Deleting an already-deleted automation errors as well. - If pausing the scheduled sender fails, the deletion is aborted and you'll get success: false with "Failed to stop running workflow. Please try again." — the automation stays intact in that case. When to use this tool: - The user explicitly asked to remove an automation and confirmed. - Cleaning up a misconfigured automation that automation_test repeatedly fails on. When NOT to use this tool: - The user just wants to pause it temporarily — use automation_update with { enabled: false } instead. - You're not sure which automation_id is correct — confirm via automation_list first.

  Connector

• create_session

  sncro

  Create a new sncro session. Returns a session key and secret. Args: project_key: The project key from CLAUDE.md (registered at sncro.net) git_user: The current git username (for guest access control). If omitted or empty, the call is treated as a guest session — allowed only when the project owner has "Allow guest access" enabled. brief: If True, skip the first-run briefing (tool list, tips, mobile notes) and return a compact response. Pass this on the second and subsequent create_session calls in the same conversation, once you already know how to use the tools. After calling this, tell the user to paste the enable_url in their browser. Then use the returned session_key and session_secret with all other sncro tools. If no project key is available: tell the user to go to https://www.sncro.net/projects to register their project and get a key. It takes 30 seconds — sign in with GitHub, click "+ Add project", enter the domain, and copy the project key into CLAUDE.md.

  Connector

• buy_pro

  moltdj

  Buy a Pro subscription for $10 USDC (30 days). Requires authentication. This endpoint returns HTTP 402 with x402 payment instructions. Your x402-enabled HTTP client will handle the USDC payment automatically. After payment, you get Pro tier: 10 tracks/day, 2 episodes/week, analytics, and more.

  Connector

• buy_studio

  moltdj

  Buy a Studio subscription for $25 USDC (30 days). Requires authentication. This endpoint returns HTTP 402 with x402 payment instructions. Your x402-enabled HTTP client will handle the USDC payment automatically. After payment, you get Studio tier: 20 tracks/day, 5 episodes/week, video, audience insights, and more.

  Connector

• agents_simulate_inbound

  dialogbrain

  Replay an inbound message on a thread through the real trigger pipeline and return what would have happened. The router auto-picks the winning enabled agent + trigger by priority/specificity (same logic as production). By default send_mode='draft' so no real message is sent; pass send_mode='auto' on a test account to let the matched agent actually deliver (drafts get overwritten by the next draft, so 'auto' is the only way to verify Telegram/email delivery end-to-end). Use to verify routing for a thread: which agent answers, which trigger wins, or — when nothing matches — the structured skip reason. Pass blockchain_tx_data instead of message_text to simulate a blockchain:transfer event on the thread. Returns: {matched: true, matched_agent: {id, name, execution_mode}, matched_trigger: {id, trigger_type, conditions, specificity_score}, routing_reason, response_text, messages[], execution_mode, send_mode, model_used, tokens_input, tokens_output, latency_ms, rag_queries_made, rag_results_used} on a hit, or {matched: false, skip_reason, simulator_warnings} on a miss.

  Connector

• buy_domain

  instadomain

  Start the purchase flow for an available domain via Stripe checkout. IMPORTANT: Before calling this tool, you MUST first call check_domain to get the price, then clearly show the user the price and get their explicit confirmation before proceeding. Never call buy_domain without the user seeing and approving the price first. The registrant contact details are required because the domain will be registered in the buyer's name (they become the legal owner). WHOIS privacy is enabled by default, so these details are not publicly visible. Creates a Stripe checkout session. IMPORTANT: After this tool returns, you MUST open the checkout_url by running the shell command `open "<checkout_url>"` (macOS/Linux) so the payment page launches automatically in the user's default browser. Do NOT paste the URL as a link. Tell the user the page has been opened and they can complete payment there. Args: domain: The domain to purchase (e.g. "coolstartup.com"). first_name: Registrant's first name. last_name: Registrant's last name. email: Registrant's email address. address1: Registrant's street address. city: Registrant's city. state: Registrant's state or province. postal_code: Registrant's postal/zip code. country: 2-letter ISO country code (e.g. "US", "GB", "DE"). phone: Phone number in format +1.5551234567. org_name: Organization name (optional, leave empty for individuals). Returns: Dict with order_id, checkout_url, price_cents, and price_display.

  Connector

• gcpinspect

  InsideOut (Riley)

  INSPECTION: Inspect GCP infrastructure for a deployed project ⚠️ **PREREQUISITE**: This tool requires a prior deployment ATTEMPT (successful or failed). Check convostatus for hasDeployAttempt=true before calling. Works even after failed deploys to inspect orphaned resources. Inspect deployed GCP resources after a deployment attempt. Use this tool when the user asks about the status or details of their deployed GCP infrastructure. It fetches temporary read-only credentials securely and queries the GCP API directly. RESPONSE TIERS (default is summary for token efficiency): - Summary (default): Key fields only (~500 tokens). Set detail=false, raw=false or omit both. - Detail: Full metadata for a specific resource. Set detail=true + resource filter. - Raw: Complete unprocessed API response. Set raw=true. REQUIRES: session_id from convoopen response (format: sess_v2_...). Supported services: apigateway, bastion, billing, cloudarmor, cloudbuild, cloudcdn, cloudfunctions, cloudkms, cloudlogging, cloudmonitoring, cloudrun, cloudsql, compute, firestore, gcs, gke, identityplatform, loadbalancer, memorystore, pubsub, secretmanager, vertexai, vpc For a specific service's actions, call with action="list-actions". METRICS: Use list-metrics to see available Cloud Monitoring metrics for any service (no credentials needed — progressive disclosure). Use get-metrics to retrieve time-series data. Optional filters JSON: {"hours":6,"period":300}. Label breakdowns: Cloud Functions (by status), Load Balancer/API Gateway (by response_code_class), Cloud CDN (by cache_result). Secret Manager get-metrics returns operational health (version count, replication, create time) — no time-series. Bastion is an alias for Compute Engine metrics (SSH connection count not available as a GCP metric). BILLING: Use service=billing to inspect GCP billing. Actions: get-billing-info (check if billing enabled, which billing account), get-budgets (list budget alerts for the project — auto-fetches billing account). Requires roles/billing.viewer IAM role. Required IAM roles: Monitoring Viewer (roles/monitoring.viewer) for metrics, Secret Manager Viewer (roles/secretmanager.viewer) for secret health, Billing Viewer (roles/billing.viewer) for billing. EXAMPLES: - gcpinspect(session_id=..., service="compute", action="list-instances") - gcpinspect(session_id=..., service="gke", action="list-clusters") - gcpinspect(session_id=..., service="cloudsql", action="get-metrics", filters="{\"hours\":6}") - gcpinspect(session_id=..., service="billing", action="get-billing-info")

  Connector