An MCP server should be judged by what an agent can finish, not by how many tools sit in its catalog. So I pointed an agent at the hosted Appwrite and Vercel MCP servers and asked both to do the same job: deploy identical applications, inspect the builds, diagnose a deliberate failure, ship a second version, and recover from it.

The two servers are built for different jobs, and the result splits along those lines:

• Appwrite reached much further into the backend and was the only one of the two exposing rollback, deletion, and explicit write confirmation through MCP.
• Vercel deployed faster and reported runtime failures better. It reached READY in about 2.1 seconds on the static app and its dedicated log tools filter properly.

How I tested

Both hosted MCP servers ran over OAuth from the same Darwin 25.5 arm64 client. I threw away the first call to each tool so nobody paid for a cold start, then alternated between the two servers so neither got the benefit of going second. Anything that wrote data went into a throwaway project I could delete afterwards.

Two test apps:

• A static site with identical index.html and marker.json files, deployed from the same source archive on both platforms.
• A Next.js 15.2.8 SSR app with deterministic build markers and controlled 200, 400, and 500 responses.

Each agent had to discover its workspace, deploy both apps, inspect logs and analytics, recover from an intentional build failure, publish v2, attempt a rollback, and handle 50 requests at concurrency 10.

01

Orient

workspace + IDs

02

Deploy

same source bytes

03

Break

exit code 42

04

Observe

3×200 · 1×400 · 1×500

05

Recover

v2 + rollback

06

Burst

50 requests · c=10

Appwrite

Vercel

How I scored it

Six things counted, correctness most of all: correctness and completeness at 30%, then result compactness, discoverability and call economy, median and p95 latency, and safety and lifecycle control at 15% each, and error recovery quality at 10%.

The two combined totals landed close enough that the gap between them tells you nothing, and the per-category numbers behind them were never written up. The per-task scores from the read and observability phases are the ones worth putting on screen:

Per-task scores, out of 5

AppwriteVercel

Workspace and project discovery

3.4

4.6

Resource detail

4.6

4.4

List deployments

3.8

3.5

Deployment detail

4.6

4.3

Build logs

4.0

4.6

Runtime logs

2.4

4.2

Usage and analytics

4.7

3.7

Documentation search

4.3

3.5

Appwrite wins five of the eight tasks, and the three it loses are the ones it loses badly.

Router versus toolbox

Vercel exposes 33 direct tools covering projects, deployments, logs, analytics, agent runs, collaboration, domains, purchases, and deployment protection. Once the agent has a team or project ID, it calls a tool named for the task.

Appwrite exposes 992 operations across 81 services behind a handful of meta-tools. Instead of loading every schema into the model's context, the agent works through four calls:

• appwrite_get_context to find the account, organization, and project
• appwrite_search_tools to find an operation
• appwrite_call_tool to execute it
• appwrite_search_docs to search current documentation

Vercel

33 named tools, called directly

33 · each reached in a single named call

Appwrite

4 meta-tools in front of everything

• get_context
• search_tools
• call_tool
• search_docs

992 across 81 services · each reached in two, none of them named up front

The router usually costs one extra call before an unfamiliar operation, and buys access to Auth, Databases, Storage, Messaging, Functions, Sites, usage, domains, and infrastructure from one interface. Vercel's toolbox is easier to navigate as long as the work stays inside deployment.

What each server actually covers

StrongPartialNot exposed

Use case	Appwrite MCP	Vercel MCP
Static and SSR deployment	Sites, deployments, activationPartial coverage	One-call project creationStrong coverage
Build and runtime logs	Available, with defectsPartial coverage	Dedicated, filter-rich toolsStrong coverage
Auth and user management	Full backend managementStrong coverage	Not exposedNot exposed
Databases and storage	Full backend managementStrong coverage	Not exposedNot exposed
Functions	CRUD, deployments, executions, variablesStrong coverage	Runtime and deployment inspectionPartial coverage
Usage and analytics	Resource and compute metricsStrong coverage	Visitors, pageviews, routes, eventsStrong coverage
Deployment protection	Site and project controlsPartial coverage	Direct protection and bypass toolsStrong coverage
Domains	Domain catalog and DNSStrong coverage	Availability, purchase, managementStrong coverage
Agent collaboration	No direct equivalentNot exposed	Agent traces and toolbar threadsStrong coverage
Rollback and cleanup	Activation, rollback, deleteStrong coverage	Not exposed through the tested toolsNot exposed

