logmein-mcp

logmein-mcp

MCP server for LogMeIn Rescue (remote support/screen-sharing platform).Exposes the Rescue API's session, chat log, note, and reporting methods asMCP tools.

Naming note: MSPbots' own integration is registered as "LogMeIn"(subjectCode=LOGMEIN); the vendor's current product name is "LogMeInRescue" (part of GoTo). This MCP covers exactly the 4 methods MSPbotsitself has configured (Report, Session, Chat, Note) — see APIReference below for where the full method catalog lives.

MSPbots Connector gives your AI clients one MCP URL to reach your entire MSP stack (RMM, PSA, documentation, security, finance), and gives you control over who can call which tool and a record of everything that was called.

Hosted service: connect.mspbots.ai · Free to use.

Why Connector

Quick start

1. Sign up at connect.mspbots.ai.
2. Connect your vendors. Pick from 150+ connectors and authorize each one on the vendor's own page, or bring your own API keys. No extra vendor accounts needed.
3. Set access. Create roles and decide which tools each role may call. Nothing is allowed until you allow it.
4. Add your MCP URL to your AI client. Copy the URL from your Connector dashboard into Claude, ChatGPT, Cursor, VS Code, Gemini, Codex, or any MCP-capable client.
5. Ask your AI to do real work, and watch every call appear in the audit log.

Features

Unified gateway

• One MCP URL for all your AI clients
• 150+ connectors across the MSP stack
• Custom MCP servers supported, free
• Authorization happens on each vendor's own page; the AI never sees passwords or tokens
• Bring your own credentials: use the vendor API keys you already have
• Multiple accounts per app; connect once, reuse across AI clients
• Tool search: finds the right action for the task
• One sign-in; vendor credentials are injected behind the scenes and OAuth tokens refresh automatically

Visibility

• Audit log for every tool call (who, which vendor, when)
• Usage dashboard: call volume, top vendors, error rate, per-user activity
• Export audit logs to CSV, or stream to Loki, Graylog, or LogScale (SIEM)
• Optional recording of tool arguments and result summaries (off by default, enabled per organization)

Control

• Per-role, per-tool allowlist, deny by default
• owner / admin / member roles
• SCIM provisioning with Entra ID, Okta, JumpCloud, and Google Workspace

Security

• Credentials encrypted one record at a time (AES-256-GCM, per-record key)
• AI clients authenticate with OAuth 2.1 + PKCE
• Vendor responses are scanned for prompt-injection patterns and returned as structured data. This is one layer of defense, not a guarantee against every attack.
• Static egress IP for customer firewall and API allowlisting

Pricing

Free.

Links: connect.mspbots.ai · mspbots.ai

Overview

• Stateless HTTP service. No credentials are ever persisted — each requestsupplies its own username/password via headers, used only for thelifetime of that single request.
• Supports concurrent requests; per-request credential isolation is done viaPython contextvars, not a global/shared client instance.
• Entry points: POST /mcp (MCP protocol) and GET /health (health check).
• Default port: 8080 (configurable via MCP_HTTP_PORT).

Authentication

The Rescue API is a classic ASP.NET session-cookie API: login.aspxauthenticates with an email/username + password and returns anASP.NET_SessionId cookie, which every subsequent call relies on — thereis no bearer token or API key. To keep this server fully stateless (nosession cached across MCP calls), it performs a fresh login on everysingle tool invocation, then makes the real API call(s) on that sameshort-lived httpx.AsyncClient (and therefore the same cookie) beforediscarding it entirely.

HEADER Authorization Parameters

Missing either header returns 401:

{
  "error": "Missing credentials",
  "message": "This server requires the X-LogMeIn-Username and X-LogMeIn-Password headers",
  "required_headers": ["X-LogMeIn-Username", "X-LogMeIn-Password"],
  "optional_headers": []
}

An invalid username/password surfaces as a tool-level structured error({"error":{"code":"unauthorized","message":"login failed: INVALID","retryable":false}}),not an HTTP-level error, since the failure only becomes known after thelogin step inside the tool call. See Error Handling below for thefull error-code vocabulary.

Environment Variables

MCP Endpoint

