Yekar.AI as an MCP server

Your agents are already reachable from the product, from triggers, and from the API. This endpoint makes them reachable from the assistants your team already works in: a client that speaks the Model Context Protocol lists your published agents as tools and calls them like any other tool.

The key is the whole configuration. There is nothing to install and nothing to register.

POST /api/v1/mcp
Authorization: Bearer yk_…

The transport is Streamable HTTP: one POST carries every JSON-RPC method. Create the key under Triggers → API keys, where the endpoint and the tools it currently serves are also shown.

Which clients can connect

Yekar.AI authenticates with your personal API key in an Authorization header, so any client that lets you set a request header works today. Clients that instead drive an OAuth sign-in cannot hold a yk_ key - see Clients that cannot connect yet below.

Client	How you add it	Their documentation
Claude Code	claude mcp add --transport http … (below)	Connect Claude Code to tools via MCP
Cursor	An HTTP entry in .cursor/mcp.json (project) or ~/.cursor/mcp.json (global)	Model Context Protocol
VS Code (Copilot)	An HTTP server entry in .vscode/mcp.json, or MCP: Add Server	MCP configuration reference
GitHub Copilot CLI	copilot mcp add --transport http …	Adding MCP servers for GitHub Copilot CLI
Codex CLI	A bearer_token_env_var or http_headers entry in its MCP config	Model Context Protocol

Their setup screens move; when this page and a vendor's own page disagree, theirs is right.

Claude Code

claude mcp add --transport http yekar https://api.yekar.ai/api/v1/mcp \
  --header "Authorization: Bearer yk_…"

Add --scope user to make it available in every project, or --scope project to commit it to .mcp.json for your team - in which case put the key in an environment variable rather than in the file.

Everything else

Most other clients take a config block of this shape. Use the file and key name your client documents - VS Code uses servers rather than mcpServers, for example - and keep the url and the Authorization header:

{
  "mcpServers": {
    "yekar": {
      "type": "http",
      "url": "https://api.yekar.ai/api/v1/mcp",
      "headers": { "Authorization": "Bearer yk_…" }
    }
  }
}

Clients that cannot connect yet

The Claude desktop and web apps' custom connectors, and ChatGPT's developer-mode connectors, both authenticate a remote MCP server through OAuth - ChatGPT's documentation states plainly that it cannot present a custom API key. Yekar.AI does not run an OAuth authorization server for this endpoint, so those two cannot hold a yk_ key and cannot connect today. This is a missing feature on our side, not a configuration you can work around: adding OAuth would change that, and until it does, use one of the clients above.

What the client sees

One tool per agent with a published Setup, named ask_<agent name> - lowercased, with runs of other characters collapsed to underscores. Two agents whose names reduce to the same slug are each given a short id suffix, so both stay addressable.

Each tool takes:

Field	Required	Meaning
message	Yes	What to ask the agent (up to 8,000 characters).
conversationId	No	Continue a previous conversation. Omit to start a new one.

Every reply carries its conversation id back, so a client can hold a thread instead of opening a new session per call. That id is the session id - the same conversation your team can open in Yekar.AI afterwards, with its full transcript, tool calls and audit trail.

An agent's tool name follows its name: renaming the agent renames the tool. tools/list is the source of truth, and clients re-read it.

The tool's description is the agent's own description, edited on the agent's page. This is worth a minute of thought: it is what a calling model reads when it decides which of your agents to reach for, so one plain sentence about the job ("Answers where-is-my-order questions from order and fulfilment data") beats an internal label. An agent with no description falls back to Ask the "<name>" agent. It replies in this conversation., which is honest and tells a model nothing.

Waiting, approvals, and other non-answers

A call waits up to 90 seconds for the turn to settle. If it does not, the tool still answers - in readable text, never a protocol error - saying what the agent is doing and carrying the conversation id:

• still working;
• waiting for a person to approve a write it wants to make;
• waiting on another agent it called;
• waiting for an answer to a question it asked its caller.

The calling assistant can relay that to its user and call again with the same conversationId. A write that needs approval still needs it here: MCP is another way in, not a way around.

Permissions

The bearer is an ordinary personal API key, and it acts with its owner's authority - the same rule as the rest of the API. Nothing about this endpoint is a separate service identity, and no permission exists here that its owner does not already have.

Two halves of that are worth stating separately:

• The tool list follows current domain membership. It shows published agents only in domains the key's user currently belongs to. Removing a membership removes those agents from discovery and name resolution.
• The call is permission-checked. Starting a conversation with an agent requires execute access in that agent's domain, checked at call time. A tool's presence in the list does not grant permission to run it. Invalid keys return 404; missing domain permission on a known agent can return 403 FORBIDDEN.

Continuing an existing conversation also requires participation in that session: its creator/recorded owner or a domain Operator, Editor or Owner, with current domain membership. A visible conversation without participation permission returns 403 SESSION_NOT_DRIVABLE. The same session privacy rules apply as in the product.

What this server does not serve

Named rather than left to be discovered:

• Tools only. No resources, no prompts. The initialize response advertises only tools, so a well-behaved client will not go looking.
• No notifications/tools/list_changed. Clients re-read tools/list rather than being told to.
• No server-to-client streaming. GET /api/v1/mcp is not served; a call answers on its POST, so tokens do not stream into the client as the agent produces them.
• Agents only. Flows are not exposed as tools; fire those through an API trigger.
• No OAuth. The endpoint takes a personal API key and nothing else, which is what limits it to the clients listed above.

The protocol version advertised is 2025-06-18.

The other direction

This page is about Yekar.AI serving your agents to an MCP client. To go the other way - letting your agents call tools on someone else's MCP server - see Custom integrations & MCP.