Skip to content
Docs

Console MCP

Run your account from Claude, Codex or another MCP assistant: connect, sign in, choose an account, and what it can do.

Stop 8 of 8
On this page9 sections

Console MCP

Console MCP lets you run your Gydr account from an AI assistant that supports the Model Context Protocol (MCP): Claude Desktop, claude.ai, Claude Code, Codex and other clients. You ask in plain words, and the assistant builds and tests widgets, manages knowledge bases, Skills and data forms, and reads conversations to find what to improve, through the same Console checks you already work under.

It is available on the Growth plan and above. Every request runs as the person who connected it, with exactly the permissions their role (or custom permission set) gives them in the account they are working in.

Not the MCP connector Plugin

Console MCP is for the people who operate the account: Gydr is the MCP server and your assistant is the client. The MCP Connector Plugin is the opposite direction: it lets your chatbot call a remote MCP server you run. They share nothing, and connecting one does not affect the other.

Connecting an assistant

Every client needs the same address. You do not create or paste a key: the client signs you in through your normal Gydr login.

Shell
https://mcp.console.gydr.ai/mcp
  • Claude Desktop and claude.ai. Open Settings, then Connectors, choose Add custom connector, and paste the address.
  • Claude Code. Run:
Shell
claude mcp add --transport http gydr-console https://mcp.console.gydr.ai/mcp
  • Codex and other clients. Add a remote MCP server (the streamable HTTP kind) with the same address. The client opens your browser to sign in.

