Launch Week 3Check the new features

Learn more

How we build the Openfort MCP Server

9 min read

How we build the Openfort MCP Server

The motivation behind building the Openfort MCP Server comes from the desire to streamline developer onboarding and enable AI-powered project scaffolding with minimal human intervention. Traditional onboarding flows require developers to read documentation or configure projects manually, and understand the platform before building anything meaningful. Our MCP approach aims to invert that experience.

We architected the MCP Server with two guiding principles:

  1. Speed up initial development and scaffolding

    The primary design goal was to allow developers (or AI agents acting on their behalf) to create, configure, and scaffold full projects without needing to manually navigate the dashboard. By exposing project and resource management tools (like creating keys, policies, contracts, etc.) directly to the LLM, we allow developers to go from zero to prototype in minutes.

    To support this, we also incorporated tool-based code snippets that provide product-specific scaffolding, currently featuring [OpenfortKit](React SDK – Openfort Documentation) for rapidly bootstrapping React + Vite applications.

  2. Provide precise and focused context
    Rather than relying on generic documentation search or bloated RAG, our MCP acts as a query-aware context provider. It can fetch the exact snippets of documentation, code examples, and configuration references that are relevant to the user's current query, project state, or LLM gaps in knowledge. This feedback loop enhances reasoning and reduces hallucination.

Features

Most state-of-the-art MCP solutions are primarily used as wrappers around documentation and API calls.

APIs

Their main function is to allow AI assistants to invoke internal API functions provided by the tool provider. This enables AI agents to perform specific, actionable tasks, such as creating or fetching tables in database platforms.

Documentation

When it comes to documentation, traditional Retrieval-Augmented Generation (RAG) techniques typically extract context from an entire documentation corpus. In contrast, MCP documentation search acts as a focus-directed retrieval system. Instead of overwhelming the model with the full documentation, the MCP allows the AI to query for highly relevant, targeted context. Clearly superior to RAG systems.

Other

Some MCPs offer highly specific, niche capabilities aligned with the core services of their providers.

Openfort's MCP

The included tools are tailored specifically for Openfort’s context. Unlike typical database services, exploration tools were considered unnecessary here. Users don’t need to create tables or fetch data directly through chat (most of the time). Instead, the dashboard provides a more suitable interface. The MCP tools are designed for LLMs to help scaffold and develop projects, rather than to inform users or let them perform actions via the chat.

The MCP Server provides three main tool categories to interact with the basic Openfort functionalities:

  1. Context – Fetch real‑time documentation and code snippets to scaffold projects.
  2. Management – Create and initialize new projects.
  3. Project – Control all the details within a specific project.

The set of 42 tools included in the MCP Server are the following. Providing more than 50 tools is considered to be overwhelming for the models and many don't even support it.

Context

Documentation

Initialization

  • create-openfortkit-app: Provides a guide to the LLM on how to create a React + Vite app using Openfort Kit.

Management

Projects

  • list-projects: List all your projects.
  • get-project: Get details of a specific project.
  • create-project: Create a new project.
  • select-project: Sets a project as active. Subsequent project-specific actions will apply to the selected project.
  • show-selected-project: Show currently selected project by the Agent.
  • deselect-project: Deselect the project.

Keys

  • get-publishable-keys: Get public project keys.
  • get-secret-keys: Get secret project keys.
  • get-shield-publishable-key: Get shield public key.
  • get-shield-secret-key: Get shield private key.
  • create-publishable-key: Create new public key.
  • create-secret-key: Create new secret key.
  • create-shield-keys: Create public, private, and encryption shield keys.

Project

Policies

  • list-policies: Retrieves a list of all policies associated with the selected project.
  • create-policy: Creates a new policy for your project.
  • get-policy: Fetches details of a specific policy.
  • update-policy: Updates an existing policy with new information.
  • delete-policy: Removes a specified policy from your project.
  • disable-policy: Disables a policy without deleting it.
  • enable-policy: Re-enables a previously disabled policy.
  • list-policy-rules: Lists all rules associated with a specific policy.
  • create-policy-rule: Adds a new rule to a specified policy.
  • update-policy-rule: Modifies an existing rule within a policy.
  • delete-policy-rule: Deletes a specific rule from a policy.

Contracts

  • create-contract: Creates a new contract for the selected project.
  • get-contract: Retrieves details of a specific contract.
  • list-contracts: Lists all contracts associated with the selected project.
  • update-contract: Updates the details of an existing contract.
  • delete-contract: Removes a specified contract from your project.

