Documenting what you build

Why document

People and AI agents pick an add-on from its README. A missing or vague README is the most common reason an add-on cannot be sealed. Write for both readers: a developer who will run it, and an agent that will decide whether it is safe to.

Agent template

• A manifest with id, name, tier, schedule, secrets (name, label, options where fixed) and the modules it needs.
• A README with a For AI agents block: the schedule, which modules and tools it calls, and what it must never do.
• The tables it creates, with each column named, and which ones a user may edit.
• The schedule as a cron line, and what happens when a run fails.
• Safety notes: which rules are enforced by SwooshConnect and cannot be changed from the code.
• A pinned version, and the same version in the manifest and the README.

MCP client config, recipe or script

• What it calls: list every tool or route, by name.
• Platforms only through SwooshConnect's API: https://swooshrank.com/api/v1 or https://swooshrank.com/api/mcp. Any other data goes only to the customer's own runtime and the AI provider whose key the customer supplies, and the README lists every destination.
• Env vars: name, what it is for, and where the user gets it. Never ask for a secret that is not needed.
• An OSI-approved licence, stated in the README and in a LICENSE file.
• A For AI agents block with the same DO, MUST, PREFER and NEVER lines as our own pages.

For the seal: what we check

• Every criterion on the Community add-ons page, against the exact version you submit.
• That the code reaches platforms only through our API, sends other data only to the customer's own runtime and their AI provider, and keeps every voice and consent rule.
• That the env vars in the README match the code, and no other secret is read.
• That the README tells an AI agent what it must and must never do.
• That the version is pinned and the licence is OSI-approved.

You pay for what you connect. Nothing else.