Jun 5, 2026ConnectPlatform

Claude and ChatGPT plug into Heyno, and Heyno connects the rest

One MCP server that exposes your whole working context to any model you already use.

The Model Context Protocol standardizes how models reach tools. Heyno ships an MCP server, which means the assistant you already use can work through your Heyno context instead of being wired to every app separately.

The N-by-M problem

Connecting M models to N systems directly is M×N pieces of integration, each with its own auth, its own permissions, and its own failure mode. Routing through one server that already holds the connections makes it M+N.

That is the entire architectural argument, and it is why the protocol exists.

Direct wiring is M×N integrations.
A shared server makes it M+N.

What the server exposes

Tools for your files, mail, calendar, contacts, tasks, memory, and business records: the same surface the assistant uses internally, with the same guardrails.

Read tools return cited content. Write tools are gated by the same approval policy that applies inside the product.

“Through Heyno: find the contract and quote the payment clause.”

Permissions travel with the tool

A model calling through MCP inherits the permissions of the person who authorized the connection. It cannot read what they could not read, and it cannot perform an action they could not perform.

Authorization is inherited from the person, not granted to the model.

Why route through Heyno

Because the context is already assembled. A model that reaches your drive directly sees files; a model that reaches them through Heyno sees files plus what was agreed about them.

M+NIntegration cost
InheritedPermissions
GatedWrite tools

Getting started

The server, the tool list, and the auth flow are documented in the MCP reference.

More in Connect

Keep reading

View all