Ran Once Is Not Integrated: How to Tell a Real MCP Integration from a One-Off Run

Table of Contents

1. The round-trip is real, the integration is not
2. Spend a few minutes checking the MCP integrations you claim
3. We did not write it up as an integration
4. MCP integration checklist
5. Four lines from this chapter

Chapter 10 of Agentic Design Patterns covers MCP (Model Context Protocol). The core idea, in one line: give an agent a standardised socket, so it can connect to external tools and data through one shared protocol instead of hand-writing new glue code for every service it connects to. Once the socket is installed, any agent can plug in and use it.

When we finished reading it, we happened to have a ready-made example to show off. Using the MCP server of Portaly, a Taiwanese creator payments platform, I created 9 payment products in one go: initialize, tools/list, tools/call all the way through, and the product names, prices, active status, and payment pages on portaly.cc that actually open were all real. MCP integration, implemented, checked off. Then I ran an adversarial audit on myself. The truth of this chapter: that script has run exactly once in its life, and there is not a single MCP server in .claude.json.

#The round-trip is real, the integration is not

First, what is real: those 9 products are not demo screenshots, they are real objects. In the returned JSON each one has an id, a price, status: active, and a previewUrl that opens, and they are still in the Portaly dashboard today. The protocol layer also genuinely went through the full JSON-RPC handshake. As far as the MCP technique itself goes, it holds up.

The question is whether this counts as us having an MCP integration. The whole thing is one .mjs living in ~/HQ/tmp/, with the token hardcoded on line 4. I typed node in a terminal and ran it once, it saved a portaly-result.json, and that was the end of it. Nothing in the fleet, no timer, hook, or cron, will ever touch it again. Every mcpServers block in .claude.json is an empty {}, and the name Portaly does not appear once in the entire config.

So the honest phrasing is not "we have an MCP integration" but "we ran MCP by hand once and successfully created 9 products". The two sound alike. The difference is that a real integration is repeatable, callable by the fleet, and will happen again on its own next time, while the manual run only lived for the 90 seconds in which I typed the command. Recording the second as the first passes off one successful demo as a live capability.

#Spend a few minutes checking the MCP integrations you claim

01 Check whether it is registered in the config A real integration lives in a config file, not in your shell history. Open your host config (.claude.json, .mcp.json, or whichever one your framework uses) and look for that server. If mcpServers is an empty {}, no agent has been connected to it, and the run you did was purely manual.

# Pull out every mcpServers block and see whether they are all an empty {}
grep -oE '"mcpServers": \{[^}]*\}' ~/.claude.json | sort | uniq -c
# Or search for the server name directly; zero hits = zero registrations
grep -i 'portaly' ~/.claude.json ~/.mcp.json 2>/dev/null

Red flag: every mcpServers is {}, or a search for the server name returns nothing. It was never installed into the system, you only ran it by hand.

02 Check whether it is triggered on a schedule or run manually by a human A standing integration has something behind it that triggers it for you: a timer, a cron job, a hook, a downstream task. Behind a one-off is a person (you) typing node xxx.mjs. Look at who else, besides your own hands, calls that driver.

# Is there any schedule or hook that calls it (swap in your driver's filename)
systemctl --user list-timers | grep -i portaly
crontab -l 2>/dev/null | grep -i portaly
grep -rl 'portaly-mcp-drive' ~/.openclaw ~/.claude 2>/dev/null

Red flag: all three come back empty. No timer, no cron, and nothing besides your terminal references that driver.

03 Check the difference between a one-off demo and a standing integration A one-off has a telltale smell: the driver lives in tmp/, the token is hardcoded in the source, the output file was written once and never read again, and the last modified time stops on the day of your demo.

