Skip to content

Connecting agents to Jentic over MCP

Search the public directory in the cloud. Inspect and execute against your own registry.

Jentic exposes its capabilities to agent runtimes over the Model Context Protocol (MCP) in two complementary shapes. They are designed to be used together:

  1. Hosted MCP server (discovery, no install) — a Jentic-hosted MCP endpoint your agent can point at with no setup, to search the public Jentic API directory in natural language and find the operation that fits a use case before you've installed anything.
  2. Self-hosted Jentic One (full loop) — your own deployment, wired into your runtime as a custom MCP connector, driving the full search → inspect → execute loop against your registry with your credentials.

1. Hosted MCP server — natural-language discovery

The hosted MCP server lets an agent search the Jentic API directory using natural language and get back concrete API operations — before any deployment exists. Ask "find an operation that creates a GitHub issue" and it returns matching operations from the public catalogue, each with the identifiers you need to go deeper.

Use it for discovery: figuring out which API and which operation solves a task. It reads the public directory; it does not touch your registry, your credentials, or execute anything against your upstreams — that is what a self-hosted Jentic One instance is for.

{
  "mcpServers": {
    "jentic": {
      "url": "https://api.jentic.com/mcp"
    }
  }
}

No token to configure — the hosted server uses OAuth (Dynamic Client Registration), so the client registers itself and prompts you to authorize on first connect. Just the URL is needed.

2. Self-hosted Jentic One as a custom connector — search → inspect → execute

A self-hosted Jentic One instance gives your agent the full capability set against your own registry: search your imported operations, inspect an operation's full contract, then execute it. (The hosted server searches the public directory for discovery before you've installed anything; your instance searches your registry and can carry an operation all the way through to execution.) Credentials are decrypted only inside your Broker at execution time, so they never touch your prompts.

The two integration paths most agents use are:

  • Local jentic mcp stdio server (the default) — your runtime spawns it as an ordinary stdio MCP entry. The CLI is bound to your own instance through its context (base_url / broker_url), so it talks to your self-hosted control plane, authenticates as the agent's registered identity, and the agent's key stays on the local machine. It does not require the hosted /mcp endpoint to be enabled. (The jentic mcp subcommand ships with recent CLI releases — run jentic mcp --help to confirm yours has it.)
  • Hosted /mcp Streamable HTTP endpoint — a URL-based custom connector on your deployment's control plane, for headless agents, other machines, or runtimes that can't spawn a process. It is off by default and enabled by the operator (server.mcp.enabled: true).

Both speak the same tool surface and are contract-tested against each other, so an agent gets identical results whichever transport its runtime uses. (Jentic One also ships lower-level transports — a jentic mcp --http local daemon and a jentic mcp --connect stdio relay — for advanced self-hosting; see jentic mcp --help.)

How the hosted /mcp endpoint authenticates

The endpoint supports two auth modes, and which one applies depends on how the operator configured it:

  • OAuth (no token to paste) — if the operator also set server.mcp.oauth.enabled: true, the endpoint speaks OAuth with Dynamic Client Registration, exactly like the hosted directory server. A URL-only client registers itself and authorizes on first connect; the self-registered client waits for operator approval (instant if auto_approve_clients: true). Config is just the URL:
{
  "mcpServers": {
    "jentic": {
      "url": "https://<your-jentic-one-host>/mcp"
    }
  }
}
  • Manual bearer — with only server.mcp.enabled: true (OAuth off), the endpoint is bearer-only: the client must supply the agent's token per request.
{
  "mcpServers": {
    "jentic": {
      "url": "https://<your-jentic-one-host>/mcp",
      "headers": { "Authorization": "Bearer <agent-api-key>" }
    }
  }
}

The agent's bearer comes from registering it against your instance (jentic register / jentic setup, which perform RFC 7591 Dynamic Client Registration and mint the tokens for you). Ask your operator which mode the deployment runs. See the Quickstart to stand up an instance, register an agent, and grant it access.

The tools an agent gets over MCP

However it connects, the agent drives the same loop. The hosted server answers the discovery steps against the public directory; a self-hosted instance answers all of them against your own registry:

Step MCP tool What it does
Identity whoami Report the calling agent's identity, status, scopes, and toolkit bindings.
Search search_apis Find API operations by natural-language query (e.g. "create github issue"); each hit carries the operation_id.
Inspect inspect_operation Fetch an operation's full contract — method, URL, params, request/response schemas, security — before executing.
Execute execute / execute_read Run the operation through the Broker, which injects the stored credential server-side; credentials never pass through the session.

A self-hosted instance additionally exposes search_catalog and import_api (find and pull public APIs into your registry), request_access (file a human-approved provisioning plan), and get_execution_result (poll a held execution).

Per-runtime guides

Support