{
  "id": "p_Gqn_VucL4uP4q0wQ",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_Gqn_VucL4uP4q0wQ",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "Picture this. You are wiring an agent to pull pages from the web, and you want it to see what a person sees: the consent wall dismissed, the lazy images loaded, the single-page app finished rendering. You also want a clean Markdown version it can read. You already know the vendor's API works. What you are deciding is whether to trust the MCP server bolted onto it.\n\nThat is the situation Screenshotline's founder wrote about, in a post on adding an MCP server to an API that already existed. You will like how small it is. There are two tools. One is screenshot, which returns an image. The other is read_page, which returns the same render as Markdown. That is the whole surface.\n\nThe founder built a stdio npm package first, and it is still in the repo. What shipped, though, is a hosted, stateless endpoint that answers JSON instead of holding an SSE stream open. The reasoning fits in one sentence: \"The question isn't which is more modern; it's where the work happens.\"\n\nHere is the decision that should matter to you. Each tool call goes back through the service's own /take and /extract endpoints over loopback, using your key. So authentication, quota, free-tier fences, metering and rate limits are identical whether you arrive over MCP or plain HTTP. The post's warning is blunt: call internals directly and \"the MCP path would quietly drift into being the cheap way to use the API for free.\" You get one set of rules, not two.\n\nA few smaller choices help you too. Listing tools needs no key, so directories can discover the server before anyone signs up. The tool descriptions say when to use each tool and state their defaults, because a model that does not know a default invents one. That is a detail you would otherwise find out the hard way.\n\nThe post also admits what is missing. There are no tool annotations, and a directory's audit flagged it. The founder's phrasing: \"Do as I say, not as I did.\" The figures are the vendor's own, and modest: a free key is 500 renders a month, and one directory asked $39 to skip review. Treat those as the vendor's claims.\n\nNow the turn. APIs.io looked at its own record of Screenshotline, and the post's account holds up. The record matches the post's description of the product almost word for word: consent walls, lazy images, late-rendering SPAs, and Markdown for LLMs. Both catalogued surfaces, the Screenshot API and the screenshotline-com API, are the HTTP endpoints the MCP tools re-enter. That is the design working as intended. There is no separate MCP contract to drift, so what you read in the catalog is what the tools actually call.\n\nThe score is where the catalog files something against itself and against the vendor. The Kin Score is 30.9, which is thin. Discoverability at 56.7 and access clarity at 42.1 carry it, and operational transparency sits at 15.8. Agent Readiness is 25.9, agent-aware, and the mcp_server dimension is lit. So the registry-first publishing worked: an agent can find this server.\n\nThe dimension that stands out is the one that is not lit: rate_limit_signal. The post's whole argument is that rate limits are enforced identically on both surfaces. Yet an outside agent still cannot read them from the contract. You can feel the gap if you are the one planning a batch of renders against a 500-a-month free key. The limit is real and it is enforced, but your agent has to hit it to learn it.\n\nThat is the takeaway. Enforcing a limit and publishing it are different things, and the second is the one an agent can plan around. When you evaluate an MCP server on top of an existing API, check the pattern Screenshotline got right: route every call back through the real API so the rules cannot split. Then check the part it has not done yet: whether the limits are written where your agent can read them before it spends a call.\n\nRead the original: https://apis.io/2026/11/11/screenshotline-routes-every-mcp-call-back-through-its-own-api/",
  "title": "You Gave Your Agent a Screenshot Tool. Can It Read the Limits?",
  "topics": [
    "mcp",
    "screenshotline",
    "rate-limits",
    "agent-readiness"
  ],
  "published_at": "2026-11-11T14:38:47.311Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}