The MCP server that wouldn't answer

The MCP setup kit was supposed to do two things. Let Claude Code read the deploy status of a pull request, and let it read my Vercel project directly — deployments, domains, environment, the whole surface. Two servers, GitHub and Vercel, and a kit that showed how to wire both. The Vercel half never worked. The server connects fine. Authentication succeeds. Then every single call scoped to my project comes back 403. Not a timeout, not a bad tool name, not a malformed request — a flat refusal, consistently, on every project-scoped call I tried. The connection is authenticated to something, just not to the team the project lives under. I could have kept going. There's a version of this where I spend an evening on OAuth scopes and re-authentication flows and eventually get it, and there's a version where I write the kit anyway with a note saying it might 403 for you too. I did neither, and the reason is a rule I set before any of this existed: I only sell things I've personally built or tested. That rule is easy to agree with in the abstract and annoying the moment it costs you something. It cost me here. The kit is smaller than I planned. But a setup kit whose central instruction is "and then this might not work" isn't a kit, it's a bug report with a price on it. So the kit ships with GitHub only, and it does one thing well. Claude Code opens a pull request, then reads that PR's Vercel preview status through the GitHub server and tells me whether the deploy succeeded before I look at anything myself. The actual deploys run through Vercel's GitHub integration, which never needed an MCP server in the first place. That turned out to be the interesting part. The thing I thought I needed a second server for was already handled by an integration I'd set up and forgotten about. Three things worth taking from this if you're building on MCP right now. A server being connected tells you almost nothing. Mine showed green and authenticated the entire time it was refusing every request. The only real test is calling the specific tools you need against the specific resource you need, and the only honest way to describe a server's reach is what you've actually watched it return. 403 is usually a scope problem, not a credential problem. If authentication passes and calls still fail, the token is probably valid for a different account or team than the one you're pointing it at. That's a re-authentication problem, not a debugging problem, and knowing the difference saves an evening. And the boring integration often beats the impressive one. I wanted the MCP server because it was the new thing. The GitHub integration was already doing the job, and the working setup is the one that used less. The Vercel connection is still sitting there, still 403ing, on the list of things to re-authenticate properly. If it starts working, it becomes an update to the kit rather than a rewrite — which is the other reason I cut it instead of writing around it. Shipping the half that works leaves a clean place to add the half that doesn't.