AI-Perceivable

Build once, invoke by code or AI.
A protocol-neutral runtime that keeps schema validation, ACL, approval, and execution evidence consistent across agent and code surfaces.

English · 中文

Documentation · Getting Started · Protocol Spec · aiperceivable.com

A tool schema tells a model how to format a call. It does not say who may make that call, what it may touch, whether a human must approve it first, or what record survives afterwards.

Those questions do not belong inside the model's reasoning loop. They belong at the execution boundary — and they must be answered the same way regardless of which protocol carried the request.

MCP tells an agent what it can call. apcore decides whether this call — with these arguments, in this environment, by this identity — should happen at all, and leaves evidence that it did.

                  ┌──────────────────────────────────────────┐
                  │     Agent  ·  Human  ·  Application       │
                  └────────────────────┬─────────────────────┘
                                       │
          ┌──────────┬──────────┬──────┴────┬──────────┬──────────┐
          ▼          ▼          ▼           ▼          ▼          ▼
       ┌─────┐   ┌───────┐  ┌───────┐   ┌──────┐   ┌───────┐  ┌────────┐
       │ MCP │   │  A2A  │  │  CLI  │   │ HTTP │   │OpenAI │  │ direct │
       └──┬──┘   └───┬───┘  └───┬───┘   └──┬───┘   └───┬───┘  └───┬────┘
          └──────────┴──────────┴─────┬────┴───────────┴──────────┘
                                      ▼
              ╔═══════════════════════════════════════════════╗
              ║              apcore runtime                   ║
              ║   schema · ACL · approval gate · middleware    ║
              ║          observability · audit trail          ║
              ╚═══════════════════════┬═══════════════════════╝
                                      ▼
                  ┌──────────────────────────────────────────┐
                  │      your existing business logic        │
                  │              (unchanged)                 │
                  └──────────────────────────────────────────┘

Three steps, and only the first one touches your code:

1. Bind — a decorator, or a YAML binding file for code you cannot annotate
2. Expose — the same registered module is projected through whichever adapters you enable
3. Execute under governance — validation, identity, ACL, approval, and audit run before and after your logic, identically on every surface

Define a governed capability once. Project it onto any surface. The guarantees do not weaken when the transport changes.

This is the most common question, so it is worth answering directly: apcore is not an alternative to MCP. MCP defines client-server communication and tool metadata. apcore addresses a different boundary — defining and executing an application capability consistently before it is exposed through MCP or anything else.

Use MCP directly when a protocol server is all you need. Add apcore when the same business capability must retain validation, access, approval, and audit semantics across MCP, A2A, CLI, HTTP, and direct code.

The same logic applies upward: apcore is complementary to LangChain, LlamaIndex, CrewAI, and AutoGen rather than competing with them. Those frameworks orchestrate calls between capabilities; apcore standardizes what an individual capability is and what happens when one is invoked.

apcore solves how to build modules (a module standard), not how to call tools (a communication protocol).

pip install apcore          # Python
npm install apcore-js       # TypeScript
cargo add apcore            # Rust

New to the project? Read What is apcore? first — it explains the module standard before any SDK detail.

Adopt incrementally. Define and test one application operation in the native SDK. Add an MCP or CLI adapter only after its validation, ACL, approval, and evidence paths are clear. One governed capability is a better starting point than a full migration.

apcore is a protocol specification. Each language is an independent implementation, kept honest by a shared cross-language conformance suite rather than by shared code.

One module, projected onto a different protocol. Each surface is specified once and implemented three times.

Scan the code you already have. No rewrite, no parallel definition to keep in sync.

apcore is open source and maintainer-led. The contributions that help most are the ones that strengthen conformance, the supported adoption path, or verified documentation.

Every repository is Apache-2.0. The core project follows OpenSSF Best Practices.

• Contributing guide · Code of Conduct
• Governance · Scope · Roadmap
• Security policy

The most useful contributions are the uncomfortable ones: a conformance case where two languages disagree, an authorization semantic the spec left ambiguous, or a surface where the governance guarantees quietly do not hold. Open an issue.