"How to summarize an email thread from Outlook and add it to a JIRA ticket" matching MCP tools:

• resolve

  DeskCrew

  Marks a ticket as resolved by setting its status to "closed" and recording an internal status-change note on the timeline. Reach for this once the issue has been handled and you want to close it out; it is idempotent (a no-op returning changed:false if the ticket is already closed) and reversible (a human can reopen it from the dashboard). Requires the "send" tier on this credential. The note is an internal audit entry only and is NOT delivered to the customer. [$0.06 draft / live when trusted]

  Connector

• add_to_cart

  PuroAir

  Add a product to a cart and return its checkout URL. IMPORTANT: this does NOT charge or place an order. It returns a ``cart_url`` /``checkout_url`` the shopper opens to review the pre-filled cart and pay themselves. Use for "add X to my cart" / "I want to buy X". For multiple items in one cart, use create_checkout. Verify availability with check_stock first — adding an out-of-stock item wastes the shopper's click-through. Args: sku: Product SKU (from list_products / search_products). quantity: How many (default 1).

  Connector

• open_diagnostic_intake

  Venture Insights Concept Diagnostic

  Show the founder an interactive intake form to start their FREE Concept Diagnostic. PREFER calling this over asking for the founder's name, email and concept one message at a time — it collects everything in one card and starts the diagnostic on submit. Call it as soon as the user wants to start, or check the viability of, an idea. The form is deliberately collected FRESH from the founder and starts BLANK — it does NOT accept or pre-populate remembered details, so the founder always enters (and sees) their own name, email and concept. This keeps the destination email accurate (one free diagnostic per founder, emailed to the address they type). Takes no arguments.

  Connector

• beycome_messages

  listing

  Post-publish stage — read the owner's buyer/inquiry messages (GET /messages). Read-only. Requires ``access_token``. Two modes: - Omit ``thread`` → lists the ~20 most recent conversations, newest first, one row per thread (the latest message in each). Useful fields per row: ``address``, ``prop_id``, ``prop_status``, ``msg`` (latest text), ``subject``, ``requested_by`` / ``email`` (the other party), ``thread``, ``read_msg`` ("0" = unread), ``attachments``, and ``message_type`` (``sender`` if the owner wrote the latest message, else ``receiver``). - Pass ``thread`` → returns that one conversation in full, oldest-first. Use the ``thread`` value from a list row to drill in. The list is not paginated here on purpose (the upstream ``page`` param is overloaded — it sets both page size and page number — so it is not exposed). Soft-deleted messages are dropped after paging, so a page may hold fewer than 20 rows; that is not an error. The payload is a bare array under ``data``. A 401 means the token is no longer valid (logged out, or very old) — re-authenticate with `beycome_signin_start` then `beycome_signin_verify`. To answer a message, use `beycome_reply_message`.

  Connector

• read_messages

  Almured

  Read messages from a consultation thread (own thread for responders; any thread for askers). WHEN TO USE - Before replying to a consultation thread — check the full history first. - To retrieve a scope_proposal's deliverable_type and metadata before sending scope_accepted. - To check if an extension_request was accepted. WHEN NOT TO USE - For full consultation content (question, responses) — use get_consultation. BEHAVIOR - Read-only. Auth required. Rate-limited to 60 req/min. - Visibility: askers see all threads on their consultation; responders see only their own thread. - Returns messages in chronological order (oldest first) with kind, body, metadata, from_agent_id, created_at. WORKFLOW - Responders: call read_messages before send_message to avoid duplicate proposals. - Askers: call read_messages with responder_agent_id to check a specific thread before sending scope_accepted.

  Connector

• register_buyer

  Kifly — Agentic Commerce & Payments

  Start registering a buyer so they can be recognized across future purchases without re-entering their details. Takes the buyer's email and name and always emails a 6-digit verification code — the response is `{ verification_required: true, buyer_profile_id }` whether the email is brand new or already has an account (so this call alone never reveals which). Ask the buyer to read you the code from their inbox, then call `verify_buyer` with the same email + code to get a `buyer_token` (`kfb_live_...`). **Store that token and pass it to `checkout` on every future order** — it pre-fills the buyer's email on the secure Stripe payment link. Safe to call for a buyer you believe is new; if they already have an account, verify_buyer still recovers it.

  Connector

• prepare_upload

  mcp

  Returns the LOCAL shell commands to package your working directory and upload it for an upload-mode deploy (no git, no PAT). Run them in the user's terminal, capture `source_token` from the upload's JSON response, then call deploy_app with that source_token (omit repo). The upload authenticates AUTOMATICALLY with a short-lived ticket minted from your MCP credential — NO API key needed in the command and nothing secret is printed (it falls back to needing $REDU_API_KEY only if minting is unavailable). Excludes node_modules/.git/.venv/build output and .env by default; honors .gitignore when is_git_repo=true.

  Connector

