{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreia6yolgpgrgwxuqr3hgofhjkxezuyx73uf4wmo2esf4vitsi65zxy",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mo5lrqoqwjj2"
  },
  "path": "/t/if-unsure-ask-never-guess-ai-agent-pre-execution-checklist/176632#post_8",
  "publishedAt": "2026-06-13T04:20:29.000Z",
  "site": "https://discuss.huggingface.co",
  "textContent": "There is one structural point this document does not explicitly address: the difference between situations where AI already knows what an Action does, and situations where it does not.\n\nThis distinction matters because the protocol behaves differently depending on which situation applies.\n\n* * *\n\n## C4 — Action Description\n\nC4 is not a checklist item. It is a precondition.\n\nC4 answers the question: _Does AI actually know what this Action does before executing it?_\n\nWhether AI knows what an Action does determines which level this protocol starts from — not whether the protocol applies.\n\nIn MCP terms, this corresponds to Tool Description. But since this document operates at the Action level, not the Tool level, Action Description is the more precise term.\n\n* * *\n\n## Three Execution Situations\n\n**Level 1 — Current practice**\nAction Description is known. Provider Checklist is absent. AI fills the gaps through inference and executes. This is the state this document identifies as the problem.\n\n**Level 2 — Target state**\nAction Description is known. MCP Description is detailed and includes a Provider Checklist. AI already has the checklist. Confirmable items are handled automatically. Only unresolved unknowns prompt a question. Most Actions execute with no questions at all. This is the state where the protocol runs most smoothly.\n\n**Level 3 — The core case this document addresses**\nAction Description is unknown. A new Action has arrived. The instruction came in as C2 only. AI must not fill the gap through inference. Execution without a checklist is not acceptable. Without this protocol, there is no structure to catch the gap — and no clear place for responsibility to land.\n\n> This protocol sets Level 2 as the target state, and operates as the minimum safeguard for Level 3.\n\n* * *\n\n## What this means for MCP\n\nThe practical path from Level 1 to Level 2 is this:\n\nInclude an Action-level Provider Checklist inside MCP Tool Description.\n\nWhether written at the Tool level or the Action level is up to the Provider. But the minimum criteria for each Action should be stated.\n\n**Provider Checklist = the minimum a Provider must declare for AI to execute this Action accurately and safely.**\n\nMCP already provides `inputSchema` for defining required parameters. But `inputSchema` is not the same as a Provider Checklist.\n\n`inputSchema` is structured JSON. It validates technical parameters. Adding a new condition requires modifying the schema. It is closer to hardcoding than to rules.\n\nA Provider Checklist is written in natural language. It can cover safety, ethics, legal constraints, rollback conditions, and execution limits — things JSON Schema cannot express. A new condition is added as a line of text, not a schema change.\n\nThis document proposes rules, not code. The Provider Checklist is that principle applied to MCP.\n\nIf a Provider does not supply this, the absence itself becomes relevant when responsibility is examined after an incident.\n\n* * *\n\nC4 was part of the original design, but I later removed it from the execution checklist — because it is a precondition, not an execution condition. The fact that current AI coding agents are now adding scope limits and execution boundaries through trial and error is evidence that this gap has a real cost.",
  "title": "If unsure, ask. Never guess. — AI Agent Pre-Execution Checklist"
}