When we started building our MCP server, it began as a simple hackathon project: take our existing CLI interface, which already has authentication and most of our API calls, and adapt it to work as an MCP server.

As a hackathon project, it turned out to be a pretty compelling demo with some strong use cases. With just the hackathon version, agents could create new feature flags, investigate incidents, clean up stale flags, and help with QA, all with natural language. We thought the demo was cool, but it was rough around the edges and failed regularly; we knew it would take quite a bit of iteration to make it production-ready.

Key Takeaways and Learnings

To get the MCP server from hackathon "working" code to a shippable product took a lot of learning through trial and error. Below, are the key learnings from that process.

Create Clear Input Schemas

Good input schemas that properly define your API are critical. The input schemas (and descriptions) are your AI agent's primary context when deciding which tool to call and the data to call the tool with. AI agents can infer reasonably well from the input schema, but in certain places, .describe() statements on your schema parameters will help push the AI agent in the right direction.

For example, if you have a search field that can accept a generic string input, adding a search.describe('Search term to filter features by "name" or "key"'), will help steer the AI Agent to only use name or key values in the search.

Without a good input schema, we found that AI agents would regularly try to use the wrong tool, causing errors or even taking the agents down unintended paths.

Descriptive Errors Make up for Most Sins

Bad error handling can break everything. The AI agent will fail as soon as it runs into an error without a very descriptive error response. Most of the time, it will just start hallucinating new data to fix the error and get into circles, chasing its own tail. Conversely though, good, descriptive error responses can solve for a lot of other problems with your MCP. If you provide detailed error responses from your APIs, that are helpful, the agent can generally one-shot fix issues in its chain of reasoning.

We assumed that creating DevCycle Features through our MCP interface, due to the large and complex Features API, wouldn't be usable. We thought the AI agent would hallucinate its way through creating features, making illogical decisions. But we were surprised that with a detailed input schema + good descriptive error responses (such as the example below), AI agents could consistently get to the right result.

Yes, the agent may need to iterate through an error or two for API rules that cannot be covered by the JSON schema, but they had an extremely high success rate generating features with complex targeting rules all through a natural language interaction with the MCP tool.

{
  "errorType": "UNKNOWN_ERROR",
  "errorMessage": "Expected type of value for variable 'include-metadata' to be Boolean, but received String",
  "toolName": "create_feature",
  "suggestions": [],
  "timestamp": "2025-08-27T14:58:17.701Z"
}

Limit the Number of Tools

Pruning your tool calls is essential; not every API function you have makes sense to be available as an MCP tool call, and every new MCP tool eats up more of your AI context window. We had to ask ourselves, do we think someone really wants/needs to be able to delete whole projects from an MCP tool call? Once we got past the initial excitement of giving agents the ability to do anything, we quickly realized actions like that were highly unlikely to be done via agents.

Counter-intuitively to API best practices, larger tool call surfaces that can combine multiple API functions into a single MCP tool call are preferable. It reduces the number of tools your MCP needs to expose and likely reduces the amount of AI context you are using up to describe your MCP tools. Many AI Agent platforms restrict the number of MCP tools installed, or at least warn users if they are using too many, meaning that if you want your MCP actually to be used, you should minimize the number of tools your MCP server exposes.

MCP OAuth is Easier with Cloudflare Workers

Getting the authentication to work well for an MCP server is hard; as a new standard, figuring out how to properly authenticate with your existing systems can be challenging (should you use API Keys, JWT, OAuth???). We found that using Cloudflare Workers + Durable Objects to host the remote MCP server made the OAuth implementation mostly painless. We also found that managing the OAuth session state in a Durable Object for all of a user's requests is a good, scalable solution for us.

The power of using durable objects is that it also lets you store other session state data. For example, we store which DevCycle project you are interfacing with for the MCP, and have tool calls that let you select between different projects in your organization. That means on all further tool calls, say to list features in a project, your AI agent doesn't need to keep track of what project you are querying for, your MCP session has already selected a project, and we have stored that state in the Cloudflare Durable Object to use for listing all the features.

Remote MCP Servers Are Easier and Safer

Remote MCP servers are easier and safer for users to install; you just need to set a URL, and you're up and running. If you are using OAuth for authentication, your users use a web-standard authentication API through which you can properly scope the permissions your MCP server has access to.

{
  "mcpServers": {
    "DevCycle": {
      "url": "https://mcp.devcycle.com/mcp"
    }
  }
}

The somewhat common practice for local MCP servers of providing an npx -y some-mcp-script to install a local MCP server with full access to your computer's file system is rife with security concerns, compared to an HTTP / SSE-based remote MCP server, scoped using permissions and time-scoped OAuth tokens.

Be Careful With Context Size and Output Schemas

