connect any compatible https mcp

How it works #

The widget authenticates to MyAISE. MyAISE holds the connection credential server-side, discovers the MCP catalog, and performs live calls within a serialized conversation turn.

 Browser             MyAISE cloud             Your MCP server
+-----------+        +-----------------------+        +-------------------+
| assistant |------->| discovery, tool policy|------->| Streamable HTTP   |
| widget    | session| confirm + verification|  MCP   | tools/resources   |
+-----------+        +-----------------------+        +-------------------+

• Customer-specific product semantics come from that team's published Solution library, not from runtime provider code.
• Connections and snapshots are isolated by credential/connection, never endpoint URL alone.
• Credentials, confirmation tokens, and unredacted tool payloads never reach the browser.

Quick start #

1. Expose one remotely reachable HTTPS MCP endpoint.
2. Implement initialize, accept notifications/initialized, and advertise the capabilities you actually support.
3. Implement paginated tools/list. Resources and templates are optional and use their standard list methods and opaque cursors.
4. Describe every tool with an exact case-sensitive name, inputSchema, and standard MCP annotations.
5. Return valid JSON-RPC as JSON or Streamable HTTP SSE. Preserve the negotiated Mcp-Session-Id until expiry or teardown.
6. Use no authentication, a bearer credential, or standard MCP OAuth discovery. MyAISE omits Authorization when the connection has no credential.
7. Connect the endpoint in the Assist console and test reads before manually testing writes in a sandbox.

Streamable HTTP lifecycle #

MyAISE follows the MCP 2025-11-25 initialization and Streamable HTTP lifecycle, including session headers and both JSON and SSE response forms.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": { "name": "myaise", "version": "1" }
  }
}

• After a successful response, MyAISE sends notifications/initialized and reuses the returned session id.
• Session expiry causes one fresh initialization and retry where safe. Explicit teardown uses the transport's standard HTTP semantics.
• The previous stateless JSON request/response shape remains a temporary protocol-detected legacy adapter. It is never selected by customer name.
• Redirects and private-network destinations are rejected by the outbound SSRF policy.

Complete discovery #

List responses may include an opaque nextCursor. MyAISE follows it without parsing or rewriting it and commits a snapshot only after the full discovery pass.

Repeated cursors, more than 100 pages, more than 5,000 entries in one collection, malformed entries, byte-limit violations, and timeouts stop the refresh. The previous complete snapshot remains available with a degraded marker; a partial catalog never replaces it.

Tool metadata and safety #

{
  "name": "records.get",
  "title": "Get record",
  "description": "Read one record by id.",
  "inputSchema": {
    "type": "object",
    "properties": { "id": { "type": "string" } },
    "required": ["id"],
    "additionalProperties": false
  },
  "annotations": {
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  }
}

• An unconflicted readOnlyHint: true is positive read evidence.
• An explicit write, missing metadata, or conflicting annotations is confirmation-gated.
• Tool-name suffixes, casing changes, underscore/dot aliases, dry-run flags, and validate_only never grant read authority.
• Authorization and dispatch use the exact case-sensitive live name. Similar names may be shown to an operator as repair suggestions but are never executed automatically.
• Confirmation rechecks the exact name, schema, safety classification, and catalog fingerprint. Catalog drift expires the card.

For compatibility, a small documented set of historical read classes is recognized when standard annotations are absent. New servers should publish standard annotations.

Optional authorization #

Unauthenticated MCP servers work without special configuration. When a credential is configured, it is stored server-side and scoped to one connection.

• OAuth uses standard protected-resource metadata, authorization-server metadata, authorization-code + PKCE, and the MCP resource indicator.
• Scopes are discovered from metadata or challenges. If the server advertises none, MyAISE omits the scope parameter rather than inventing provider scopes.
• The grant is treated as an opaque connection scope. app_ref and account_ref are optional display labels, not authorization or cache keys.
• There is no mandatory identity or whoami tool. Your authorization server and MCP implementation remain responsible for tenant isolation.

Connect MyAISE #

In the Assist console, add the endpoint and choose no authentication, a server-side credential, or OAuth. Ordinary use requires no profile, sandbox, contract, or evaluation corpus.

The connection view reports negotiated protocol, health, discovered counts, refresh time, and one of: connected, cached/degraded, reauthorization required, incompatible, or unavailable. Optional diagnostics and sandbox probes live separately and never gate MyAISE releases.

Each end-user OAuth connection, handoff, and session has an isolated snapshot and cache. Two credentials for the same URL never share catalog state.

Running a live demo from your marketing site? When you push a grant server-side with POST /v1/customer_app/mcp_handoffs, pass viewer_session_id so the grant is bound to that prospect's viewer session — it then expires with the session and the AI SE acts as that demo user. See the website integration guide at /docs/api#website-integration.

Verify safely #

1. Verify initialize + initialized notification and session-header reuse.
2. Test JSON and SSE responses, pagination, an empty catalog, malformed responses, and session expiry.
3. Ask a live-data question and confirm only a positively classified read executes.
4. Ask for a change and confirm no tool call occurs before the exact confirmation card is accepted.
5. Interrupt a write after dispatch. Confirm MyAISE marks it indeterminate and performs only read-only reconciliation — the write is never repeated automatically.
6. Change a referenced schema and confirm pending cards and Solution workflow evidence become stale while unrelated catalog additions do not.

Questions? hello@myaise.com