TRMNL's MCP beta has two setup paths. Verify the live one before it writes

TRMNL currently has two official instruction surfaces for connecting external AI clients, and they give different authentication guidance. The AI Agent help page, updated July 23, 2026, tells header-capable clients to send a bearer key to https://trmnl.com/mcp. The current default-branch copy of an official TRMNL agent-skill file, last changed May 12, 2026, at commit af30383b63604f2d23c5083e47596bda93da9fab, tells Claude Code, Cursor, Codex, Gemini, and generic clients to put the key in the URL query string.

The difference matters because TRMNL's MCP server is a write-capable public beta. It can change private-plugin markup and refresh data, while other tools can return screenshots, merge variables, and logs to the client. Before connecting operational content, use one disposable private plugin and one exact client version to verify the current instructions, credential handling, live tools, plugin identity, reversible write path, visual result, and revocation behavior.

Two official TRMNL sources now describe different connection paths

The July help page says MCP keys begin with ps_mcp_ and that each key is scoped to one plugin. Its Claude Code command sends the key in an Authorization bearer header to https://trmnl.com/mcp. The page documents external MCP powers for reading and writing markup, refreshing data, taking screenshots, viewing merge variables and logs, searching recipes, and consulting TRMNL's design documentation.

The same page makes an exception for Claude Desktop's custom connector form because that form does not reliably pass custom headers. Its connector example puts the key in the URL, while a configuration-file alternative uses mcp-remote to send an Authorization header. TRMNL says teams can revoke or regenerate a key and limits requests to 60 per minute per key.

TRMNL also documents a built-in Agent that uses a customer-supplied OpenRouter or Anthropic API key, with Tavily optional for search. The help page reports a $2.20 cost for one first-party plugin-generation example. That single example does not provide a usable estimate for another team's plugin, model choice, requests, or iteration count.

The May skill file is also official, but it is a versioned artifact from an earlier date. It describes hosted live-plugin operations and names tools such as IntegrationsShowTool, MarkupsReadTool, MarkupsWriteTool, MarkupsScreenshotTool, merge-variable and log tools, recipe and design-reference tools, and asynchronous dispatch and result tools. It gives every listed client the endpoint https://trmnl.com/mcp?api_key=<api-key> and states a limit of 60 requests per 60 seconds.

The May file proves that TRMNL published query-string instructions for those clients at that commit. It does not establish that the current server requires query-string authentication, that the listed tool names remain unchanged, or that a downloaded copy still matches the live service. The newer help page is the better current setup instruction; the gap between the two sources shows the documentation and client drift a team can encounter during a public beta.

Prefer the July header route and inspect any client that insists on a URL key

Use the July help page's Authorization-header route when the client supports it. If a client, connector, or downloaded skill insists on putting the key in the URL, stop before entering the credential and determine exactly where that client stores, logs, displays, exports, or reports the full URL. Make the decision for the exact client and version you will use, since another client's behavior cannot answer that question.

Neither documented URL form is evidence of a leak or vulnerability. The sources also do not show that TRMNL's server is insecure or that its stated plugin scope and revocation have failed. The practical issue is credential handling: a URL and an Authorization header can pass through different configuration fields, histories, logs, diagnostics, and support bundles. Our analysis of agent secret handling covers the broader raw-secret isolation problem; this trial only needs to establish how this TRMNL key moves through one client.

The live connection must settle what the dated instructions cannot

A successful connection only proves that one authentication path worked. It does not prove that an older tool list is current, that the connection identifies the intended plugin, that a write can be verified, or that revocation stops the next server call. Those questions require the live MCP surface and TRMNL's current plugin state.

The published tool descriptions also do not expose a plugin-ID selector for directing a key-bound operation to some other plugin. The credential appears to select the plugin available to the connection. A two-plugin denial attempt is therefore not mechanically grounded: the client may have no legitimate way to address a second plugin with the first plugin's key. Verify the identity that the live connection reports instead of inventing a target parameter the documented tools do not provide.

Treat the May names as leads, not a fixed API. MCP clients can request the live tool catalog with tools/list, which returns the names and descriptions the connected server currently exposes. The live list decides which identity, read, write, and visual-verification steps are available for this client session.

Use one disposable plugin to verify the current connection

1. Choose one client and record its exact version, then choose the transport before copying a key. Prefer the July help page's Authorization-header route. If the client or its installed skill requires URL or query-string authentication, pause until you know where that client stores, logs, or displays the URL and have decided that handling is acceptable for this disposable trial.

2. Create one disposable private plugin with no operational content, generate a key for that plugin, and connect the chosen client. Treat the ps_mcp_ value like a password. Keep it out of notes, screenshots, copied commands, issue reports, and any other test record.

3. Call tools/list and save the returned tool names and descriptions without the credential. Compare the live result with the task you intend to perform. Do not assume that the May skill's list or names are current.

4. Call the integration or plugin identity tool returned by the live server and verify that it identifies the disposable plugin. The May skill calls this tool IntegrationsShowTool; if the live surface uses another name, record the actual name and result. If no available tool clearly establishes the plugin identity, keep the connection disposable and stop before writing.

5. Use the live read tool to retrieve the plugin's current markup and save an unchanged backup before any write. Record the backup path and confirm that the file can be opened. The backup should contain plugin markup, never the MCP key.

6. Make one harmless, reversible markup change and read the markup back from the server. If tools/list includes a live screenshot tool, use it to inspect the rendered result; otherwise verify the change in TRMNL's editor or preview. Record which visual path you used, then restore the backed-up markup and confirm the restoration.

7. Revoke the key in TRMNL and make a fresh server call with the old connection. Require that next call to fail. A cached tool list or previously returned content is not a revocation check because it may not contact the server.

8. Record the client and version, source instructions followed, transport, live tool names and descriptions, verified plugin identity, backup path, write and readback result, visual check, revocation result, and timestamps. Never record the key value. If a result is ambiguous, preserve the non-secret evidence and leave the plugin disposable while you investigate.

This sequence checks one client version, one transport, one key-bound plugin, and the live tools exercised during the trial. It is not an independent security assessment of TRMNL's service. The documented 60-request limit also controls request volume; it does not verify plugin identity, write behavior, visual output, or revocation.

Connect operational content only when every part of the live path agrees

Connect operational content only when the current instructions, the client's credential handling, the live tool list, the reported plugin identity, the reversible write and readback, the visual verification, and the failed post-revocation call all agree. If any part is missing or contradictory, keep the plugin disposable or wait for the documentation, client, and server behavior to converge.

The tool catalog also shows what the client can ask the server to do and what data can return. Review those capabilities before enabling a real workflow, especially markup writes, refreshes, merge variables, logs, and screenshots. Our MCP authority analysis explains how to examine a server's broader action and data surface, and the AI workflow security review worksheet can help assess the surrounding workflow before rollout.

The Hacker News discussion includes enthusiasm, implementation questions, and skepticism about the product direction. Those comments are useful context for what readers noticed, but they do not establish the beta's security, reliability, cost, adoption, or current server behavior. The live acceptance check still has to carry that decision.

BaristaLabs can help verify the live path before rollout

BaristaLabs' process automation work can help run this client-specific trial, document the live tool and credential path, verify the reversible change, and test revocation before operational content reaches the connection. Bring the TRMNL client and the plugin workflow you want to connect before moving the public-beta setup beyond a disposable plugin.