Loading ToolBench
This MCP server provides 18 tools for Wingify feature flag management with mixed quality. Most tools have basic descriptions and input schemas, but there are systematic gaps: (1) Parameter descriptions are sparse or missing type hints; (2) Output schemas are not documented anywhere in the visible code; (3) Error handling is minimal, tools return generic error strings without actionable recovery guidance; (4) Many parameter names are ambiguous (e.g., 'sdk' is passed to every tool but never described); (5) Tool descriptions lack WHEN-to-use context that LLMs need for selection. The server follows a consistent BaseTool pattern and uses Zod schemas, but the schemas themselves are not visible in the source provided, making validation of actual schema completeness impossible. Tool naming is acceptable (verb_noun style with 'Get', 'Create', 'Delete', 'Update', 'List'), but composition is weak, several tools operate on the same resources without clear disambiguation (e.g., GetFeatureFlag vs GetFeatureFlagRule).
Add Wingify FE Rules
Create a new feature flag
Create a single or multiple feature flag rules
Create a new ready-to-use feature flag with smart default values
Delete a feature flag
Delete a feature flag rule
Find unused or stale Wingify FE feature flags in the codebase
Output schemas are not documented. No tool provides an explicit schema for what data is returned. LLMs cannot plan multi-step workflows or extract required fields for downstream tool calls.
The 'sdk' parameter is ubiquitous across all tools but is never described. What is an 'SDK identifier'? Is it a version string, a namespace, an API key? LLMs will guess or pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
List Wingify Data360 events for the account. Use customEventsOnly to return only custom (non-standard) events.
Get details of a specific feature flag by ID or key, including its configuration, variables, variations, rules, and associated metrics
Get details of a feature flag rule
Get the complete list of all available data360 metrics that can be used across the entire Wingify account (not specific feature flag data)
Integrate the Wingify FE SDK code
List all feature flag rules per environment
List all feature flags
Toggle a feature flag
Toggle a single or multiple feature flag rules
Update a feature flag
Update a feature flag rule
Error responses are generic strings (e.g., 'Failed to fetch events: [error]'). No recovery guidance, no error classification (retryable vs. fatal), no actionable next steps for the LLM.
Destructive tools (DeleteFeatureFlag, DeleteFeatureFlagRule) have no confirmation/dry-run support. An agent could permanently delete flags without review.
Many parameter descriptions are trivial or missing type/format hints. E.g., 'featureRule' is described as 'Feature rule configuration' but the actual structure is not documented. LLMs cannot construct valid payloads.
Tool names contain ambiguous pairs: GetFeatureFlag vs GetFeatureFlagRule, CreateFeatureFlag vs CreateFeatureFlagRules, UpdateFeatureFlag vs UpdateFeatureFlagRule. No clear descriptions of when to use each.
No pagination limits are stated in tool descriptions. List tools (ListFeatureFlags, ListFeatureFlagRules, GetEvents) accept limit/offset but do not specify maximum safe values. Agents could request 10,000 items, blowing context windows.
Tool descriptions lack WHEN-to-use context. E.g., 'List all feature flags' does not explain whether to call this for discovery, for validation, or for analytics. LLMs waste reasoning cycles.
Parameters like 'environmentIdOrKey' and 'featureIdOrKey' suggest the tool accepts both IDs and names, but no description explains how to provide each or what format they must be in.