Yekar.AI as an MCP server

This endpoint lets the assistants your team already works in use your Yekar.AI workspace. A client that speaks the Model Context Protocol can:

• ask your published agents - each one is a tool;
• start, follow and continue conversations, and approve or reject an action an agent is waiting on;
• build agents - create one, edit its draft, check it and publish it, choose its knowledge and manage its triggers;
• write knowledge - create knowledge modules and draft articles;
• look things up - your domains, agents, knowledge bases, conversations and the integrations you can use;
• fire your API triggers;
• do anything else you can do in Yekar.AI - flows and runs, the approvals inbox, connections, domains, the knowledge library, evals, modules and settings - through two general tools, with the Everything you can do in Yekar.AI permission.

Everything it does, it does as you, with your permissions in Yekar.AI.

POST https://api.yekar.ai/api/public/v1/mcp

The transport is Streamable HTTP: one POST carries every JSON-RPC method. The address, the tools it currently serves and the apps you have connected are all on Triggers → API keys.

Two ways to connect

You use	How it signs in
The Claude or ChatGPT app	You paste the server URL and sign in to Yekar.AI
Claude Code, Cursor, VS Code, Copilot CLI, Codex CLI	A personal API key in a request header

Developer tools that support signing in through OAuth can use either.

Claude and ChatGPT: add a connector and sign in

1. In the app, add a custom connector (in ChatGPT, a connector in developer mode) and paste the server URL above. You don't need a key.
2. The app opens Yekar.AI. Sign in if you aren't already, and pick the workspace if you belong to more than one.
3. Yekar.AI shows which app is asking and what it will be able to do. Choose Allow.

The app appears under Triggers → API keys → Connected apps, where you can disconnect it at any time. Disconnecting stops it straight away. Their setup screens move; when this page and a vendor's own documentation disagree, theirs is right.

What the app can do is decided on that consent page, using the same permissions as an API key:

Permission	Lets the app
MCP server	See and ask your published agents. Always included.
Run agents	Start and continue conversations, read them, and approve or reject actions you are allowed to decide.
Build agents, integrations and knowledge	Create agents and edit their drafts, publish them, manage their triggers, and write knowledge.
Fire triggers	Fire your API triggers.
Everything you can do in Yekar.AI	Do anything else you can do in Yekar.AI, except the actions listed under What an app can never do.

An app that asks for nothing in particular is offered all five. One that asks for less is offered what it asked for, plus MCP server. Every permission on offer starts ticked except Everything you can do in Yekar.AI, which you tick yourself if you want the app to have it - the same as for a key. You can change any of them, except MCP server, on the consent page before you choose Allow.

Developer tools: a personal API key

Create a key under Triggers → API keys with MCP server ticked. MCP server on its own gives the client your published agents. Tick Run agents, Build agents, integrations and knowledge, Fire triggers or Everything you can do in Yekar.AI as well to add those tools. Everything is never ticked for you: a new key, and a key created before permissions existed, do not have it unless you choose it. A key expires like every key (90 days by default), so note the date before you hand it to a client.

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

claude mcp add --transport http yekar https://api.yekar.ai/api/public/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.

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/public/v1/mcp",
      "headers": { "Authorization": "Bearer yk_…" }
    }
  }
}

What the client sees

Three kinds of tool.

Your agents. 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. Each takes a message (up to 8,000 characters) and an optional conversationId to continue an earlier conversation. The tool's description is the agent's own description, edited on the agent's page - it is what a calling model reads when it decides which agent to reach for, so one plain sentence about the job beats an internal label. Renaming an agent renames its tool.

Yekar.AI's own actions. One tool for each operation of the public API, with the same inputs, limits and checks, so a tool and its API route always agree:

Area	Tools
Conversations	list_agent_sessions, start_agent_session, read_agent_session, post_agent_message, approve_agent_turn
Agents	list_domains, list_agents, create_agent, update_agent_setup, verify_agent_setup, publish_agent_setup, set_agent_knowledge_selection
Triggers	list_agent_triggers, create_agent_trigger, update_agent_trigger, delete_agent_trigger, fire_trigger
Integrations	search_integrations, read_integration, list_integration_connections
Knowledge	list_knowledge_bases, list_knowledge_modules, create_knowledge_module, create_knowledge_article, add_knowledge_module_article

Reads are marked read-only and deletes destructive, so a client can decide what to confirm with you. tools/list is the source of truth, and the list on Triggers → API keys shows each tool with the permission it needs.

