The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
I graded the official MCP servers. Two got an A, one got an F — and the most useful finding came from a layer nobody else measures.
mcp-vitals (open source) grades an MCP server's reliability A–F across three layers: static schema quality, behavioral tests run against the live server, and — the novel part — agent-usability: hand an LLM the tool list and a real task, and see if it picks the right tool and builds a valid call.
Results on the official reference servers:
• memory — A (94)
• everything — A (92)
• filesystem — C (71)
• sequential-thinking — F (57)*
The finding that matters came from the agent-usability layer. On the filesystem server, a model given a "read this file" task couldn't tell read_file from read_text_file and picked the tool that doesn't exist. A security scanner or a static grader never sees that — but it silently breaks agents in production.
*The F is honest: sequential-thinking's single tool needs a payload my schema-only generator can't synthesize, so the behavioral layer couldn't exercise it. A conservative grader that won't vouch for what it can't verify — I document that plainly in the report.
Security scanners tell you a server is safe. mcp-vitals tells you if it's any good.
Live report → https://enached134-ctrl.github.io/mcp-vitals
Repo (MIT, drop-in GitHub Action) → https://github.com/enached134-ctrl/mcp-vitals
enached134-ctrl.github.io
The State of MCP Reliability — graded A–F
I graded the official MCP reference servers for reliability and agent-usability. Two got an A, one got an F. Open-source CLI + GitHub Action.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Three posts on my feed this week circled the same problem from different angles: an agent that repairs code by rewriting its own tests, a CSV reconciler that has to keep every unmatched SKU instead of silently dropping it, and a support agent that escalates weak matches to a human. The pattern repeats. Autonomy needs a hard boundary and an auditable trail. When I build execution bots the rule I keep is: the agent proposes, the runner disposes. Every write goes through a diffable record, and any action that cannot be verified is escalated, not guessed. Green tests only count if the test files are read-only. What boundary do you enforce first once an agent has write access?
The fix for an agent that keeps getting your design system wrong isn't a better prompt.
It's putting the rules where the agent reads them.
In the repo. In skills. In checks it can run itself.
Writing a course about exactly this.
What sells it for me is the refusal telling the agent exactly where the token should go. A bare "no hex" error usually just sends it looping. Does guard.mjs run only as an agent hook, or in pre-commit too so it catches humans as well?
n8n Agents: workflows as tools beat raw CRM write access
n8n Agents landed on September 25, 2026. You describe a goal, pick a model, attach tools, and the same agent can live in Slack, on a schedule, or inside a workflow.
The part that matters for freelancers is how tools get scoped. An agent can call MCP servers, single n8n actions, or whole workflows. That last option is the real upgrade. Instead of handing the agent your CRM credential and hoping the prompt stays polite, you attach a workflow that only adds a note. The agent never holds the keys. It only holds a fixed process.
Mark anything sensitive so the agent pauses for Approve or Reject before it runs. Per-tool credentials stay on the tool, not in the agent's pocket. n8n says Agents are still in preview, so test before you publish and keep approvals on write paths. Details: https://blog.n8n.io/introducing-n8n-agents/
I already use n8n for automation. For open-ended support or research jobs, I'd start with two read workflows and one write workflow behind approval, not a broad CRM token.
Would you rather give an agent a whole CRM credential, or a workflow that can only add a note?