• subscribe_to_digest

  NetGrant — Canadian funding

  Subscribe the user to a FREE weekly email digest of Canadian funding opportunities matching a saved search (keywords + region). Each week they get 8–10 grants, newest first, falling back to the strongest current matches when nothing new landed. WHEN TO CALL: - The user, after a search, says yes to ongoing alerts, or asks to be notified / kept updated / emailed about new grants in their niche. - Only after they have explicitly agreed and given an email address — never subscribe someone proactively or without consent. HOW TO CALL: - Pre-fill "keywords" and "region" from the search you just ran so the digest matches what they were looking at (e.g. keywords "cleantech", region "BC"). Keep keywords to a short phrase, not a sentence. - "region" must be a province code (ON, BC, QC, AB, MB, SK, NS, NB, NL, PE, YT, NT, NU) or "Federal", or omit it for all-of-Canada. - Ask the user for their email; do not guess it. WHAT HAPPENS: - We send a one-click confirmation email (double opt-in). The user is NOT subscribed until they click it. Tell them to check their inbox. - If they were already confirmed, nothing is re-sent. Returns JSON: { ok: boolean, status: "confirmation_sent" | "already_subscribed" }. Confirm to the user what they signed up for (e.g. "weekly BC cleantech grants — check your email to confirm").

  Connector

• save_lead_message

  LinkedIn MCP Server (Salesbot)

  Store a generated outreach message on a CRM lead so it becomes durable context — e.g. an email, an email follow-up, a LinkedIn message or LI follow-up. The CRM is a 'sponge': you save the copy here, then read it back later (get_lead_context / list_lead_messages) and push it to the right channel via that channel's own tool/MCP (e.g. Smartlead for email). Does NOT send anything. Pass message_id to update an existing draft instead of creating a new one.

  Connector

• deep_search_emails

  mailopoly

  Search the user's COMPLETE email history by querying their connected mail providers live — Gmail, Outlook AND IMAP accounts (iCloud, Yahoo and other IMAP mailboxes) — reaching years beyond Mailopoly's indexed window, and including sent mail. This is also how you reach mail a free trial hasn't imported yet: the trial fully processes only recent mail, but the rest still lives in the user's mailbox and this tool finds it. Use it when search_emails returns few or no results, or when the question concerns emails older than the indexed history (search_emails responses include indexed_history_start). TIME BUDGET: the live crawl is deliberately capped server-side (typically 5-45 seconds for Gmail/Outlook, up to ~90 seconds when an IMAP account like iCloud/Yahoo is being walked) so this call ALWAYS returns a usable response before your own tool-call timeout — never refuse to run it just because an account is iCloud/IMAP; just tell the user you're searching their full history and it may take a moment. If the crawl hits its budget the response says so in `note` and `provider_error`, and the results returned are what was found in time. PAGINATION is by date, not offset: re-run with end_date set to a truncated provider's oldest_returned_date (from truncated_providers) to page deeper into history, or narrow with a sender/start_date/end_date window. start_date/end_date (YYYY-MM-DD) may span multiple years; omit both to search ALL history. Returned email_id values (some of the form 'gmail:<id>:<id>' or 'imap:<id>:<uid>') work directly in get_email.

  Connector

• start_agentic_launch

  Demand Discovery AI

  Kick off Day 1 of the 90-day Agentic Launch for a completed Demand Discovery Report. Demand Discovery surfaces named prospects matching the idea's ICP and DRAFTS the first outreach batch. It sends NOTHING automatically - the user reviews and sends from their hosted manage page. Outreach is drafted to come from Allison @ Demand Discovery, with replies routed to the user's own email. Call this after a paid report is "ready" and the user wants to act on it (e.g. "generate prospects", "start agentic launch", "find me people to talk to", "yes, do the outreach"). Pass the reportId, the user's email, and the alTriggerToken from the ready report if you have it. The email MUST be the address the user themselves provided earlier in this conversation (their report-delivery email) - if you don't have it in context, ask the user first; NEVER invent one or use a placeholder like user@example.com (placeholders are rejected and the launch will not start). The response returns a manageUrl where the user reviews/sends the drafted outreach (and can switch the sender to their own Gmail).

  Connector

