Picture this. You run a support assistant. It searches tickets and adds internal notes. Someone on your team has found a remote MCP server that does both, and the connection test just came back green. The server also offers a customer-export tool you never asked for.
A green connection feels like the finish line. Dome Systems, in a post on how to review a remote MCP server before connecting it, says it isn't. In its words: "A successful connection tells you the server works. Before using it in production, you also need to know what the agent can do, whose permissions it uses, and what happens when a call fails."
The APIs.io post calls Dome's piece the most practical MCP security review the series has read. It has no figures. Every item is a test, not a principle, and you can run each one this week.
Start with that export tool. Dome asks whether the assistant should be able to call it. Checking that export is missing from the tool list "isn't enough; try calling it directly."
Next, ask whose account the ticketing system sees: the employee, or a shared service account. Dome's line here is that "an email address supplied as a tool argument isn't proof of identity." Then confirm the server validates that a token was issued for it, and isn't just passing one through from the ticketing API.
Then run a test with synthetic contact details and inspect what the agent actually receives. Dome notes that "a saved configuration doesn't tell you whether a nested field survived." The post also flags server-side request forgery during OAuth setup, which can bite before the first tool call.
The item the post singles out is the retry. Your assistant adds a note. The note is saved, but the response never arrives. The assistant tries again. Dome warns that "retrying immediately could create the same note twice." You should reproduce that failure on purpose. If your application cannot tell whether the write happened, Dome says to "keep note creation disabled until there's a safe recovery procedure."
Now the turn. The APIs.io post doesn't stop at praise. It looks at Dome's own record in the catalog, and the record is thin. The catalog holds Dome as a gateway vendor with almost no contract of its own. Its provider page lists no API pages.
On the Agent Readiness score, the MCP server and auth clarity are lit. Spec presence and agentic access are unlit. The Kin Score is 42.3, in the developing band. It's carried by access clarity at 76.3 and developer ergonomics at 71.4, against contract quality at 0.0. The Agent Readiness score is 9.9, which the catalog labels agent-aware.
That gap matters to you. The retry test maps onto the idempotency dimension this series checks on every provider: a contract that lets a caller repeat a write safely, usually with an idempotency key. The post says most providers in the series have it unlit. So when you run Dome's test against a server, you are probably testing for something its provider never published.
That is the catalog's point about Dome too. It has written the test that would show which providers a support assistant can safely retry. The post's closing line is that Dome's own record should publish the contract that would pass it.
Here is what you take away. Don't treat a green connection as approval. Before your assistant gets write access, call the export tool directly, find out whose permissions the server uses, check where tokens come from, and see what the agent really receives. Above all, break a write on purpose and retry it. If you can't tell whether the note landed, leave note creation off until you have a recovery procedure. And when you evaluate a provider, look for the contract as well as the checklist. A server that claims to be safe to retry should say so in something you can read and test.
Read the original: https://apis.io/2026/10/23/dome-says-a-retried-write-is-the-mcp-review-question-nobody-tests/