Output schemas can help provide more context to the AI when it chooses which tool call to make. However, the token cost of large output schemas is likely not worth the minimal benefit, when most of the output's context can be provided with a simple statement in the tool call's description. If you choose to set output schemas, keep them as a high-level description of the first layer of output parameters with short descriptions of the deeper parameters.

The Real Value of MCP Tied to Developer Workflows

To be honest, I was initially skeptical of the value of most MCPs, they never natively fit into my AI development workflows, I could get documentation by just pasting a link in my chat. But after using our new MCP for a while, it has become obvious that there is real value in an MCP server that directly interacts with your code development workflow, versus just providing information to an AI agent.

The most popular MCP servers to date have mostly been informational interfaces to project management tools (think: Linear / Notion / Github), or documentation (Context7), and these MCPs certainly have their value, but the daily use cases as a primary interface feel limited.

By building MCP tool calls that are directly involved in the code-writing process, when you ask your AI Agent to "wrap this new functionality in a DevCycle flag" as part of a regular every-day prompt to do a simple task you may have done manually in the past, your AI agent now not only has the context on how to implement that flag properly, it will automatically fetch the existing variable's type/default value/schema for that flag, or create a new variable and feature for you in DevCycle, and self-target you into that flag to initially test it locally.

These types of workflows, extending the functionality of coding tasks you are already doing with your AI agent, quickly become a native interface you don't need to think about using. And more than that, while MCP may not be perfect, it can actually make for a better overall experience with our platform as a developer, where you can stay in code and context.

Example Workflows

Some of the example workflows and prompts we have discovered so far are:

Quickly Creating a Feature in DevCycle for a New Variable in Code

Create a new feature in DevCycle for the flag "new-flag"

These feature creation prompts are great for quickly creating a feature in DevCycle and keeping you in the flow of your code editor. At the same time, you work on implementing your new feature, letting you set up a simple feature based on the flag in your code without needing to set anything up in the DevCycle dashboard.

Self-Targeting Into a Feature for Local QA

Self-target me into this devcycle feature flag

By making it so easy to quickly target yourself into a newly created DevCycle feature flag, it again keeps you in the flow of developing your new feature in your code editor and makes one of the most useful tools in the DevCycle platform that much more accessible to developers' local development workflows.

Promoting a Feature From Development to Staging

Enable this devcycle feature in staging for all users

This allows you to quickly promote an existing feature you have set up and have been testing in a lower environment, like a local or development environment, to a higher-level environment, like staging.

Testing in Production for All Internal Users

Enable this feature in production for all internal users with "@devcycle.com" emails

Again, a common internal practice for us here at DevCycle is testing all new production features by targeting internal users. This can be done with a simple email filter or an existing saved audience.

Identifying If an Error Is Related to a Feature Flag:

Is this error we are seeing in prod controlled by a devcycle variable? If so, turn off the feature.

When debugging errors, one of the first tools you should look to is what feature flags were recently deployed or enabled. With the DevCycle MCP, you can quickly ask if there are any changes across all of your feature flags that are related to a known stack trace or error in your code.

Cleaning Up Stale Feature Flags:

Cleanup all the features marked as stale by devcycle

A recent feature we've built at DevCycle helps you identify features in your project that are stale (haven't been changed or evaluated in a while) and should be cleaned up in your code. Our MCP tool calls include data about whether we have marked the feature as stale, making it easy to use your AI agent to clean up these flags.

This is an area where we think AI can be particularly helpful, given the common problem of letting stale flags build up in a codebase...

Archiving DevCycle Features That Don’t Exist in Your Code Anymore.

Review all devcycle features and list any that don't have any devcycle variables in this codebase to be archived

Sometimes you start creating a feature flag but don't end up finishing the job. Maybe it was a POC or maybe you just got started creating a flag during a scoping meeting. AI has all of the context necessary to quickly and easily archive Features that never got used.

Next Steps With DevCycle’s MCP

Another investigation led us to develop AI prompts for instructing AI agents on how to install DevCycle and OpenFeature SDKs into applications and set up the first feature flags. In a future blog post, we'll detail how we're reimagining our product onboarding around this MCP installation flow with real-time feedback. As a team that has built SDK-based SaaS services for over a decade, this approach addresses two persistent challenges: getting customers to install and update SDKs and streamlining the onboarding process.

Developing these MCP tools taught us a key lesson for creating effective AI agent-based workflows: prioritize integrations that enhance the daily activities of your platform. For us, that's clearly creating, managing and decommissioning feature flags. And so far, MCP is making it easier and safer to stay in flow and manage flags.

Read more about the DevCycle MCP Server.

About DevCycle

DevCycle is the first OpenFeature‑native feature flag management platform - so you can ship faster without vendor lock‑in. The MCP server extends that developer‑first experience right into your AI tools.