# Agent skill manifest
An agent skill manifest is a machine-readable description of the named capabilities a tool exposes to AI agents. It includes the skill's name, a clear description of what it does, the arguments it accepts, the shape of the output it returns, and ideally usage examples. The audience is a language model rather than a developer. The structure is what lets an agent reason about which skill to call without having to read a REST API doc and infer the right endpoint.
The concept generalizes across agent runtimes. Anthropic's Skills format, OpenAI's tool definitions, the MCP capability list, and various proprietary equivalents all express roughly the same idea. The names differ. The structure is similar. A manifest declares what the tool can do in a form a model can reason about at planning time.
Why it matters
The shift from human-driven software to agent-driven software is mostly a shift in how capabilities are discovered and invoked. A human reads a UI to find a button. An agent reads a manifest to find a skill. If the manifest is missing, vague, or misleading, the agent cannot use the capability reliably. If it is structured and precise, the agent uses it correctly on the first try.
This matters more than it sounds because models are trained to follow descriptions literally. A skill description that says "Searches the prospect database" will be used to search the prospect database. A description that says "Searches the prospect database and also handles enrichment if the user did not specify a separate enrichment step" will get used in confused ways because the agent now has to reason about preconditions.
The manifest is also the contract between the tool and the agent. When the tool ships a breaking change to an endpoint, the manifest version tells the agent the contract changed. Without an explicit manifest, tools and agents drift silently and integrations rot over months.
For agent-driven outbound specifically, the manifest is the unit of integration. A sales tool that ships a high-quality manifest can be used by any compatible agent within minutes. A tool that does not ship one has to be integrated by hand, which usually means it does not get integrated and falls out of the agent's working set.
Common pitfalls
The first is exposing too many skills. A tool with thirty named skills gives the agent thirty options to choose between at planning time, which dilutes the choice quality. The right pattern is a small number of high-level skills that each compose lower-level operations internally. The agent picks "build prospect list with these filters" rather than "call search-endpoint, then call enrich-endpoint, then call dedup-endpoint."
The second is describing skills in terms of implementation rather than intent. "POSTs to the /v2/prospects endpoint with the org-scoped auth token" is useless to a model. "Returns a list of prospects matching the user's ICP filters and the optional signal trigger" is useful. The description should answer "when should I use this?" not "what does this call under the hood?"
The third is missing examples. A skill description without examples leaves the agent to infer the argument shape from the schema. A skill description with two or three worked examples lets the agent pattern-match. Examples are the single highest-leverage addition to a skill manifest.
The fourth is failing to declare side effects. A skill that sends a message, charges a card, or schedules a calendar invite has consequences the user needs to approve. A manifest that describes these as if they were read-only queries will lead to the agent firing them at planning time. The convention is an explicit requires_confirmation flag or equivalent, which the runtime can enforce.
How it shows up in agent-driven workflows
In Coil specifically, CLI capability manifests live in packages/cli/skills/ and are returned through coil agent-context --json. Runtime-native skills package the same operating guidance and API references for Codex, Claude Code, Hermes Agent, and OpenClaw. These are standalone agent-discovery artifacts, not an MCP server or MCP protocol integration.
This is intended to move toward parity with the web UI, but parity is not complete. Core source, lead, recipe-run, automation-run, export, and actor-scoped preference workflows have machine-callable surfaces; some admin and operator actions remain human-session or dashboard-first. The manifest documents the supported CLI surface rather than implying coverage it does not have.
The other reason the manifest matters is inspectability. Structured inputs and outputs make calls reproducible, and mutating routes with audit coverage attribute the human or machine actor. Durable source, recipe, export, and webhook records provide operation-specific evidence. Coil does not currently store every skill name, argument set, and result in a comprehensive browsable audit log.
For MCP sales buyers evaluating tools in 2026, the question to ask vendors is not "do you have an API." It is "do you ship a skill manifest, and what is in it." The answer tells you whether the tool was designed for agents or retrofitted.
Related concepts
MCP sales is the protocol that carries skill manifests across vendor lines. Without a protocol, manifests are tool-specific and the integration cost stays high.
Agent-driven outbound is the workflow pattern manifests enable. Without manifests, the agent has to guess. With them, the agent can plan.
Lead enrichment is a typical category of skill exposed in sales-focused manifests, often with multiple provider options the agent can choose between.
Sales Navigator scraping is another typical skill, and one where the manifest's requires_confirmation flag matters because the underlying action carries platform-TOS risk.
For Coil's own skill manifest set and how it works in practice, see the agent-driven lead gen pillar.
Frequently asked questions
How is a skill manifest different from an OpenAPI spec?
OpenAPI describes HTTP endpoints, parameters, and responses for human developers building integrations. A skill manifest describes named capabilities for an AI agent to choose between at runtime. The audience is a language model rather than a developer. The contents overlap but the framing differs, skill manifests emphasize when to use a capability over which HTTP verb to call.
Where does the skill manifest live?
Most commonly inside the tool's MCP server. The MCP protocol includes a discovery handshake where the server returns its skill list to the connecting agent. Some tools also publish standalone manifests as JSON files, which is useful for documentation and for non-MCP integration paths.
Do agents need a skill manifest?
Not strictly, a capable agent can read REST docs and figure out what to call. But the success rate is much higher with a structured manifest because the agent does not have to infer intent from prose. For production workflows the manifest is effectively required.