test(mcp): add skipped AJV compile guard for MCP tool input schemas

[ProCO-RPHopkins]

Hi @joshsny - This adds a skipped AJV compile guard for MCP tool input schemas under products/mcp/typescript/tests/unit/schema.ajv.test.ts. It runs AJV in strict: true with ajv-formats and compiles schema/tool-inputs.json.

It’s describe.skip(...) for now because several tool schemas are known-broken (duplicate enum entries, array shape vs. anyOf, etc.). We’ll flip it on once the upstream schema fixes land:

• Upstream tracker: https://github.com/PostHog/posthog/issues/38607

Why this is useful

• Gives an early, focused signal on schema regressions without touching runtime code.
• When #38607 is resolved, we can remove .skip and the guard will protect future changes.

Local run

pnpm -C products/mcp/typescript test

When #38607 (schema cleanup) is resolved, we’ll remove .skip so CI fails fast on schema regressions.

[ProCO-RPHopkins]

Hi @joshsny, quick follow-up. I ran a strict AJV scan locally against the current tool list from the remote MCP server (43 tools total).

Under strict: true with ajv-formats, 39 of 43 tool input schemas compile cleanly, and the following 4 fail:

• create-feature-flag
• update-feature-flag
• survey-create
• survey-update

The same pattern occurs for all four:

• the operator enum under the filters / targeting filters has duplicate values (e.g. "exact", "is_not", "is_set", "is_not_set" appear multiple times), and
• AJV also complains about the items / anyOf shape for that part of the schema.

Once that shared operator schema is cleaned up, we should be able to flip the guard test from describe.skip() to a normal describe() and let CI enforce it going forward. I can help with a follow-up PR that fixes those four schemas and then turns the guard on, if that’s useful.

[ProCO-RPHopkins]

Hi @joshsny, I’ve pushed the update that removes the duplicated operator enum values in the feature-flag filter schemas and regenerated tool-inputs.json. The strict Ajv guard is now enabled and passing locally. Everything here is scoped to MCP, so the failing frontend check and the “merge blocked due to incident” status look unrelated. Happy to adjust anything you’d like.

[joshsny]

Hi @ProCO-RPHopkins - great, thanks for doing that - it looks like those are failing stating the pnpm lockfile is out of date, could you run pnpm install to try fix those?

The pending check about the incident can be ignored, merges are temporarily blocked due to an ongoing data migration.

[wiz-7ad640923b[bot]]

Wiz Scan Summary

⚠️ Many findings detected

Many findings were detected, but only a subset of the findings are displayed inline due to API constraints. To view all findings inline, please click here.

Scanner	Findings
Vulnerabilities	25  23  13
Sensitive Data	-
Secrets	-
IaC Misconfigurations	-
SAST Findings	-
Software Supply Chain Findings	-
Total	25  23  13

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[ProCO-RPHopkins]

Hi @joshsny - The previous pnpm failure came from me working from a partial checkout of the repo, so pnpm couldn't see all the frontend pkgs when it tried to update the workspace lockfile. Now that I've pulled the full repo and ran npm install at the root, that check is passing.

The remaining failing checks are Prettier/linting jobs for @posthog/frontend, which I haven’t modified in this PR.

[ProCO-RPHopkins]

Hi @joshsny, finally all required checks are green. Since I was able to troubleshoot the checks, contributing to PostHog in the future should be much easier.

The remaining Integration Tests job is failing due to missing TEST_POSTHOG_ environment variables, which I believe rely on internal secrets. Let me know if there’s anything else you’d like me to run locally.

[posthog-bot]

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.

[joshsny]

Don't mark as stale - we're keeping this open, merging it is delayed by the temporary external contributor block

[posthog-bot]

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.

[github-actions[bot]]

This PR was closed due to lack of activity. Feel free to reopen if it's still relevant.

[joshsny]

@ProCO-RPHopkins I've reopened this, since the external contributor block that was there due to an incident is no longer in place - if you are able to resolve the conflicts, we can get this merged :)