Bridging IFTTT to Your Local AI Assistant with an MCP Proxy

Amazon Quick, an AI assistant, gained the ability to control IFTTT automations through a custom proxy built by a developer. The proxy bridges the gap between Quick's stdio-based MCP transport and IFTTT's Streamable HTTP transport, handling OAuth authentication and response format conversion. The developer guided the architecture while Quick wrote the 500-line Node.js proxy code.

So IFTTT shipped MCP support https://ifttt.com/mcp . That means you can control your automations, list applets, edit triggers, run queries... all through the Model Context Protocol. In theory, any MCP-capable AI assistant can now talk directly to IFTTT. In practice? Not quite. Right now, IFTTT officially supports https://help.ifttt.com/hc/en-us/articles/47690989390619-Using-IFTTT-with-AI-Assistants only Claude and ChatGPT as AI assistant integrations. You go to Settings → Connectors in Claude, or Settings → Connected Apps in ChatGPT, and IFTTT is right there. But if your AI assistant isn't on that short list? You're on your own. Here's the situation. My AI assistant Amazon Quick https://aws.amazon.com/quick/ speaks MCP via stdio . It launches a local process and communicates over stdin/stdout using JSON-RPC. Simple. Clean. Works great for local tools. IFTTT's MCP server lives at https://ifttt.com/mcp and uses Streamable HTTP transport. It expects authenticated HTTP POST requests and responds with either JSON or Server-Sent Events streams. Two completely different transport layers. They don't talk to each other. So what do you do? You build a proxy. Well... "you" build a proxy. In my case, I described the problem to Amazon Quick my AI assistant and it wrote the entire proxy for me. All ~500 lines of it. I guided the architecture, debugged alongside it, and steered the fixes when things broke. But the actual code? That was all Quick guiding Kiro https://kiro.dev/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253 . This whole post is really about what happens when you pair an AI coding assistant with a well-defined integration problem. The proxy is a ~500-line Node.js script that sits between them: ┌────────────┐ stdio ┌───────────┐ HTTPS ┌──────────┐ │ │ JSON-RPC │ │ POST │ │ │ Amazon │ ────────▶ │ MCP │ ──────▶ │ IFTTT │ │ Quick │ │ Proxy │ │ MCP │ │ │ ◀──────── │ Node │ ◀────── │ Remote │ │ │ JSON-RPC │ │ SSE/JSON│ │ └────────────┘ └─────┬─────┘ └──────────┘ local │ remote ┌──────┴──────┐ │ OAuth 2.1 │ │ PKCE + Auto │ │ Refresh │ └─────────────┘ It reads JSON-RPC messages from stdin, forwards them as authenticated HTTPS requests to IFTTT, handles whatever response format comes back direct JSON or SSE stream , and writes the response to stdout for Quick to consume. The full flow: Sounds straightforward? It mostly is. But two gotchas took me while to debug. Let me walk you through them. First things first. IFTTT requires OAuth authentication. The proxy has an --auth mode that handles the entire flow: js async function authenticate { const codeVerifier = generateCodeVerifier ; const codeChallenge = generateCodeChallenge codeVerifier ; const state = generateState ; const authParams = new URLSearchParams { client id: CLIENT ID, code challenge: codeChallenge, code challenge method: 'S256', redirect uri: REDIRECT URI, resource: 'https://ifttt.com/mcp', response type: 'code', scope: 'mcp', state: state, } ; // Opens browser, starts local callback server on port 3118 // Exchanges code for token using PKCE verifier // Saves token to ~/.quickwork/ifttt-token.json } Run node index.js --auth once, authenticate in your browser, and the token gets saved locally. After that, the proxy handles refresh automatically. You never think about auth again. The token management is simple but important: function isTokenExpired tokenData { if tokenData || tokenData.access token return true; if tokenData.expires in return false; const expiresAt = tokenData.obtained at + tokenData.expires in 1000 ; return Date.now expiresAt - 60000; // 1 minute buffer } That 60-second buffer matters. You don't want a request to fail because the token expires mid-flight. So here's where it got interesting. My first version of the proxy was dead simple. Read from stdin, POST to IFTTT, buffer the response, write to stdout. Classic request/response. It worked great for tools/list . IFTTT returned a nice 200 OK with a JSON body listing all available tools. I was feeling good. Then I called my applets . Nothing came back. No error. No response. Just... silence. After adding some debug logging, I discovered IFTTT was returning HTTP 202 Accepted with an empty body . The actual response? It was coming back as a Server-Sent Events stream. But my buffered HTTP client was already done. It saw the empty body, closed the connection, and moved on. The fix is a streaming-aware HTTP client that checks the Content-Type header: function httpsStreamingRequest url, options, body, timeoutMs = 60000 { return new Promise resolve, reject = { const req = https.request reqOptions, res = { const contentType = res.headers 'content-type' || ''; const isSSE = contentType.includes 'text/event-stream' ; if isSSE { // Keep the connection open, collect SSE events let sseBuffer = ''; res.setEncoding 'utf8' ; res.on 'data', chunk = { sseBuffer += chunk; } ; res.on 'end', = { resolve { status: res.statusCode, isSSE: true, events: parseSSEBody sseBuffer , } ; } ; } else { // Standard buffered response let data = ''; res.on 'data', chunk = { data += chunk; } ; res.on 'end', = { resolve { status: res.statusCode, isSSE: false, body: data } ; } ; } } ; req.setTimeout timeoutMs, = { req.destroy new Error Request timed out after ${timeoutMs}ms ; } ; if body req.write body ; req.end ; } ; } The SSE parser itself is straightforward. Events are separated by double newlines, data lines start with data: : js function parseSSEBody body { const events = ; const blocks = body.split '\n\n' ; for const block of blocks { let eventData = ''; for const line of block.split '\n' { if line.startsWith 'data: ' { eventData += line.substring 6 ; } else if line.startsWith 'data:' { eventData += line.substring 5 ; } } if eventData { try { events.push JSON.parse eventData ; } catch e {} } } return events; } After this fix, my applets worked beautifully. IFTTT returned 12 applets, all properly structured. I was back to feeling good. For about 10 minutes. So the proxy was getting responses. IFTTT was sending back data. But Amazon Quick was still showing... nothing. Or more precisely, it was throwing a vague "Tool execution failed" error. I pulled the raw JSON-RPC response to see what IFTTT was actually sending: { "jsonrpc": "2.0", "id": 1, "result": { "content": , "isError": false, "structuredContent": { "applets": ... } } } See it? The content array is empty . The actual data is in structuredContent . According to the MCP spec, tool results go in the content array as TextContent or ImageContent objects. That's what Amazon Quick reads. IFTTT decided to put their data in a custom structuredContent field instead, leaving content as an empty array. The fix is a response transformer that runs before writing to stdout: function transformToolResponse jsonRpcResponse { if jsonRpcResponse || jsonRpcResponse.result return jsonRpcResponse; const result = jsonRpcResponse.result; if result.structuredContent && result.content || result.content.length === 0 { result.content = { type: 'text', text: JSON.stringify result.structuredContent, null, 2 , }, ; } return jsonRpcResponse; } 12 lines. That's all it took. But finding the problem? That was the hard part. With both gotchas solved, the main proxy loop is clean: js async function proxyMcpRequest jsonRpcMessage { const token = await getValidToken ; const headers = { 'Content-Type': 'application/json', 'Authorization': Bearer ${token} , 'Accept': 'application/json, text/event-stream', }; if mcpSessionId { headers 'Mcp-Session-Id' = mcpSessionId; } let response = await httpsStreamingRequest IFTTT MCP URL, { method: 'POST', headers }, JSON.stringify jsonRpcMessage ; // Capture session ID for subsequent requests if response.sessionId { mcpSessionId = response.sessionId; } // Handle 401 - try token refresh if response.status === 401 { cachedToken = await refreshToken cachedToken ; headers 'Authorization' = Bearer ${cachedToken.access token} ; response = await httpsStreamingRequest IFTTT MCP URL, { method: 'POST', headers }, JSON.stringify jsonRpcMessage ; } return response; } The Accept: application/json, text/event-stream header is important. It tells IFTTT "I can handle both formats." Without it, you might not get the SSE stream at all. The proxy registers itself in the MCP config as a simple stdio server: { "mcpServers": { "ifttt": { "command": "node", "args": "/path/to/ifttt-mcp-proxy/index.js" } } } That's it. Amazon Quick launches the process, pipes JSON-RPC to stdin, reads responses from stdout. The proxy handles everything in between: auth, streaming, format translation, token refresh. With this proxy running, I can do all of this from my AI assistant using natural language: No browser. No IFTTT web UI. Just conversational access to my entire automation setup. A few takeaways if you're building something similar: The MCP spec has transport flexibility. Stdio and Streamable HTTP are both valid, but they don't interoperate automatically. If you're connecting a stdio client to an HTTP server, you need a proxy. If you're working with MCP on AWS, Amazon Bedrock Agents https://aws.amazon.com/bedrock/agents/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253 supports MCP servers natively for remote tool use... so you might not need a custom proxy if you're already in that ecosystem. SSE is sneaky. When a server returns 202 Accepted, your instinct is "okay, no content." But with SSE, the content is coming... just not the way you expect. Always check Content-Type before closing the connection. Not everyone implements the spec the same way. IFTTT's use of structuredContent instead of content is technically non-standard. Your proxy might need to normalize responses. OAuth 2.1 + PKCE is worth the complexity. No client secrets stored on disk, proper token rotation, and it works great for local tools that need to authenticate with remote services. AI assistants are shockingly good at integration plumbing. I didn't write a single line of this proxy by hand. I described the problem to Amazon Quick, and it generated the entire thing... the OAuth flow, the streaming HTTP client, the SSE parser, the response transformer. When something broke, I described the symptoms and it diagnosed and fixed the issue. The whole thing went from "IFTTT has MCP support" to "fully working native integration" in about an hour of back-and-forth conversation. That's the real story here. I've written more about this dynamic https://blog.technodrone.cloud/2026/05/your-coding-assistant-is-not-you.html between developer and AI coding assistant... it's a relationship worth understanding. Tools like the AWS Toolkit for AI Agents https://aws.amazon.com/developer/generative-ai/tools/?trk=d76afd77-bb62-46ac-b0a3-9dbf5ecde253 are making this kind of AI-assisted building the norm rather than the exception. The full proxy is about 500 lines of zero-dependency Node.js. No npm install needed. Just node and the built-in http , https , and crypto modules. The complete source code is on GitHub https://github.com/maishsk/ifttt-mcp-proxy . I would be very interested to hear your thoughts or comments, so if you've built something similar or found a different approach, ping me on X https://twitter.com/maishsk or LinkedIn https://www.linkedin.com/in/maishsk/ or feel free to leave a comment below. And if you're trying to connect other remote MCP servers to a local client... your mileage may vary, but the pattern should be the same.