---
canonical: https://docs.jentic.com/guides/mcp/remote-mcp/
representation: markdown-alternate
# Canonical page: https://docs.jentic.com/guides/mcp/remote-mcp/
# This is the Markdown alternate of the page above.
title: "Connect Agents to Jentic over Remote MCP"
description: >-
  Connect your AI assistant to the Jentic remote MCP server to search, load, and execute
  over 10,000 APIs with managed credential vaulting and just-in-time tools.
---

# 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.

```json
{
  "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:

  ```json
  {
    "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.

  ```json
  {
    "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](../../getting-started/quickstart.md) 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

- [Claude Desktop / Claude Code](./claude-desktop-remote.md)
- [ChatGPT](./chatgpt.md)
- [Cursor](./cursor-remote.md)
- [Windsurf](./windsurf-remote.md)

## Support

- **Discord:** [https://discord.com/invite/TdbWXZsUSm](https://discord.com/invite/TdbWXZsUSm)