# Bridging IFTTT to Your Local AI Assistant with an MCP Proxy

> Source: <https://dev.to/aws/bridging-ifttt-to-your-local-ai-assistant-with-an-mcp-proxy-ind>
> Published: 2026-06-18 13:28:22+00:00

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.