PostHog
fix(mcp): allow feature flag arrays to use operators beyond in/not_in
Problem
Fixes issue #145 in the standalone MCP repo (now moved to monorepo).
The MCP server was incorrectly rejecting feature flag property filters when using the exact operator (and other string operators) with array values. This prevented users from creating feature flags like:
{
"key": "email",
"value": ["[email protected]", "[email protected]", "[email protected]"],
"operator": "exact"
}
The validation logic was too restrictive, only allowing in and not_in operators with arrays, even though PostHog's API supports arrays with many more operators.
Solution
Updated the PersonPropertyFilterSchema validation in products/mcp/typescript/src/schema/flags.ts:
-
String arrays can now use all string operators (
exact,icontains,regex, etc.) + array operators (in,not_in) -
Number arrays can use base operators (
exact,is_not, etc.) + array operators - Prevents invalid combinations (e.g., number arrays with
gt/gteoperators which don't make semantic sense) - Maintains existing validation that array-specific operators require array values
Testing
Added comprehensive test suite in products/mcp/typescript/tests/tools/featureFlags.integration.test.ts:
- ✅ String array with
exactoperator (the main bug) - ✅ String array with
icontainsoperator - ✅ Number array with
exactoperator - ✅ Array with
inoperator (ensures existing functionality still works)
Impact
Users can now manage feature flags with multiple-value filters through the MCP server without falling back to PostHog's UI.
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.
@sreuter thank you for this PR! Running the CI checks now so we can get it merged in.
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant.
@sreuter hey sorry our bot does that automatically when a PR is stale. I've reopened, set it to auto merge and re-run all CI checks. If the fail (e.g. due to formatting), do you mind pushing fixes to the branch? (unfortunately I can't push to your fork)
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.
Don't mark this as stale - it should get merged once the temporary external contributor block is lifted
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in another week. If you want to permanentely keep it open, use the waiting label.