Picture this. You run security for a mid-sized company, and last quarter you did the thing VComply describes in its post: your team finished an access review, compliance asked for the evidence, and somebody had to find it, upload it, and tell a compliance officer to update the status. In the post's words, "People effectively become the connection between systems." You were that connection, and you would like an agent to take the job.
So you read what VComply, a governance, risk and compliance vendor, has written. In MCP Servers, AI Agents, and the Next Era of Compliance, it lays out the work an agent could remove. With controlled access, an agent could answer questions like "Which obligations are overdue this month?", "Who owns this control?" and "Where is the latest evidence?" The post gives no figures. It is an argument, and a careful one.
The care shows in the line it draws between reading and acting. "Which controls are overdue?" retrieves information. "Mark these controls complete" changes the compliance record. You'd expect those to carry different risk, and the post agrees: "Someone who can read a policy should not automatically be able to edit it through AI."
The prescription follows from that. "Start with read, then move carefully toward action." After read, low-risk actions such as comments and follow-up tasks. Complex workflow execution only once accuracy and permissions are understood. And the line you might pin above your desk: "The goal should not be maximum autonomy. It should be the right amount of autonomy for the risk involved."
Near the end, the post names its own product. The VComply MCP Server lets authorized clients such as Claude work with obligations, tasks, ownership, evidence and permitted workflow actions. That is the part that makes you want to try it.
So you do what you'd do with any vendor: you look at the record. The APIs.io catalog has a VComply provider page, and it lists no API pages. Every one of the nineteen Agent Readiness dimensions is unlit, including the MCP server the post describes. No machine-readable description of VComply's API or MCP server has been found.
The numbers say the same thing. The Kin Score is 22.0, in the emerging band. It is carried by access clarity at 60.5 and discoverability at 55.4, against contract quality and contract governance at 0.0. The Agent Readiness score is 0.0, marked human-only. To be fair to the vendor, the catalog says what it has found, not what exists behind a login. But what it has found is nothing to read.
That's the turn, and it is a pointed one. The post's own rule applies to its own record first. Start with read. Before an agent can be trusted to mark a control complete, something has to tell it which tools exist, what each one changes, and which of them require approval. A published tool list does that. So does an OpenAPI description or an agent card. Those are the things you, or your agent, would read before granting any permission at all.
Without them, the read-first discipline has nothing to stand on. You can't scope an agent to read-only if you can't see which operations are reads. You can't hold an action behind approval if the description never says which actions need it. The caution VComply argues for depends on exactly the information the catalog couldn't find.
What do you take away? First, VComply has made a good argument for careful, read-first autonomy in compliance, and you can use that argument as it stands. Second, an argument is not a description. When a vendor says its MCP server exists, check whether the first thing an agent would read about it has been published. In this case, as of this record, it hasn't.
So when you ask VComply the question, make it a read-first one: where is the tool list, and which tools change the compliance record?
Read the original: https://apis.io/2026/10/20/vcomply-says-start-with-read-and-its-record-has-nothing-to-read/