Connect anything
The capability pool: MCP servers, imported skills, public APIs, and your own packages — four on-ramps to one contract.
Every playbook in this section eventually hits the same question: how do I
give an agent this one capability? Neuralis answers with one contract and
four on-ramps. The pool on the other side is effectively the whole software
world: 1,400+ public APIs in community directories like publicapis.dev,
thousands of MCP servers (claudemarketplaces.com alone indexes 8,700+),
tens of thousands of importable agent skills across marketplaces like
ClawHub, and every GitHub repository that ships a .claude/ or .cursor/
folder. If it has an API, an MCP server, or a connector shape — an agent can
work with it.
On-ramp 1: attach an MCP server
The fastest path for anything that already speaks MCP. Add the server on the agent's settings and its tools appear next to the built-ins — no code, no install. The official CoinGecko server in the research desk playbook is the canonical example: public endpoint, no key, working in minutes. MCP runs in both directions here — Neuralis also serves its own capabilities to external clients over the same protocol.
On-ramp 2: import skills you already have
A skill written for Claude Code, Cursor, or any agentskills.io-aligned tool loads in Neuralis unchanged — the frontmatter parser is whitelist-tolerant by design. Two import paths:
- Sync a repository that carries a
.claude/,.cursor/, or.github/folder: it becomes a source package, no install step at all. - Drop a skill folder into a project's
_packages/directory — a bareSKILL.mdfolder is a valid one-skill package.
This is what "universal package consumer" means in practice: the skill ecosystems' output is your input.
On-ramp 3: wrap a public API in a skill
For the long tail — every service with a REST API and no MCP server yet — a skill with a small script is the workhorse:
---
name: send-campaign
description: Sends a prepared campaign through the mailing provider's API.
credentials:
- MAILER_API_KEY
---The declared credential is resolved from the encrypted store at activation — scoped to platform, project, user, or agent — and projected only into that script's environment. The agent gets the capability; it never sees the key. The package carrying the skill stays sandboxed and untrusted; the capability works anyway.
On-ramp 4: build a package
When the capability is the product — your own tools, widgets, connectors,
a whole vertical — write a package against
the package system: WASM-sandboxed in a project's
_packages/, or admin-installed for first-party trust. The
software team playbook can do this work
inside Neuralis itself; the
contract examples are the templates
— one per install class.
Choosing the on-ramp
| The capability is… | Use |
|---|---|
| A service with an MCP server | Attach it (on-ramp 1) |
| A skill that exists in some marketplace or repo | Import it (2) |
| A service with only an HTTP API | Wrap it in a skill + credential (3) |
| Something nobody has built yet | Build the package (4) |
Whatever the on-ramp, the governance is identical — feature gates, URI policies, credential scoping, audit — because everything lands on the same contract. That is the point of the protocol: the integration effort is spent once, by whoever builds the capability; every team after that just hires it.