Lifecycle control: Appwrite exposed more

Getting the first URL live is the easy half. An operator also has to publish updates, switch versions, disable things, and clean up.

Appwrite deployed v2 to the existing Site with an explicit build cache hit, switched the active deployment, and then rolled back to v1 in 1.32 seconds. The public health endpoint returned version: "v1" immediately. Disabling the Site returned a 404 router_deployment_not_found, and re-enabling restored v1 straight away.

Vercel's inline deployment tool created a new project for v2, which also meant it reported no previous build cache. Its tested MCP surface exposed no rollback, no redeploy to an existing project, no project deletion, and no general environment-variable management. Those capabilities exist elsewhere on the Vercel platform; the benchmark required MCP-only operation. The practical consequence is that both Vercel projects from this run are still live, because nothing in the 33 tools can delete them.

Write safety differed too. Appwrite required confirm_write=true before every mutation and refused the first unconfirmed create. Vercel's deploy tool had no equivalent parameter, though its commercial operations do separate quotes from purchases.

Deployment speed: Vercel was a bit faster

Vercel accepted an inline file tree and had the static app ready in about 2.1 seconds, on one write. Appwrite needed two, create the Site then upload and activate a gzipped deployment, and took about 27 seconds end to end. On SSR the gap narrowed to 39.1 seconds against a 91-second build, roughly 2.3 times faster on reported build time alone.

Both platforms rejected an earlier version of the SSR app, for different and legitimate reasons: Appwrite's adapter expected a next.config.* file, and Vercel blocked Next.js 15.2.4 over a known vulnerability. Each agent diagnosed its own failure from the logs it was handed.

Observed latency

Once the agent had picked a project, Appwrite was faster on every repeated read I measured, in the case of build logs by a factor of eight.

Observed MCP call latency, lower is better

View as table

Operation	Appwrite	Vercel	Runs
Resource detail	416 ms	891 ms	3 + 3
Deployment list	448 ms	897 ms	3 + 3
Deployment detail	491 ms	914 ms	3 + 3
Build logs	319 ms	2,590 ms	1 + 1
Analytics	416 ms	915 ms	1 + 1
Docs search	525 ms	1,464 ms	3 + 3

Both servers cleared the bounded concurrency check without errors. Appwrite returned 50 of 50 in 5.146 seconds wall time, Vercel 50 of 50 in 4.714 seconds. Vercel was modestly faster, and the sample is far too small to support a broader performance claim.

Compactness is where the read gap is real rather than marginal. Asking for 100 log entries returned roughly 115 KB from Appwrite for 96 events, which got context-truncated, against 12.3 KB of filtered events from Vercel.

Choosing between them

Appwrite MCP fits when the agent has to operate the backend as well as the deployment: users, data, files, messaging, functions, and Sites. It is also the stronger fit when you need explicit write confirmation, rollback, repeated deployment to one resource, and cleanup the agent can actually perform.

Vercel MCP fits when the job is deploying, inspecting, diagnosing, and analyzing Vercel-hosted applications. Its direct tools remove selection ambiguity, its builds were faster here, and its log filters make for a cleaner diagnostic loop.

Worth saying plainly: both of these deploy sites well. Every app I handed to either server went live, and both agents read their own build failure and fixed it without help. Vercel got there faster, 2.1 seconds against 27 on the static app and roughly 2.3 times quicker on the SSR build, and its log responses came back small enough to actually read. Appwrite was slower to the first URL and reached much further once it arrived: rollback, deletion, write confirmation, and the rest of the 992 operations behind the router, none of which the 33 Vercel tools touch. If your work stops at deploying, that speed is the whole story. If it doesn't, one extra search call buys you a lot.

---

Test conditions

• Access. Hosted MCP endpoints, authenticated over OAuth.
• Client. A single macOS arm64 machine, one continuous session.
• Write phase. Static deployment, SSR deployment, an induced build failure, a second version, and a rollback.
• Excluded. No paid protection tier was enabled, and no purchase operation was executed.
• Scope. Results describe the MCP surfaces as tested, not controlled infrastructure benchmarks.