• POST /mcp — MCP protocol (streamable HTTP transport)
• GET /health — health check, returns {"status": "ok"} (pure local probe, does not depend on the LogMeIn Rescue API being reachable)

Tool List

All 4 tools are read-only (readOnlyHint=True); there are no write/delete tools in this service.

On success, responses are the vendor's raw pipe-delimited text (startingwith OK or ERROR, never JSON), returned as-is — consistent with howthe Rescue API itself replies — capped at 20,000 characters (truncatedwith a trailing notice if the vendor's response is larger).

Error Handling

Transport/protocol-level failures (network errors, HTTP-level errors,login failures, invalid report parameters) are returned as a structuredJSON error envelope instead of the raw vendor text:

{"error": {"code": "unauthorized", "message": "login failed: INVALID", "retryable": false}}

code is one of a fixed vocabulary: not_configured, unauthorized,not_found, invalid_argument, rate_limited, upstream_error.retryable tells the caller whether retrying the same call mightsucceed (true for rate_limited/upstream_error, false otherwise).Network errors and HTTP 429/5xx responses from the vendor areretried automatically (up to 3 attempts, capped exponential backoff,respecting Retry-After) before surfacing as upstream_error/rate_limited.

A business-level ERROR body from the vendor's own API (e.g. an unknownsession ID passed to logmein_get_chat/logmein_get_note) is notan error envelope — it is returned as-is in the raw text result, exactlyas the vendor's API replies, since that's a normal (if empty/negative)query outcome rather than a transport failure.

Test Example

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-LogMeIn-Username: [email protected]" \
  -H "X-LogMeIn-Password: <your-password>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "logmein_get_session",
      "arguments": {"node": "57554", "noderef": "NODE"}
    }
  }'

Live-verified (2026-07-30) against a real Rescue account(ThrottleNet, Inc): logmein_get_session (node = the account's ownAccountID) returned OK with the session table header (no activesessions at test time — a valid empty result, not an error);logmein_get_report with report_area=2 (Login report) chainedsetReportArea → getReport_v2 and returned OK with the Login report'scolumn header; logmein_get_chat and logmein_get_note were called witha non-existent session ID and correctly returned ERROR (the vendor'sdocumented response for an unknown session — not an auth failure,confirming the login pipeline works). A separate handshake using adeliberately wrong password correctly surfaced Error: LogMeIn Rescue API error: login failed: INVALID.

API Reference

• Overview (public, no login required): https://support.logmein.com/rescue/help/rescue-api-reference-guide-articles
• Method-specific pages used by this server:
  • Login: https://support.logmein.com/rescue/help/API_map_account_info
  • Session Management (getSession_v3): https://support.logmein.com/rescue/help/API_map_session_management
  • Reporting (getChat, getNote, getReport_v2, setReportArea,setReportDate_v2): https://support.logmein.com/rescue/help/API_map_reporting

Known Gaps

• Scope is exactly MSPbots' 4 configured endpoints (Report, Session,Chat, Note), not the vendor's full API surface — the Rescue API alsoexposes Account Management, CRM integration, and ReportAreaconfiguration methods (date/time/delimiter/output format setters) thatMSPbots does not use; those are out of scope here.
• The authcode field MSPbots also stores for this integration is notused by this server. The Rescue API documents authcode as analternative to logging in (mainly for the Session Management methods;Reporting methods require login regardless of authcode). Live testingshowed that the provided authcode value was rejected(INVALID_SECRETAUTHCODE) when passed, while plainusername+password login worked correctly and was sufficient for all 4endpoints — matching MSPbots' own stored config, which has no authtemplate defined beyond credentials. This server therefore reliessolely on the login-cookie flow.
• The vendor rate-limits getReport_v2 to once per 60 seconds peraccount (documented). Calling logmein_get_report more frequentlythan that will likely fail at the vendor side.
• node/nodetype defaults for logmein_get_report (-2 /EXTERNALROOT, meaning "the whole External Technicians tree") werechosen to match a whole-account report, mirroring MSPbots' generic"Logmein Report" endpoint naming (MSPbots' own stored config has nospecific node/nodetype recorded). Callers needing a report scoped to asingle technician or group should override both parameters.