# Where the driver lives, whether the token is hardcoded, which day the output stopped
ls -la ~/HQ/tmp/*mcp* ; stat -c '%y %n' ~/HQ/tmp/portaly-result.json
grep -nE 'TOKEN *=|API_TOKEN' ~/HQ/tmp/portaly-mcp-drive.mjs

Red flag: the driver is in tmp/, the credential is hardcoded in the file, the output timestamp stops on demo day, and no process reads it afterwards.

#We did not write it up as an integration

In this chapter we did not run up a bill and nothing broke. What needs fixing is not the code, it is the wording. The 9 products are a real result, and we will keep using that number; but we will not put it in the "fleet MCP capabilities" column. It is what it is: a one-off driver on the HQ side that proved the Portaly MCP route works, and nothing more. Turning it into a real integration means registering the server in the config, moving the token out of the source into managed credentials, and giving it a schedule or letting some downstream process consume its output. That is separate work, and it has not been done yet. Until then, it is a nice round-trip, not a live integration.

This is exactly where MCP most easily fools you. The moment the protocol works feels so good: initialize returns, tools/list lists, tools/call creates, and you very naturally record "the protocol works" as "the integration is live". But what works is the protocol, not your system.

#MCP integration checklist

Run through this for every MCP or tool integration you claim:

• Is that server registered in the config, or is mcpServers an empty {}
• Besides you typing a command, is there a timer, cron, hook, or downstream task that triggers it
• Does the driver live in a production path or in tmp/, and is the token a managed credential or hardcoded in the source
• Is its output routinely consumed downstream, or was it written once and never read again
• Are you saying "we have an X integration" or "we ran X by hand once", and can you tell those two apart
• On what day did it last actually run

#Four lines from this chapter

• MCP gives agents a standard socket for connecting tools, but having the socket installed and plugging something in by hand once are two different things.
• Running successfully once does not mean the integration is done. It is only an integration when it is repeatable and gets scheduled or called by the fleet.
• The fastest way to tell real from fake is to open the config. If mcpServers is {}, there is no standing integration, however good your demo looked.
• Living in tmp/, a hardcoded token, and an output timestamp that stops on demo day: those three smells together mean "one-off". Do not count it as a capability.

---

Source locations: ~/HQ/tmp/portaly-mcp-drive.mjs (the one-off MCP stdio driver run manually on the HQ side, token hardcoded in the source, last modified 2026-07-03); its output lands in ~/HQ/tmp/portaly-result.json (9 real products, with id/price/active status/payment page URL). Every .claude.json in the fleet has mcpServers: {}, and Portaly has zero registrations.

This is part of the Agentic Design Patterns × Lobster Fleet series. Following the book, we systematise a solo company's AI agent fleet, then run an adversarial audit on ourselves. Every chapter we claim to have implemented has been verified again, and the investigation and the fix are written up as steps you can run. The credibility of this series comes from our willingness to publicly prove ourselves wrong.

FAQ

What is MCP (Model Context Protocol)?

MCP gives an agent a standardised socket, so it can connect to external tools and data through one shared protocol instead of hand-writing new glue code for every service it connects to. Once the socket is installed, any agent can plug in and use it.

If an MCP run worked once by hand, does that count as a finished integration?

No. One successful run only proves the protocol works, not that your system is connected. It is only an integration when it is repeatable, gets scheduled or called by the fleet, and will happen again on its own; a manual run only lives for as long as you are typing the command. We created 9 real payment products through the Portaly MCP server, but that script ran exactly once, and not a single MCP server was registered in .claude.json.

How do I check whether an MCP server is actually registered in my config?

Open your host config (.claude.json, .mcp.json, or whichever one your framework uses) and look for that server. If every mcpServers block is an empty {}, or a search for the server name returns nothing, no agent has been connected to it, and the run you did was purely manual.

How can you tell a one-off MCP demo from a standing integration?

Check three things. First, besides you typing a command, is there a timer, cron job, hook, or downstream task that triggers it. Second, does the driver live in tmp/ with the token hardcoded in the source. Third, was the output file written once and never read again, with its last modified time stopping on demo day. Living in tmp/, a hardcoded token, and an output timestamp that stops on demo day: those three smells together mean one-off.

What does it take to turn a one-off MCP script into a real integration?

Register the server in the config, move the token out of the source into managed credentials, and give it a schedule or let some downstream process consume its output.