Loading ToolBench
MCP server for Harness FME (Split.io) — read and toggle feature flags.
The server has 10 tools with reasonable naming conventions (verb_noun pattern) and input schemas that are visible and typed. However, descriptions are present but often quite brief (20-60 chars), lacking the depth needed to guide LLM selection. Most tools lack explicit output schema documentation. Parameter descriptions are present but minimal. Error handling is basic, errors return simple messages without recovery guidance or categorization. The tooling demonstrates competent API wrapping but falls short of production-grade LLM-optimized definitions.
Create a new feature flag in a workspace.
Get details of a specific feature flag by name.
Get the definition of a feature flag in a specific environment.
Assemble a Harness FME web-UI deep-link for a flag in an environment. Accepts workspace/flag/environment by name or id.
Kill (disable) a feature flag in a specific environment. Requires explicit confirmation.
List environments for a workspace.
Output schemas not documented. Tools return JSON responses but no schema is specified in tool definitions. LLMs cannot predict what fields to expect or plan downstream operations.
Descriptions are too brief (20-70 chars). Most descriptions lack context on WHEN to use the tool vs. similar tools, WHAT the tool returns, or any prerequisites. Examples: 'List environments for a workspace' (34 chars), 'Get details of a specific feature flag by name' (46 chars). Best practice is 50-200 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | 2026-07-28+ | v2 |
List feature flags (splits) in a workspace with optional filtering and pagination.
List workspaces with pagination support.
Restore (re-enable) a previously killed feature flag in a specific environment.
Update metadata of a feature flag (description, tags, owners, rollout status).
Error handling lacks recovery guidance and categorization. Functions return bare error messages like 'failed to fetch workspaces' without indicating whether the error is retryable, user-fixable, or fatal. No suggestions for alternatives (e.g., 'environment not found, try list_environments() first').
Destructive tool 'kill_feature_flag' accepts a 'confirm' boolean parameter but lacks explicit dry-run support. If the agent omits the confirmation or passes false, the tool silently fails with no error message or guidance. Better pattern: require confirm=true or return a detailed confirmation prompt first.
Parameters could be more descriptive. Many parameter descriptions are single sentences lacking format/constraint details. E.g., 'The workspace ID' does not specify format (UUID, alphanumeric, etc.). Parameter descriptions should include format, valid ranges, and constraints inline.
API key injected via environment variable MCP_HARNESS_FME_API_KEY (correct pattern). However, missing documentation in tool descriptions or README about required environment variables and setup. Operators cannot discover that the server requires this variable without reading source code.
get_flag_url tool requires MCP_HARNESS_FME_ACCOUNT_ID and MCP_HARNESS_FME_ORG_GUID environment variables (source code shows these checked at runtime), but the tool description does not mention this dependency. Tool will fail silently if these are not set, providing no guidance to the operator.