@kud/mcp-harness-fme
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HARNESS_FME_API_KEY | Yes | Your Harness FME API key |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workspacesA | List all FME workspaces in the account |
| list_environmentsA | List all environments in a workspace |
| list_feature_flagsC | List feature flags in a workspace |
| get_feature_flagA | Get metadata for a specific feature flag |
| get_flag_definitionA | Get the targeting rules and treatment definition of a feature flag in a specific environment |
| kill_feature_flagB | Kill (disable) a feature flag in an environment — forces all traffic to the default treatment |
| restore_feature_flagA | Restore (re-enable) a killed feature flag in an environment |
| create_feature_flagC | Create a new feature flag for a given traffic type |
| update_feature_flagC | Update a feature flag's description, tags, or owners (partial update) |
| delete_feature_flagB | Permanently delete a feature flag from a workspace — irreversible |
| list_flag_definitionsA | List all feature flag definitions (targeting rules) in a specific environment. Full definitions are large; pass summary: true to get name/id only when you just need to locate a flag. |
| get_flag_urlA | Build a deep-link to a feature flag's definition in the Harness FME web UI. Pass workspace, flag, and environment by name or id — the org slug, project, flag id, and env id are resolved for you. Requires MCP_HARNESS_FME_ACCOUNT_ID and MCP_HARNESS_FME_ORG_GUID env vars on the server (those IDs are not exposed by the API — copy them once from a flag URL in the browser). |
| add_segment_to_treatmentA | Add a segment to a specific treatment of a feature flag via read-modify-write — safer than update_flag_definition's full replace, where a dropped field silently removes existing targeting. Idempotent: a no-op if the segment is already on the treatment. For workspaces where list_workspaces reports requiresTitleAndComments: true, pass title (and comment). |
| create_flag_definitionA | Create (activate) a feature flag definition in a specific environment with treatments and targeting rules. For workspaces where list_workspaces reports requiresTitleAndComments: true, pass title (and comment) or the API rejects the write with a 400. |
| update_flag_definitionA | Fully replace a feature flag definition (treatments, targeting rules) in an environment. For workspaces where list_workspaces reports requiresTitleAndComments: true, pass title (and comment) or the API rejects the write with a 400. |
| delete_flag_definitionA | Remove a feature flag definition from an environment — the flag itself remains, but loses its targeting rules in that environment |
| list_segmentsC | List all segments in a workspace |
| list_traffic_typesB | List all traffic types in a workspace |
| list_rollout_statusesA | List rollout status definitions for a workspace (e.g. Killed, Permanent, Ramping) — use the returned IDs to filter feature flags by rollout status |
| archive_feature_flagA | Archive a feature flag — removes it from active use while preserving history. Subject to OPA policy checks (409 on failure). |
| unarchive_feature_flagC | Unarchive a previously archived feature flag, restoring it to active use |
| list_rule_based_segmentsB | List all rule-based segments in a workspace |
| get_rule_based_segmentB | Get a rule-based segment's workspace-level metadata by name |
| create_rule_based_segmentB | Create a new rule-based segment in a workspace under a specific traffic type |
| delete_rule_based_segmentA | Permanently delete a rule-based segment from a workspace — environment-level configs must be removed separately |
| list_rule_based_segment_definitionsB | List rule-based segment definitions in a specific environment |
| update_rule_based_segment_definitionC | Update a rule-based segment definition in an environment (rules, exclusions, matchers) |
| enable_rule_based_segment_definitionB | Enable (activate) a rule-based segment in a specific environment — creates an empty definition that can then be configured via update |
| disable_rule_based_segment_definitionA | Disable (remove) a rule-based segment from a specific environment — workspace-level metadata is preserved |
| create_rule_based_segment_change_requestA | Submit a change request for a rule-based segment definition — supports approval flow via approvers |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 30 tools
Most tools have distinct purposes, but potential overlap exists between add_segment_to_treatment and update_flag_definition, and among the various segment list tools (list_segments, list_rule_based_segments, list_rule_based_segment_definitions). Descriptions help clarify, but an agent might still misselect.
All tool names follow a consistent verb_noun pattern in snake_case, e.g., create_feature_flag, list_environments, update_flag_definition. No mixing of conventions.
With 30 tools, the set is slightly over the typical well-scoped range (3-15), but it covers a complex domain (feature flag management with many sub-resources). Each tool seems justified, though some granularity could be reduced.
The tool set provides comprehensive CRUD and lifecycle operations for feature flags, segments, environments, workspaces, and more. Includes advanced operations like rollback, change requests, and deep-links. No obvious gaps for the intended domain.