The client registers itself automatically. A client whose sign-in returns to a custom app address (for example one that starts with cursor://) cannot connect yet: Console MCP only accepts https addresses and addresses on the same computer (localhost).

Signing in and choosing an account

When the client first connects, a Gydr page opens in your browser. You sign in with your Gydr login, then see a consent page that names the app asking, the address it will return to, and your email. If you belong to several accounts, tick every account the assistant may work in (at least one); the first one you tick is where it starts. Accounts whose plan does not include Console MCP are shown but cannot be ticked. Choose Allow to connect, or Deny to refuse.

If none of your accounts is on the Growth plan or above, you see a refusal instead of a picker.

Switching accounts

A connection may use the accounts you allowed, and works in one of them at a time. The assistant can tell you which with whoami, list your accounts (and which ones it may use) with list_accounts, and move between the allowed ones with switch_account. Asking it to move to an account you have not allowed is refused. Each connection keeps its own account: switching in one app never moves another app, and never changes the account your open Console tab is using.

Every tool that changes something requires an accountId, and it must be the account the connection is working in. A mismatch is refused, naming both accounts, and nothing changes. The assistant never switches on its own to make a call succeed. Every result begins with the name of the account it ran in.

What the assistant can do

Area
Account
Tools
whoami, list_accounts, switch_account
Area
Knowledge bases
Tools
List, get, create and update a knowledge base; start a sync; products, FAQs and locations (list, create, update, delete, turn on or off in bulk, add or update up to 100 at once); documents (list, create one from text, list chunks, add, correct or delete a passage, process, delete)
Area
Skills
Tools
List, get, create, update, clone and delete
Area
Widgets
Tools
List, get, create and clone; list, read, add and edit saves (drafts, with every design option typed); send a test message to a draft or the live widget; publish; turn a widget on or off
Area
Data forms
Tools
List, get, create, update and delete form definitions
Area
Conversations
Tools
List, search, get, read messages (archived ones too, with each reply's insight on request) and analytics; see which desk took a conversation, its ticket ids and how the handover ended; hand a stuck handover back to the assistant; read topics; report a reply that went wrong
Area
Integrations, plugins and channels
Tools
List and get (secrets and header values hidden); see what each desk, plugin and channel supports; change a desk's or CRM's settings (Live Support and Ticket modes, team name, required details, what happens when no one is free, takeover and hand-back switches, lead export) and a plugin's settings — never a credential or the address it is sent to; test a desk's or plugin's stored connection; list an MCP Connector's tools; see channel replies waiting to be delivered

Widget edits go into a draft save and reach visitors only after the assistant publishes it; it can test the draft first. Knowledge edits reach the chatbot after a sync. A Skill has no draft: a change reaches every live widget that uses it, so the assistant asks you first. Tools the signed-in person's role does not allow are hidden from the assistant, and the Console still refuses anything not permitted.

Why a reply came out as it did

Ask for a conversation's messages with insight on (and every test message) and each reply comes with its insight: what the assistant searched for, which of your knowledge items it found (each a strong or a weak match), and what shaped the reply, such as nothing found, a question judged off-topic, a reply corrected because your knowledge did not support it, a visitor who needed to sign in, or a person who was not available. That is enough to see what to add to a knowledge base or a Skill. It never shows how Gydr works inside.

It also shows what each search did with your custom attributes: every attribute filter the assistant asked for and whether it was applied or ignored (an attribute no knowledge base defines, or a value that does not fit it), the items an exclusion attribute kept from that visitor with the note that did it, and a category that matched nothing and was widened. So when a visitor says the assistant suggested the wrong thing, or never suggested the right one, the assistant can find the attribute to fix. The visitor's own filter values are never included.

What is deliberately left out

Some things are done in the Console only, on purpose.

  • Secrets and exit routes. API keys, webhooks, sign-in sources and integration keys. A webhook is also a way to send data out, so a session that reads visitor text must not be able to create one.
  • People. Team members and ownership transfer.
  • Exports. Data-form rows, transcripts and topics hold visitors' personal data.
  • Deleting a whole knowledge base or widget.
  • Creating integrations, plugins and channels, and their credentials. Connecting one involves secrets and browser sign-in steps, so it is done in the Console; the assistant can change their other settings and gives you a link to the right Console page.
  • File uploads, including logos, avatars, product images and document files. A product can show an image from a web address, and a document can be created from text.
  • The website crawler. Your AI app can read a page of your website itself and add its questions, products, locations or the page itself as a document, in your own words; to import a whole site, use the crawler in the Console.

Credits

Each tool call uses credits from the account it runs in: from 2 credits for a read and 3 for a change; large or slow requests use more. They appear on their own Console MCP line in your usage. Failed calls caused by Gydr are free, and so is a call refused for the account's plan or credits: it is refused before anything is sent when the account does not have enough credits or its payment is overdue. A call the Console turns down because of what was asked (a field it does not accept, a permission the person does not have) uses the minimum for its kind. Work the Console already bills, such as a sync or document processing, is billed on its own line exactly as it is in the Console.

The app's other requests on the connection, such as starting a session, listing its tools or renewing its sign-in, use from 1 credit each, on the same line. Connecting an app uses a few credits from the account you choose, once, when you select Allow; the consent page shows the exact number, and an account that cannot cover it is told so before anything is connected.

Disconnecting an app

Open Settings, then Connected Apps. Each row shows the app, the account it works in and how many more it may use, where it runs, when you connected it and when it was last used, with the most recently used app first. Open a row's menu (⋮) and choose Edit accounts to add or remove accounts: the change applies to the app's next request, with no need to reconnect. Choose Revoke to disconnect it at once: the app can no longer act, and connecting again asks you to sign in and consent again. Each person sees and changes only their own connections. Resetting your password, or being removed from the team, also stops a connection.

Security notes

  • Conversation text is untrusted. Messages are written by your website visitors. Conversation tools return them inside a labelled “visitor-written content” envelope, and the assistant is told to treat it as data to read, never as instructions.
  • Your assistant never holds your Console login. It holds only a Console MCP token that works at the Console MCP address and nowhere else.
  • Changes are audited. Requests made through Console MCP are recorded in the audit log with the name of the app that made them.
  • Review before you approve. Check the app name and the address it returns to on the consent page. Connect only apps you trust.