Glide has opened its app-building environment to external AI agents through a new Model Context Protocol server. Instead of moving between an assistant and GlideOS, users can now ask a compatible client such as Claude, Cursor or ChatGPT to create and modify Glide apps while the agent calls Glide's tools directly.
The connection covers more than generating a first draft of an interface. Glide says agents can work with spreadsheets, load data, build app components and maintain connectors. They can also use the platform's built-in database and calculated views, giving an assistant access to the same underlying building blocks that a person would assemble inside GlideOS.
The builder moves into the agent conversation
MCP provides a standard way for an AI client to discover tools and exchange context with another service. Glide's server turns GlideOS into one of those services. A user can remain in an agent conversation, describe the software they want and allow the agent to call the appropriate Glide functions as the work develops.
That changes the starting point for no-code development. A blank canvas is no longer mandatory: the first interaction can be a request to an assistant that already understands the user's goal. The agent can translate that request into app structure, data operations and follow-up edits, while Glide remains the runtime and application platform.
The launch does not mean every MCP client behaves identically. Each assistant brings its own planning, model capabilities and interface, and Glide supplies the tools those assistants are permitted to use. Results will therefore depend on both sides of the connection, as well as the clarity of the instructions and the organisation's existing data.
The connection carries the user's access
A connected MCP client signs in as the Glide user and inherits features available on that person's organisation plan. This makes the integration useful without creating a separate, reduced Glide environment, but it also means the agent operates within real account boundaries rather than an isolated demo space.
Glide provides action-level permission choices so users can decide when approval is required. Those controls are central to the release. An agent that can load data, change an app or maintain a connector needs a clear boundary between actions it may perform automatically and those a person should inspect first.
The MCP server address is available from the organisation sidebar under MCP Server. Because that address helps connect an AI client to the user's workspace, teams should handle it as account configuration rather than casual public information. Authentication still takes place through the supported connection flow.
Claude, Cursor and ChatGPT take different routes
Glide documents separate setup paths for the major clients. For Claude, an owner of a Team or Enterprise account adds Glide as a custom connector. Cursor uses an MCP configuration file in the project. ChatGPT requires developer mode, a custom connector and an OAuth sign-in.
Those differences reflect how each client currently implements MCP; they are not different versions of GlideOS. Once authenticated, the shared idea is the same: the assistant can see the tools Glide exposes and use them within the permissions attached to the connection.
The release may be especially useful for people who already conduct planning or coding work in one of these clients. They can keep requirements, data questions and app changes in a single working conversation instead of manually copying an answer into a separate builder. For less technical users, the agent can also provide a conversational path into structures such as calculated views that might otherwise require more platform familiarity.
Two providers, two sets of usage costs
The integration joins services rather than combining their billing. Glide says tokens consumed by the external agent are managed and charged by that agent provider. Glide credits continue to apply when the work uses GlideOS Runtime AI, workflows or integrations.
That split is easy to miss during experimentation. A single instruction may prompt the external model to reason over the task and then trigger operations that consume Glide resources. Organisations evaluating the connection will need visibility into both accounts to understand the full cost of repeated agent-led building.
It also places responsibility for model choice outside Glide. A team can select an MCP client that suits its workflow, but the external provider controls the model's token usage and may apply its own account limits or administration. Glide controls the app tools and runtime operations on its side of the connection. The two layers need to be considered together when access is granted.
Starting with approval prompts for consequential changes gives organisations a way to observe how an agent interprets requests before allowing more automation. The point is not that every action needs permanent manual review, but that permissions can be widened after the team understands which Glide operations a chosen client is likely to invoke.
Glide's MCP launch makes its no-code tools available inside a wider agent ecosystem without replacing the Glide workspace, database or plan controls. The result is a more flexible front door to app development: the conversation can happen wherever the user prefers, while execution remains tied to the user's Glide organisation and permissions.