Capability overview
Actions vs Integrations vs MCP vs Skills — what they are, when to use each, and why they're not the same thing.
Operators are useful only insofar as they can do things. Four layers in Guilde give them capability. They look similar. They're not.
The TL;DR
- An action is a single tool method an operator can call right now.
- An integration is the installer — the OAuth flow, the credentials, the metadata that brings a provider's actions into your guild.
- An MCP server is one kind of integration: a remote tool catalog exposed over the Model Context Protocol.
- A skill is a named, distributable bundle of prompt + actions + examples an operator can be hired with.
Mental model: integrations install actions; skills compose actions.
Actions — the flat verb surface
Every action your operators can run lives on /actions. One row per tool
method, grouped by provider, searchable, filterable by "active" (wired to an
operator) vs "all".
Built-in actions ship out of the box: Browser, Canvas, Knowledge, Vault,
Work Items, Team Management, Web Research, Routine Scheduler, Self
Capabilities, Content Creation, Design Kits, etc. Marketplace actions add
on top — connect a GitHub MCP server and you get 90 more (actions_get,
actions_list, add_comment_to_pending_review, etc.).
→ See Actions.
Integrations — how actions arrive
/integrations is the installer. Browse the catalog, click Install,
authenticate (OAuth or paste an API key), the integration registers its
actions into your guild's flat action surface.
Integrations come in three flavours:
- HTTP — REST APIs (HubSpot, Stripe, Linear, …)
- MCP — remote tool catalogs (GitHub MCP, Smithery skills, your own MCP server)
- Built-in — first-party providers (Browser, Canvas, Workspace, …)
→ See Integrations and MCP servers.
MCP servers — one kind of integration
The Model Context Protocol is the open standard for exposing tools to AI. An MCP server is anyone — you, a vendor, a community — that publishes tools at an MCP endpoint. Guilde treats MCP as a first-class integration flavour: hook one up and its tools appear in the Actions list with no custom wiring.
Use MCP when:
- The capability you want isn't covered by a first-party integration
- You're publishing your own internal tools to be used by AI
- You want a community MCP server (filesystem, browser, GitHub, …)
→ See MCP servers.
Skills — named, distributable recipes
A skill is a bundle of prompt + instructions + examples + (usually) a
set of actions an operator can call. The catalog is browsable from
/skills; install with one click; operators invoke the skill by name.
If actions are verbs and integrations are suppliers, skills are playbooks: "SEO audit", "Cold-outbound", "Run a daily standup". Skills make hiring trivial — install a skill, the operator that owns it gets sensible defaults out of the box.
→ See Skills.
Picking among them
| Need | Use |
|---|---|
| See what an operator can do right now | Look on Actions |
| Wire a third-party SaaS into the guild | Install an Integration |
| Use an open-source / vendor toolset | Pick an MCP integration |
| Hire an operator pre-wired for a specific outcome | Install a Skill |
| Package & distribute your own capability | Skill on top of actions |
In practice you use all four: integrations bring in the connectors, MCP adds long-tail tools, skills pre-compose them into named loadouts, and Actions is the live, searchable index of everything an operator can call.
What's next
- Actions
- Integrations
- MCP servers
- Skills
- Runtimes — the where actions run