Everything else, with the Everything you can do in Yekar.AI permission. Two tools reach the rest of the product, rather than hundreds of separate tools that would crowd an assistant's tool list:

• search_yekar_operations finds an action. Called with no words it lists the areas (Automations, Domains, Org knowledge, Sessions, Evals and so on); with words it returns matching actions, each with its id, method, path and the shape of what it takes.
• call_yekar_operation runs one, as you, through the very route the product uses. Every permission check, approval, audit entry and error message is that route's own.

New product actions appear in the search the day they ship.

A few behaviours worth knowing:

• Drafts first. update_agent_setup changes the draft; nothing changes what runs until publish_agent_setup, which can also choose how the Procedure runs (procedureMode: free_text or structured) and otherwise keeps the draft's mode. New triggers start switched off.
• Agent calls never take caller credentials. A tool runs the agent on its domain's connections, as the API does when no caller credential is sent.
• Errors are readable. A bad argument or a refusal comes back as a tool error naming the field or the reason, so the assistant can correct itself.

Waiting, approvals, and other non-answers

The tools that talk to an agent - ask_<agent>, start_agent_session, post_agent_message and an approving approve_agent_turn - wait 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 (the answer names the action and its approval id);
• waiting on another agent it called;
• waiting for an answer to a question it asked its caller.

When the agent uses an integration its domain has not connected yet, the answer also lists each one with the link where an owner of the agent's domain connects it - the agent cannot use those tools until then.

The assistant can relay that and call again with the same conversation, or check with read_agent_session. A write that needs approval still needs it here, from someone allowed to decide it: MCP is another way in, not a way around.

What an app can never do

A connected app acts as you, but some acts are kept for you to do in Yekar.AI yourself. These are the acts where an assistant steered by something it read - an email, a web page - could do harm you would not see coming:

• Create keys or tokens - an API key, or a key rotation.
• Enter or change secrets - connection credentials, model-provider keys, OAuth app settings, encryption keys, storage.
• Change who has access - inviting or changing members, domain membership, approver policy, permissions, support access, single sign-on, hosting.
• Make payments - checkout, subscriptions, billing details.
• Send data elsewhere or delete it - webhooks to an outside address, workspace exports, retention windows, scheduling the workspace's deletion.
• Sign in, or connect another app.

Everything else - running and approving your agents' work, building agents and flows, triggers, knowledge, evals, modules, connection settings - is open to the app, within your own permissions. An action the app is refused comes back with the reason.

Permissions

A connected app and an API key both act with their 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.

• The agent tools follow current domain membership. They list published agents only in domains you currently belong to.
• Every call is permission-checked when it runs, by the same check as the product and the API. A tool's presence in the list does not grant permission to use it - for example, starting a conversation needs execute access in the agent's domain, and publishing needs edit access.
• Conversations keep their privacy rules. Continuing one needs participation in it; the same session rules apply as in the product.

A call with no credential, or one that has expired or been revoked, gets 401 with a WWW-Authenticate header pointing at the sign-in metadata - which is how the Claude and ChatGPT apps find where to sign in.

Connected apps end when your sessions do. Changing or resetting your password, changing your sign-in email, or choosing Sign out of all devices disconnects every app you connected, in every workspace. API keys are not affected. An admin disabling or removing you from a workspace disconnects your apps there too, and turning you back on does not reconnect them.

Changes an app makes are recorded. Each change made through call_yekar_operation adds an AI app made a change entry to the audit log, beside the action's own entry, naming whether a key or a connected app made it and which one.

Searching conversations matches titles and agent names, never what was said in them. list_agent_sessions reads conversations with credentials removed, so a search of their contents could reveal what the read hides.

Organization owners and admins see every member's connected apps under Settings → Connected apps, and can disconnect one they don't recognise.

Workspaces on their own infrastructure work the same way. Sign-in stays with Yekar.AI, and each call is answered by the workspace's own server, with the same tools and checks.

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.
• No notifications/tools/list_changed. Clients re-read tools/list rather than being told to.
• No server-to-client streaming. A call answers on its POST, so tokens do not stream into the client as the agent produces them.
• No file uploads or downloads. Actions that take a file or send one back (uploading a knowledge document, downloading an export) stay in Yekar.AI; the search does not offer them.

The protocol version advertised is 2025-06-18.

The other direction

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