GETTING STARTED
Integrate with an AI agent
These docs are written for people. This page is written for the agent doing the work.
Most Agentifys integrations are now written by a coding agent rather than typed by hand. An agent reading this site gets React markup, navigation and a theming playground wrapped around the two facts it needed. So the same material is published in formats an agent can consume directly: a spec, a single-file reference, and a skill. And for the setup half of the job, an agent does not have to read anything at all — it can call the platform directly over MCP.
The four files, and one endpoint
| Field | Type | Description |
|---|---|---|
/llms.txt | map | A short index: what exists and where it lives. The file to fetch first. |
/llms-full.txt | reference | The entire integration surface in one self-contained file — endpoints, signing, SSE events, widget, tools, errors. An agent can integrate end to end without fetching anything else. |
/openapi.json | OpenAPI 3.1 | The public /v1 API, 19 operations. Generate a client from it. Models the per-route identity transport structurally, which is the thing integrators most often get wrong. |
/agentifys.skill.md | Agent Skill | Task-shaped instructions: a decision tree, the integration checklist in order, how to verify each step actually worked, and a troubleshooting table keyed on the symptom you actually see. |
/mcp | MCP server | Not a file — a live endpoint. Connect an agent with a scoped eat_ admin token and it gets twelve tools that create and configure projects: prompt, user schema, tools, policies, MCP servers, limits, scheduling. See the MCP provisioning guide. |
/admin routes — the console API is not public./v1 API use the publishable era_ project key. The MCP server uses an eat_ admin token, which is the opposite kind of credential: secret, server-side only, never in browser code and never in a committed file. Both ride Authorization: Bearer, which is exactly why agents mix them up — the skill file's first section exists to stop that.Give them to your agent
# Claude Code — drop it in your project mkdir -p .claude/skills/agentifys curl -sSL https://agentifys.ai/agentifys.skill.md \ -o .claude/skills/agentifys/SKILL.md # Or hand the whole reference to any agent in one shot curl -sSL https://agentifys.ai/llms-full.txt
The skill file is a single markdown file with YAML frontmatter, so it works anywhere skills are supported, and reads fine as a plain document anywhere else. Nothing about it is Claude-specific beyond the format.
The files tell an agent how to integrate a project. If you also want it to create one, connect it to the MCP server as well — then the same agent writes the prompt, declares the user schema, adds the tools and the policies, and reports what a human still has to do by hand:
claude mcp add --transport http agentifys https://agentifys.ai/mcp \ --header "Authorization: Bearer eat_..." \ --scope user
A prompt that works
Agents integrate better when they are told which of the two shapes you are building before they start, because that single choice decides the rest — identity mode, where the key lives, and whether your allowed-origins list must stay empty.
Integrate Agentifys into this product. Read https://agentifys.ai/llms-full.txt first — it is the complete integration surface in one file. The OpenAPI spec is at https://agentifys.ai/openapi.json. Our situation: - we serve signed-in users, so use signed identity - our backend will proxy the calls (the browser never holds the key) - we want the widget, one read tool, and a weekly scheduled report
If you are a person
Start at the integration walkthrough, which carries one realistic scenario from first request to a working scheduled task, and links the reference pages at each step. The quickstart is faster if you only want the widget on a page.