Vercel AI SDK
Connect the Vercel AI SDK to Edison Watch using createMCPClient over streamable HTTP, keeping a stable session per conversation so data-leak protection holds across every turn.
The Vercel AI SDK connects to Edison with createMCPClient and its built-in HTTP transport. Your connection URL carries your API key, so no auth header is needed.
createMCPClient lives in the dedicated @ai-sdk/mcp package (the un-prefixed name), used alongside ai v7. Older code imported experimental_createMCPClient from ai; that alias still exists in @ai-sdk/mcp for back-compat, but prefer createMCPClient.
npm install ai @ai-sdk/mcp @ai-sdk/openaiimport { createMCPClient } from '@ai-sdk/mcp';
import { generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
const client = await createMCPClient({
transport: {
type: 'http',
url: process.env.EDISON_MCP_URL!,
},
});
try {
const tools = await client.tools();
const response = await generateText({
model: openai('gpt-5.6-luna'),
tools,
messages: [{ role: 'user', content: 'List my available tools.' }],
});
console.log(response.text);
} finally {
await client.close();
}Set EDISON_MCP_URL to your connection URL, e.g. https://mcp.edison.watch/mcp/<your-api-key>/?client=vercel-ai-sdk.
Recent AI SDK versions tighten redirect handling on MCP HTTP transports as an SSRF guard. Edison serves its endpoint directly (no redirect), so the default is fine - but if you front the gateway with something that 3xx-redirects, set redirect: 'follow' explicitly.
Keep a stable session across turns to preserve data-leak protection
Send a stable x-edison-conversation-id header on every turn of the same conversation. That header is what keeps Edison's data-leak protection intact across a multi-turn run: Edison tracks lethal-trifecta risk per session, so if each turn looks like a brand-new session, that protection resets - and a later turn can leak data that the accumulated risk should have blocked.
Hosted clients (Claude Code, VS Code) send it automatically. For a custom Vercel AI SDK app, set the header on the transport, keyed to your own conversation or thread id - and reuse that id on every turn:
const client = await createMCPClient({
transport: {
type: 'http',
url: process.env.EDISON_MCP_URL!,
headers: { 'x-edison-conversation-id': conversationId },
},
});Without a stable x-edison-conversation-id, each connection is treated as a fresh session that starts with empty risk state - so risk accumulated on an earlier turn won't be there to block a later exfiltration. The ?client= label is only a dashboard tag, not a session key. Use a unique id per conversation (a UUID is ideal); ids are scoped to your API key, so don't reuse one string for two different conversations.
Optional: the encrypted-secrets header
For servers with zero-knowledge-encrypted secrets, add headers to the transport, alongside x-edison-conversation-id:
const client = await createMCPClient({
transport: {
type: 'http',
url: process.env.EDISON_MCP_URL!,
headers: {
'x-edison-conversation-id': conversationId,
'x-edison-secret-key': process.env.EDISON_SECRET_KEY!,
},
},
});Microsoft Agent Framework
Connect a Microsoft Agent Framework agent to Edison Watch using MCPStreamableHTTPTool, keeping a stable session per conversation so data-leak protection holds across every turn.
Mastra
Connect a Mastra agent to Edison Watch using MCPClient over streamable HTTP, keeping a stable session per conversation so data-leak protection holds across every turn.