Split.io MCP server: there is none, and Harness FME is the route

Why the splitio organization has no server, which thirteen resource types cover feature flags, and why one call can reach two different APIs.

Last verified 1 September 2026 · from The harness/mcp-server repository, the GitHub API and the hosted endpoint

This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.

What is the Split.io MCP server?

Split was a feature flag and experimentation platform. Harness acquired it, and it now ships under the name Harness FME. FME is the Harness name for the feature flag and experimentation product Split used to be. Flags, segments and traffic types are the same concepts under a new name.

Most MCP servers publish one tool per API endpoint. The Harness repository states why it does not: for a platform this broad that would mean 240 or more tools, and models get worse at tool selection as the count grows.

So the model sees eleven verbs, not hundreds of nouns. The agent calls harness_schema or harness_describe on a resource type first, then passes that resource type to harness_list, harness_get or harness_execute, and the server routes the call.

Where a Split question actually goes:

The repository states that passing both workspace_id and org_id or project_id on one call is an error, as is mixing org_id with project_id alone. Pick one mode per call.

Feature flags sit in release, and the wider Harness server reaches further than Split ever did.

Split.io lets an agent read and change a flag in one conversation, including killing it. Nothing in the FME resource set explains what the flag did to your metrics.

What can an AI agent do with Split.io?

What connecting costs before the first question

A context window is the amount of text a model can hold at once. Split publishes no server, so the measurement is of Harness FME, the connector that reaches Split's flags. Its tools cost 912 to 983 tokens on Claude.

Thirteen resource types are arguments to eleven tools, not thirteen extra tools. The tool list costs 912 to 983 tokens on Claude however many resource types exist.

Encodings: GPT-5.6, GPT-5.5 o200k_base; GPT-4, GPT-3.5 cl100k_base; Claude Haiku 4.5 to Opus 5 count_tokens. Counted from the 11 tool entries in the vendor's own documentation. That is the only public inventory.

The server could not be run for a live tools/list. So no input schemas are available. These figures cover each tool's name and description only. They are a floor, not the figure.

The Claude columns are measured through the API's count_tokens endpoint, with an empty schema per tool. So they cover the same content as the GPT columns. The range there is two tokenizer generations. Haiku 4.5 and Opus 4.6 sit at the low end. Opus 5 and Sonnet 5 sit at the high end. The gap between them is about a tenth.

Split.io MCP server limits: where answers come back incomplete

The first limit costs time before setup starts. There is no Split MCP server to find.

How to configure Split.io MCP for agents

1. 1

   Pick one scoping mode per call

   Legacy passes workspace_id, native passes org_id with project_id. Passing both is a documented error.

2. 2

   Expect a second credential in legacy mode

   HARNESS_FME_API_KEY is a Split admin key or an FME-entitled Harness token, because those calls go directly to api.split.io.

3. 3

   Set HARNESS_READ_ONLY for evaluation

   It blocks create, update, delete and execute, leaving only list and get.

4. 4

   Trim the toolsets

   Thirty-nine of forty are on by default. HARNESS_TOOLSETS accepts -name to drop defaults and +name to add the opt-in ansible set.

5. 5

   Watch the native-mode gaps

   fme_workspace is legacy-only, and native environment names are capped at 15 characters.

Paste this into your agent’s instructions

One tool name covers 240 resource types across two APIs, so the tool call alone does not say what happened or where.

When you answer using Harness FME MCP tools, state:
- The resource type you acted on, not only the tool name.
  harness_execute on fme_feature_flag is not the same as
  harness_get.
- Which scoping mode you used: workspace_id, which reaches
  api.split.io, or org_id with project_id, which reaches
  Harness.
- Whether the call changed a flag. kill, restore, reallocate,
  archive and unarchive all change live behavior.
Never state that data does not exist. State the resource type
and the scope you queried.
Write your answer in ASD-STE100 Simplified Technical
English. Use short sentences with one idea in each.

Do you need the MCP server at all?

Not for scheduled work. The Split admin API is unchanged and remains the direct route there, using the same admin key legacy mode needs.

For feature flags without the rest of a delivery platform, Flagsmith and Statsig both publish servers scoped to flags alone.

Where the question is which flag moved a metric, Statsig and Eppo answer it and no fme_ resource does.

If Harness is already your delivery platform, the 39 default toolsets make this one connection rather than several.

With MCP, a flag can be found, read and changed in one conversation, without the tab-switching the admin UI requires.

Filter the toolsets to feature-flags and set read-only first. Add writes when you know which resource types you need.

Split.io MCP server setup

There is nothing from Split to install. The connector is the Harness MCP server, available as a hosted endpoint at https://mcp.harness.io/mcp or run yourself over stdio, Docker or Kubernetes.

Every block below carries a Harness API key. The account ID is read automatically from a Harness personal access token or service account token, so no separate account setting is needed.

Legacy workspace_id calls need HARNESS_FME_API_KEY as well, because those requests go directly to api.split.io and Harness platform credentials do not authenticate them.

claude mcp add --transport http harness \
  https://mcp.harness.io/mcp \
  --header "Authorization: Bearer <harness-api-key>"

HARNESS_READ_ONLY=true \
HARNESS_TOOLSETS=feature-flags \
HARNESS_API_KEY=<harness-api-key> \
  harness-mcp-server stdio

