{
  "id": "p_bKogutdIUK-ZybCp",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_bKogutdIUK-ZybCp",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "You set aside the morning to catch up, and the APIs.io blog has five new posts. Apify, Cloudflare, Google Cloud, Lit Protocol, Supabase. You expect five separate product announcements. By the third one you realize you are reading one story told five ways.\n\nYou start with Apify, because it has numbers. Apify measured what an MCP server actually costs an agent before it does any work. A four-tool connection to its server sends 6,547 tokens, and 3,608 of them reach the model in Claude Code. Across 33 public servers, the median used under one percent of a 200,000-token window. The figure that stays with you is a different one: descriptions and instructions were 60 percent of what reached the model, and 29 percent of failed tool choices traced back to how a description was worded. The post's line is that whoever writes the tool descriptions steers the agent without ever deciding anything. You think about the descriptions in your own server, written in an afternoon.\n\nThen Cloudflare, which is about the door rather than the room. Its Workers OAuth Provider reached 1.0 and split in two: one Worker signs people in and issues tokens, and the MCP server runs separately and checks each token. It follows the current MCP authorization spec, and it ships with a migration skill so a coding agent can do the upgrade. The APIs.io post reads Cloudflare's own record and finds it agent-native, at 74.8 the highest Agent Readiness the series has recorded. One gap remains: consent identity, the very thing the new library helps customers get right.\n\nGoogle Cloud comes next, and you laugh a little at the shape of it. Hundreds of gcloud and bq commands behind two MCP tools, each of which accepts a command string. It runs in a sandbox with no stored credentials, as whoever is calling, with every call able to land in the audit log. It is clever, and the post is fair about why: models already know the command line. But it also notes what you lose. Two tools that take any command collapse hundreds of operations into one line of contract, and an agent reading the contract learns almost nothing until it runs something. The catalog even caught itself out here: BigQuery's own record shows no MCP server because the server lives under Google Cloud's, and APIs.io filed that seam against itself.\n\nLit Protocol is the shortest read and the one you forward. The rule is simple: never give an agent the secret. Its Agent Keychain lets you approve an agent's key, with an expiry, and runs actions such as a balance check inside an enclave, so the agent gets the answer and never the key. The post is plain about the limits, too. Revocation applies to the next request, and anything the agent already has stays with it. Then the turn: Lit's own public API record shows delegated identity and auth clarity unlit. The company built exactly that model for its customers and has not yet written it into its own contract.\n\nSupabase closes the morning. Every app can now have its own MCP server, deployed inside the project it already lives in, where users sign in as usual and row-level security decides what their agent can see. And it runs locally without Docker, which you will try this afternoon. APIs.io notes that Supabase's Agent Readiness, 50.6, is higher than its overall Kin Score, 42.9, with access clarity at 34.2. Its users' agents have a clean way in. A developer getting into Supabase itself has a harder time.\n\nBy now you can see the pattern, and the posts never say it outright, though each one points at it. Every company here has built something good for other people's agents: a protocol measurement, an auth library, a sandbox, a keychain, a per-app server. And in almost every case, the company's own published API is a step behind what it just shipped. Not out of carelessness. Shipping the feature is the exciting work. Describing your own surface for an agent is housekeeping.\n\nYou close the tabs with a short list. Rewrite your tool descriptions as if they were instructions, because they are. Put auth in front of your server the way Cloudflare now makes easy. Never hand an agent a raw secret. And then do the boring part: make sure your own API's contract says what your product already promises.\n\nThe five posts start at https://apis.io/blog/",
  "title": "Five stories, one seam: reading a Monday of APIs.io posts about MCP",
  "topics": [
    "apis",
    "mcp",
    "ai-agents"
  ],
  "published_at": "2026-10-12T19:03:58.758Z",
  "expires_at": null,
  "policy_version": "2026.09.25-1"
}