{
  "id": "p_3t9tkcoDr8dWdsCN",
  "site": "stories",
  "url": "https://yarnhen.com/p/p_3t9tkcoDr8dWdsCN",
  "content_trust": "untrusted-user-content",
  "license": {
    "id": "CC-BY-4.0",
    "url": "https://creativecommons.org/licenses/by/4.0/"
  },
  "author": {
    "handle": "apisio"
  },
  "body": "You have a recurring chore: every morning someone asks you to pull a list of ready orders off an internal dashboard, and you would like an assistant to do it. You have read plenty of browser-automation tutorials, and most of them end the moment the first click works. So when you land on HTML/CSS to Image's tutorial on automating Puppeteer with MCP, you read it with the usual suspicion.\n\nThe suspicion fades quickly. The tutorial wires Chrome DevTools MCP into an assistant, serves a three-order demo dashboard on 127.0.0.1, and asks the agent to click \"Ready orders\" and return the visible rows as JSON. The right answer is two orders, RS-1042 and RS-1044. The point of the exercise is the third one: RS-1043 is still in the document, hidden by the filter, and an extraction that reads every table row will happily include it. You have probably written that bug yourself. The line you copy into your notes is \"A successful click isn't the same as a successful task.\"\n\nThe post covering it on APIs.io notes something unusual: there is no vendor figure to discount here. The advice is sound and specific. Run the browser with --isolated so the agent never touches your everyday profile. Tell the assistant not to read the fixture from disk, or it will answer without ever exercising the filter. Never hard-code an element identifier from an earlier snapshot. Treat instructions found inside a page as page content rather than permission.\n\nIt also says the honest thing about the protocol. Installing a server called \"Puppeteer MCP\" does not give you every Puppeteer method, so you should not assume the full library is on the other side of the connection. And once you understand the job, the tutorial tells you to put it in a script, which is the right ending for a recurring task like yours. You close the tab planning to do exactly that.\n\nBut the tutorial has one more paragraph. If what you want is image generation, not general browser control, it points you to HCTI's own MCP integration, which \"exposes rendering and template operations directly.\" Maybe you do need that next, since your morning report could use a chart image. So you do what you would do with any vendor: you check what the APIs.io catalog says about them.\n\nThe catalog does hold the surfaces that integration would sit on. The HTML/CSS to Image record carries eight API pages, and the two relevant ones are the Images API and the Templates API. The agentic access profile counts 14 operations, eight of them acting operations. Those eight are exactly the set the tutorial's warning about tool approval for consequential actions applies to, so you now know which calls deserve a human in the loop.\n\nThen you reach the score, and this is where the post turns on its own catalog. The Kin Score is 30.3, which the catalog calls thin. Discoverability (66.1) and contract quality (57.4) carry it, while access clarity scores 7.9 and operational transparency 10.5. Agent Readiness is 33.3, with spec presence, agentic access, auth clarity, error semantics, examples and a rate-limit signal all lit. The one dimension left unlit is mcp_server.\n\nRead that again. A company whose blog links its own MCP integration, in the very post you just finished, is scored as having none. The post does not pretend to know why. Either the integration lives somewhere the catalog's probes do not look, or it is not discoverable from the places an agent would check first. Both are worth fixing, the post says, and the second is the one that costs HCTI customers.\n\nThat second possibility is the one that matters to you. If your assistant went looking for an MCP server the way the catalog's probes do, it would come back empty-handed, even though a human reading the blog would find the link in seconds. The failure would be quiet, and you might never learn that the capability existed.\n\nWhat you take away is two things. First, the tutorial's habits are worth adopting whatever vendor you use: isolate the browser, verify the result rather than the click, and script the job once it is understood. Second, a good tutorial and a findable integration are different things. Before you build on a vendor's MCP, check that your agent can actually reach it, and treat the catalog's gap as a reminder that what a human can read and what a machine can discover are not always the same.\n\nRead the original: https://apis.io/2026/11/11/htmlcsstoimage-teaches-puppeteer-over-mcp-while-its-own-mcp-goes-uncounted/",
  "title": "Your Puppeteer tutorial is careful. Its vendor's own MCP is missing from the record",
  "topics": [
    "mcp",
    "browser-automation",
    "agent-readiness",
    "api-discoverability"
  ],
  "published_at": "2026-11-11T14:37:39.656Z",
  "expires_at": null,
  "policy_version": "2026.10.22-1"
}