Agents
Let your coding agent run your growth
Connect a coding agent to AfterLaunch research and growth drafts through MCP or REST, with account context, scoped permissions and review before completion.
From a finding to something you can publish.
- ResearchAfterLaunch
- Working draftAfterLaunch
- ReviewYou and your AI
- PublishWith your approval
In this article
A coding agent can already work in the repository where you maintain your product and its website. Giving it access to growth research lets you use that same workspace to improve a page, prepare a comparison or finish a draft.
The useful connection is between a finding and the work it requires. A search report can identify a weak page; an agent with access to the page can help change it. That handoff needs enough context to explain what was found and why the proposed edit is worth making.
AfterLaunch exposes its research and prepared growth moves through MCP and a REST API. Your agent can read the same work you see in the browser, then help you finish it in the tools you already use.
- AfterLaunch makes research and drafted growth work available through MCP and REST.
- The connected agent helps finish the work in your repository and tools, with the same record available in the browser.
- Keys separate reading, acting on moves, metered work, configuration and external publishing. Review the permissions before connecting one.
Connecting research to the work
An agent needs a documented interface and a credential with the right permissions. It also needs to know which account it is working on and what happens if it repeats an action after a failed connection.
For growth work, the response has to carry the evidence as well as the task. “Improve this page” is difficult to act on. A proposed edit with the page, the customer question and the supporting source gives the agent something it can review with you.
The connection described here makes that material available in an agent session, without copying findings out of a dashboard by hand.
The growth layer an agent can wire in
AfterLaunch is the agentic growth engine. Its MCP endpoint at /api/mcp and REST API under /api/v1 use scoped keys and share an action registry. The developer reference lists the current tools and their permissions.
Between agent sessions, AfterLaunch monitors the product’s discoverability and prepares growth work. The research covers:
- AI Visibility. How ChatGPT, Gemini, Perplexity and Google AI Overviews describe the product when someone asks for a tool like it, and who gets named when it is not.
- SEO. A site-wide audit that produces specific, applicable fixes rather than a score.
- Competitors. Where the product stands against the set it actually competes with in answers and in search.
- Communities and channels. Where the customers are already asking the question the product answers.
The Board holds the proposed work, including the reason for each move and its draft. An agent can read that material, inspect relevant files or sources, and work through an edit with you. The record stays available when you return to the browser.
What a session actually looks like
Once an account has a key, the following sequence establishes context before making changes.
Connect
One command points an MCP-capable client at the endpoint and carries the key. In Claude Code that is:
claude mcp add afterlaunch --transport http https://afterlaunch.io/api/mcp --header "Authorization: Bearer al_..."REST callers skip the command entirely and send the same Authorization header to /api/v1.
Confirm what the key is bound to
Start with whoami to confirm which product run the key belongs to and which permissions it has. This avoids applying a task to the wrong project or assuming a key can perform an action it cannot.
Read the Board
list_feed returns the current growth work and its draft content. Read the move and its evidence before editing it. The API also exposes loop status and individual outputs; the developer reference describes the available filters and response fields.
Act on a move
update_draft saves an edited draft, skip_move records a dismissal, and archive_move removes work from the Board. ship_move records completion only after the founder explicitly confirms it, using the current move state and the evidence required for that work. A generated asset alone is not proof that a page or post is live. These actions use the act scope.
refresh_scan, replenish_feed and run_loop trigger metered work and require the write scope. Their documented idempotency and cycle limits control repeated requests. Read the current tool description before calling them, and reuse an idempotency key when retrying the same logical action.
Set the terms
Configuration tools can change a loop’s autonomy or cadence where the product permits it. They require the config scope. These permissions are separate from reading the Board or editing a draft.
| Scope | Purpose | Examples |
|---|---|---|
| read | Inspect the product and its growth work | whoami, list_feed, get_loop_status |
| act | Review and update work | update_draft, skip_move, archive_move, ship_move |
| write | Trigger metered work | refresh_scan, replenish_feed, run_loop |
| config | Change permitted account or loop settings | set_loop_autonomy, set_loop_cadence |
| egress | Publish through supported external connections | Requires separate publishing permission |
Permissions and review
Review the permissions when you connect a key. Reading work, editing it, triggering metered generation and publishing externally are separate capabilities.
- Use a named key bound to the intended product run, and check its scopes with whoami.
- Keep retries attached to the same logical action. Metered tools document their idempotency requirements and spend limits.
- Review the exact draft before publishing. Preparing an asset and publishing it are separate actions.
- For agent-assisted onboarding, the person enrolling confirms the request through the approval flow.
The developer reference is the place to check the current permission and completion requirements. An agent should use those requirements at the time of the action, rather than infer them from a tutorial.
Where to start
Create a key in Settings on an eligible account, give it a recognisable name, and connect your agent. Begin by reading the account and the Board, then choose one move to review together.
If you do not yet have an account, the agent-assisted onboarding flow can request an approval email. The person enrolling confirms the request before account activation proceeds.
Read: How an AI agent sets up its own growth engine →Use the live developer reference for tool names, parameters and authentication details.
Developer docs: the API and MCP surface →Do I need an agent to use AfterLaunch?
No. You can review the research and growth work in the browser. MCP and REST provide another way to use that same account.
Which agents can connect?
An MCP client that supports the HTTP endpoint and bearer authentication can connect. Other integrations can use the REST API. Check the developer reference for setup details.
Can a connected agent publish externally?
External publishing requires its own permission and a supported connection. Reading the Board or editing a draft does not grant that permission. Review the key scopes and the action’s requirements before publishing.
How are repeated metered requests handled?
Metered actions have idempotency requirements, cycle limits and spend controls. Follow the current tool description and use the same idempotency key when retrying the same action.
Start with a free scan to inspect your product’s discoverability, then review the ongoing research and growth work through the browser or a connected agent.
Scan my siteRead next
How long before Google shows a change
Typical and slow times for Google to find, index and show a change, as reported from a Google talk, and when to judge a growth move by them.
Read →JournalLaunched my SaaS, nobody finds it. What now?
A quiet launch is the normal start for a young product. What our AI search data shows, the three checks to run in order, and the one move to make after them.
Read →