Users

  • create-user: Creates a new user in the project.
  • get-user: Get detailed information about a specific user in the project.
  • list-users: Get the users in the project.
  • update-user: Update an existing user's information.
  • delete-user: Delete a user from the project.

Accounts

  • create-account: Creates a new blockchain account for the provided player. If no player is provided, a new one will be created.
  • get-account: Get detailed information about a specific account in the project.
  • list-accounts: Get the accounts in the project with optional filtering.

Transactions

  • list-transactions: Lists all transactions associated with the selected project.
  • get-transaction: Retrieves details of a specific transaction.
  • simulate-transaction: Simulates a transaction to check validity and expected fee.

Installation & Usage

The user can easily plug and play the MCP Server by simply filling the platform-specific config file mcp.json in their editor with the standarized content.


_11
{
_11
"mcpServers": {
_11
"openfort-mcp": {
_11
"command": "npx",
_11
"args": [
_11
"mcp-remote",
_11
"https://mcp.openfort.io/sse"
_11
]
_11
}
_11
}
_11
}

Authentication is triggered immediately, allowing the user to identify as an Openfort user through Supabase OAuth using GitHub, Google, or email/password.

Once authenticated, the user can interact with the AI assistant through chat or prompts. The LLM will automatically invoke the appropriate MCP tools on behalf of the user when needed.

However, LLMs often forget about the availability of MCP tools. To mitigate this, prompts include explicit references to these tools, and Rules have been added to help remind the model to use them.

Once installed, the main use cases lie on:

  • Creating projects without needing to set anything up in the dashboard.

  • Fetching data from your users, policies, transactions.

  • Scaffolding projects quickly.

  • Automatically allow the LLM to create policies, contracts and wallets.

  • Fetching the documentation on real-time.

Architecture

Deployment

Running the MCP Server locally using stdio was discarded as a suitable option due to several limitations:

  • More complex setup for end users

  • No centralized monitoring or logging

  • Tool updates cannot be easily broadcasted across local instances

On the other hand, when using a remote server, the one-off comunication pattern using HTTP provides latency and overhead. Also, the MCP needed to incorporate some sort of state. Connections related to the same topic should be maintained open and the MCP should keep track of the project API keys somehow to make the calls to Openfort.

The Cloudflare MCP infrastructure has been used. It provides out of the box deployment and has native support for Server-Sent Events  (SSE). This allows applications to directly push data to clients and avoid buffering, similar to WebSockets but only server-to-client.

Cloudflare

The Cloudflare infrastructure also provides the workers-oauth-provider library, an OAuth2.1 Provider that makes authorization possible. This means solving the problem of having to pass to the LLM the API keys directly from the chat for every session or having to store them on a .env file. This also means that the MCP can now create Openfort projects for the user and there's no need to enter the dashboard at any time.

The authentication is performed using the pkce flow (see image below), so it's fully server-side. Here, the Supabase OAuth has a second layer of authentication that is nicely handled thanks to the custom implementation using the workers-oauth-provider library.

Also, the McpAgent SKD  handles the transport and provides state so during a session, the AI Agent can store the API keys from a selected project and make all the subsequent API calls affect that project, avoiding manual API keys input from the user once again.

Finally, it uses mcp-remote, an adapter that lets MCP clients that otherwise only support local connections work with remote MCP servers.

Structure

The source code structure is very simple.

handlers Stores the OAuth handlers with a single handler for the Supabase OAuth. It's customly designed to fit the Openfort auth flow.

utils Mainly HTML forms for the authentication prompt.

tools Stores the tools divided by the commented categories.

index.ts Initiates the MCP Agent instance and registers all the tools and the authenticator.

Limitations

The current state of Openfort's MCP still poses some limitations:

  • The protocol itself is still in early stages, that means it comes with some inherent limitations. For example, the return format from the MCP Server to the MCP Client must always be text, so JSONs had to be stringified, sometimes causing confustion to the the LLMs.

  • The output still depends a lot on the LLM. That means it's highly non deterministic and can hallucinate or commit errors.

  • It's also very sensitive to the prompt, one sentence can make the LLM not use the appropiate tool and cause the resulting code not to run.

  • The MCP only works for test projects, there's no implementation for the live mode yet.

  • There's a lot of hype but most scaffolding from AI builders is nearly hardcoded. The LLMs work on a a very specific tech stack (usually React+Vite) and can't build projects from absolute scratch.

  • Most AI Builders don't allow custom MCP Servers so right now it's limited to code editors and IDEs that support it.

Resources used

Share this article