Assessment: Vantage MCP server
Vantage builds cloud-cost management, and their MCP server exposes it to AI agents — 127 tools across cost reports, budgets, anomalies, and the accounts behind them. I read it because assessing code you didn't write is the actual job, and because it does one thing better than any of the thirteen servers in the field notes. This is a generous assessment: the server earns it.
1 — Tool annotations · exemplary — the standout
This is the best annotation discipline I've seen in an MCP server, and it isn't close. All 127 tools are registered through a single wrapper whose TypeScript type makes the three hints — readOnly, openWorld, destructive — non-optional. You cannot add a tool to this codebase without declaring all three; the compiler refuses. The wrapper then maps them to the wire hints (readOnlyHint, openWorldHint, destructiveHint) in one place. 39 tools are declared destructive, and not one tool is missing its block.
Most servers rely on a maintainer remembering to annotate. Vantage made forgetting a compile error. That is the correct way to solve it.
2 — Destructive-operation gating · passes
Every deleting tool — delete-cost-report, delete-budget, and the rest — carries destructive: true and says "This action is irreversible" in its own description. That is exactly what a host needs to gate them: the server labels the danger honestly and correctly, leaving the client free to require confirmation. A server can't force a host to prompt; it can make sure the host has the information to, and this one does.
3 — Path handling · not applicable
No filesystem surface — every tool is backed by the Vantage API. Nothing to traverse.
4 — Query and injection safety · low surface, handled
The query tools (query-costs, query-network-flow-logs) pass structured parameters to the Vantage API rather than exposing raw SQL to the model, so there's no query string for an agent to smuggle a second statement into. The injection surface a database server has to defend simply isn't present here.
5 — Untrusted content · passes
Tools return the user's own cost and usage data from their connected cloud accounts, through an authenticated API — not arbitrary text from the open web. The prompt-injection path that worries me on a web-reading server is narrow here, and openWorld is declared per tool regardless, so a host is told what to trust.
6 — Access model · passes
Authenticated by the user's own Vantage token; every tool is scoped to whatever that token can already see, so the server grants no reach the user didn't already have. It runs on a Cloudflare Worker with per-tool request tracing, which also means an audit trail of what the agent did.
7 — Tests and CI · passes
134 test files, a test.yml CI workflow, Biome for linting, and separate staging and production deploy workflows. This is not a project where the guard rails are hoped for; they're run.
8 — Claim versus reality · guaranteed, not asserted
The check that ties it together. On most servers "every tool is annotated" is a claim you verify by reading. Here it's enforced by the type system — the property can't be false, because code that violated it wouldn't compile. That is the strongest form this check can pass: not a promise in a README, a guarantee in the build.
Tier two — the hardening not yet present
Vantage is about as good as it gets on the basics. Tier two is where even it has room — and where almost every server does, because this is the frontier of a protocol barely a year old.
Confirmation (8) · not yet. Destructive tools are labelled honestly, but the server doesn't itself require a confirmation before a delete — it trusts the host to notice the hint and prompt. Correct as far as the spec long required; the elicitation step added in 2026-07-28 would let the server insist rather than trust.
Read-only mode (11 · defense in depth) · not present. Access is scoped to the user's token, but there's no server-side read-only switch to keep an agent off the mutating tools entirely — the kind of second layer that protects against a host that gates poorly.
Blast radius (12) · deferred to the API. Delete tools remove one resource by token; bulk and rate limits rest on the Vantage API rather than the server. Reasonable, but a review would confirm the API actually bounds it.
Checks 9 and 10 — approval-replay and re-validation — barely apply: the server keeps no approval state to replay, and every call hits the live API, so there's no stale scan to exploit.
Verdict
If someone asks what good looks like for MCP tool annotations, this is the answer I point to — the tier-one surface is exemplary, the annotation completeness compiler-guaranteed. What's left is tier two: the server labels its destructive tools but doesn't yet require confirmation before them, and offers no read-only mode as a second layer. That's not a flaw so much as the next frontier, and it's exactly what a review would help add. Reviewed, sound on the basics, and honest about the hardening still ahead — the document a company can hand to a customer asking who checked.
Want the same for your server?
Read the whole thing, a test behind every finding, a document you can forward. How the service works · lesliekadenge@gmail.com.
Every claim above is checkable against the public repository at github.com/vantage-sh/vantage-mcp-server. This assessment is offered in good faith and names the server only for what it does well.