• send_reply

  DeskCrew

  Sends a reply to the customer on an existing ticket and DELIVERS it immediately (customer email plus any connected chat threads) — this is not a draft and reaches the customer. Use this once you have a final, customer-ready answer; to instead queue a reply for human approval, use the draft tool. Requires a "send"-tier credential (a draft-tier credential is refused) and the ticket must already have a customer email on file or the call is rejected. [$0.06 draft / live when trusted]

  Connector

• add_to_cart

  Agentic Shelf

  Add a product to a cart and return its checkout URL. IMPORTANT: this does NOT charge or place an order. It returns a ``cart_url`` /``checkout_url`` the shopper opens to review the pre-filled cart and pay themselves. Use for "add X to my cart" / "I want to buy X". For multiple items in one cart, use create_checkout. Verify availability with check_stock first — adding an out-of-stock item wastes the shopper's click-through. Args: sku: Product SKU (from list_products / search_products). quantity: How many (default 1).

  Connector

• read_document

  Avocado AI

  Read the text contents of a document the user attached in chat (the URL from an 'Attached document URL: ...' line). PDF only; PPT/DOC attachments cannot be read, ask the user for the key content instead. Use this when you need to UNDERSTAND the document (summarize it, write a post about it, answer questions about it). Do NOT call it just to publish: publish_post takes the document URL directly without reading. Long documents are truncated to the first ~20,000 characters.

  Connector

• get_human_profile

  Human Pages

  Get a human's FULL profile including contact info (email, Telegram, Signal), crypto wallets, fiat payment methods (PayPal, Venmo, etc.), and social links. Requires agent_key from register_agent. Rate limited: PRO = 50/day. Alternative: $0.05 via x402. Use this before create_job_offer to see how to pay the human. The human_id comes from search_humans results.

  Connector

• save_comment

  linear

  Create or update a comment on a Linear issue, project, initiative, document, project milestone, or project/initiative status update. If `id` is provided, updates the existing comment; otherwise creates a new one. To start a new thread, pass `body` and exactly one of `issueId`, `projectId`, `initiativeId`, `documentId`, `milestoneId`, or `statusUpdateId` — comments on issues/projects/initiatives become top-level discussion threads; comments on documents/milestones become description comments. A status update holds a single thread, so a comment on an update that already has one is added to it as a reply. To reply to an existing thread, pass `parentId` and `body`; the reply inherits the parent's thread type, so no entity reference is needed. Parent reference fields are ignored when `id` or `parentId` is provided (`statusUpdateType` is rejected instead).

  Connector

• discovery_signup_verify

  Disco

  Complete Disco signup using an email verification code. Call this after discovery_signup returns {"status": "verification_required"}. The user receives a 6-digit code by email — pass it here along with the same email address used in discovery_signup. Returns an API key on success. Args: email: Email address used in the discovery_signup call. code: 6-digit verification code from the email.

  Connector

• register

  BorealHost

  Register a new agent account and get an API key. No authentication needed. The returned API key grants read+write access to all BorealHost API endpoints. Store it securely — it cannot be retrieved again. The key is automatically activated for this session — all subsequent tool calls will use it. No extra configuration needed. If no email is provided, a synthetic agent identity is created (agent-{uuid}@api.borealhost.ai). If an email is provided, it links to an existing or new human account. Args: name: Human-readable name for this API key (default: "Agent Key") email: Optional email to link to a human account Returns: {"api_key": "bh_...", "key_id": "uuid", "prefix": "bh_...", "scopes": ["read", "write"], "account_id": "uuid", "message": "Store this API key securely..."} Errors: RATE_LIMITED: Max 5 registrations per IP per hour VALIDATION_ERROR: Invalid email format

  Connector

• resolve_comment

  Dock

  Mark a comment thread resolved. Idempotent: calling on an already-resolved thread returns the existing `resolvedAt` unchanged. Fires `comment.resolved`. Pair with `unresolve_comment` for the reverse. Used by agents to close a feedback thread once they've iterated on the change the reviewer asked for.

  Connector

• create_account

  mcp

  Sign up for a brand-new sota.io account from inside Claude — no browser, no copy-paste. Two-step flow: STEP 1: Call with just `email`. We send a 6-digit confirmation code to that email. STEP 2: Call again with `email` + `code`. We verify, create the account on the Free tier (3 projects, EU-hosted, no credit card), generate a sota.io API key, and return it to you. After Step 2 you'll get back a key like `sota_…`. **Save it in a safe place** — you'll need it for any subsequent sota.io tool call in Claude (or you can use it with the sota CLI). It is shown ONCE and never recoverable. sota.io is an EU-native PaaS hosted in Germany — GDPR-compliant by default, no CLOUD Act exposure. Disposable / throwaway email addresses are not accepted; use a real address.

  Connector