Invokta

The domain outcome is the durable asset

If your MCP tool or CLI command creates a specification, retrieves project context, guides a workflow, reviews code, or classifies a ticket, it already contains the core of an Action Engine.

The reviewed specification, selected context, next safe step, or classified ticket is what consumers depend on. MCP, CLI, HTTP, and direct APIs are delivery paths to that outcome.

Teams often build each delivery path separately. The first integration ships, then the next consumer needs its own schema conversion, authentication, error mapping, cancellation, logging, and tests. Protocol upgrades and business-rule changes must be kept consistent across every copy.

An Action Engine gives the domain action one owned, versioned boundary. The model, prompt, provider, data source, and interface can change while consumers continue to use the same validated contract.

What Invokta provides

Define a capability once with its input, output, access rule, and execution behavior. Invokta applies the same invocation pipeline from application code, the CLI, MCP stdio, and stateless MCP Streamable HTTP.

Stable contracts

Validate input and output at runtime and publish the same schema information through every adapter.

One execution path

Every adapter calls engine.invoke, keeping validation, authorization, cancellation, errors, and events in one pipeline.

Delivery adapters

Invoke the engine directly, expose a local CLI, or publish MCP tools over stdio and bounded stateless HTTP.

Supporting tools

Check capability composition, inspect supported local MCP client targets, and prepare reviewable HTTP deployment artifacts.

Your engine owns the outcome

Domain contracts, business rules, prompts, models, data integrations, authorization policy, evaluations, and outcome quality stay in the engine you build. Invokta does not provide an identity provider, model router, agent harness, workflow engine, or production observability platform.

The smallest useful engine

import { createEngine, defineCapability } from "@invokta/core";
import { z } from "zod";

const greet = defineCapability({
  description: "Create a welcome message for a new team member.",
  input: z.object({ name: z.string().trim().min(1) }),
  output: z.object({ message: z.string() }),
  access: "public",
  async run({ input }) {
    return { message: `Welcome, ${input.name}!` };
  },
});

export const engine = createEngine({
  name: "hello-engine",
  version: "1.0.0",
  capabilities: {
    "onboarding.create-welcome-message": greet,
  },
});

The capability ID belongs to the engine map. The capability contains the contract and implementation that every entry point reuses.

Build the complete example

Choose your next step

Explore complete engines

Browse example engines for specifications, context retrieval, code review, image production, observability, and support operations.

Follow a practical recipe

Use a runnable recipe for dependency injection, domain authorization, capability composition, or an external provider.

Understand the boundary

Read about Action Engines and the capability contract.

Look up the API

Use the @invokta/core reference and the error taxonomy while implementing an engine.