{"mcpServers":{"harness":{"type":"http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

[mcp_servers.harness]
url = "https://mcp.harness.io/mcp"

[mcp_servers.harness.headers]
Authorization = "Bearer <harness-api-key>"

Every other client

Each block below is the configuration for one client, with the file path and the key that client expects.

HARNESS_API_KEY=<harness-api-key> \
HARNESS_FME_API_KEY=<split-admin-key> \
  harness-mcp-server stdio

{"mcpServers":{"harness":{
  "command":"harness-mcp-server","args":["stdio"],
  "env":{"HARNESS_API_KEY":"<harness-api-key>"}}}}

{"mcpServers":{"harness":{
  "httpUrl":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"servers":{"harness":{"type":"http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{
  "serverUrl":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"context_servers":{"harness":{
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{"type":"http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"amp.mcpServers":{"harness":{
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{"type":"streamableHttp",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

extensions:
  harness:
    type: streamable_http
    uri: https://mcp.harness.io/mcp
    headers:
      Authorization: Bearer <harness-api-key>

{"mcpServers":{"harness":{
  "command":"harness-mcp-server","args":["stdio"],
  "env":{"HARNESS_API_KEY":"<harness-api-key>"}}}}

{"mcpServers":{"harness":{
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{"type":"http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{
  "type":"streamable-http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

name: Harness
version: 0.0.1
schema: v1
mcpServers:
  - name: harness
    type: streamable-http
    url: https://mcp.harness.io/mcp
    requestOptions:
      headers:
        Authorization: Bearer <harness-api-key>

{"mcpServers":{"harness":{
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

{"mcpServers":{"harness":{"type":"http",
  "url":"https://mcp.harness.io/mcp",
  "headers":{
    "Authorization":"Bearer <harness-api-key>"}}}}

HARNESS_BASE_URL=https://harness0.harness.io \
HARNESS_API_KEY=<harness-api-key> \
  harness-mcp-server stdio

Read-only access, permissions and security

• An agent can kill a feature flag

  fme_feature_flag supports execute actions kill, restore, reallocate, archive and unarchive. A kill changes production behavior immediately.

• HARNESS_READ_ONLY is the mitigation, and it is off by default

  It blocks create, update, delete and execute, leaving list and get.

• Legacy mode holds a second credential

  HARNESS_FME_API_KEY is a Split admin key or an FME-entitled Harness token, and it authenticates directly against api.split.io.

• That variable is forbidden in multi-user mode

  The repository states it must not be set there, because FME must use each session's own credentials.

• Thirty-nine toolsets are on by default

  Feature flags arrive beside CI/CD, GitOps, Cloud Cost Management, Security Testing and Chaos Engineering. Those are toolset names, not tool names: the surface stays at eleven tools whatever loads. Filter with HARNESS_TOOLSETS if flags are all you need.

Troubleshooting

There is no MCP server in the splitio organization

Correct, and there was none on 25 August 2026. Split is Harness FME, and coverage comes from harness/mcp-server.

A call errors when it names both a workspace and a project

Documented. Passing workspace_id together with org_id or project_id, or mixing org_id with project_id alone, is an error. Pick one scoping mode per call.

`fme_workspace` returns nothing in native mode

It is legacy-only. The repository states there is no Harness-native equivalent, and that it exists to discover workspace_id values.

Creating an environment fails on the name

Native mode caps environment names at 15 characters. Native update is a JSON Merge Patch, so you send only the fields you change. name and isProduction cannot be cleared.

Legacy calls are rejected on the hosted endpoint

Those requests go to api.split.io directly, so hosted Harness credentials do not authenticate them. They need HARNESS_FME_API_KEY, which cannot be set in multi-user mode.

Too many unrelated tools appear

Thirty-nine of forty toolsets load by default. HARNESS_TOOLSETS accepts a comma-separated list, with -name to remove a default and +name to add the opt-in ansible set.

Split.io MCP server: Reference

What engineers report

The record here is the repository, which explains its own design decisions in unusual detail: 93 stars, MIT licensed, 11 tools across 240 resource types. Public discussion adds little to that.

“Most MCP servers map one tool per API endpoint. For a platform as broad as Harness, that means 240+ tools, and LLMs get worse at tool selection as the count grows. Context windows fill up with schemas, and every new endpoint means new code.”

“FME calls go directly to api.split.io, so hosted OAuth/service-routing credentials for Harness platform APIs do not authenticate these requests.”

“Block all mutating operations (create, update, delete, execute). Only list and get are allowed.”

The splitio GitHub organization was searched for MCP repositories on 25 August 2026 and returned zero results. Tool names, resource types and environment variables come from the harness/mcp-server README read on the same date, and the hosted endpoint was probed then too.

Should you connect an agent to Split.io?

Yes. Best for flag inspection and rollout questions, with HARNESS_TOOLSETS narrowed and writes gated.

Strongest fit

Teams already on Harness who want flags, pipelines and cost in one connection rather than several.

Main advantage

Eleven tools instead of hundreds, with a documented read-only switch and toolset filtering.

Main weakness

Split coverage is thirteen resource types inside somebody else's platform, split across two scoping modes with different capabilities.

Operational risk

harness_execute on fme_feature_flag can kill a flag in production, and read-only is off by default.

Frequently asked questions