ClaudeSuperPower
SubmitLog in

testing-mcp-tools-locally

Skill

Set up the local dev environment, seed data, and API keys to test the staff-only managed migrations MCP tools (managed-migrations-support-list, managed-migrations-support-get) end to end. Use when testing batch import support tooling, debugging MCP tool responses or discovery (tools not appearing),

0Testing

Install

git clone https://github.com/PostHog/ai-plugin.git ~/.claude/skills/testing-mcp-tools-locally

What is testing-mcp-tools-locally?

Set up the local dev environment, seed data, and API keys to test the staff-only managed migrations MCP tools (managed-migrations-support-list, managed-migrations-support-get) end to end. Use when testing batch import support tooling, debugging MCP tool responses or discovery (tools not appearing), or verifying the support API before deploying. Covers the discovery gate: hidden scope, is_staff, user:read, and why wildcard keys and OAuth never work.

What this can do

Capabilities declared in this component's own frontmatter — not inferred.

Inherit all session tools

Declares no tool restrictions — inherits every session tool

~113 tokens of context used while enabled, before you invoke anything

Documentation

README · ~5 min read

Testing managed migrations MCP tools locally

Prerequisites

The dev environment must be running with Docker services healthy. The batch import support API and MCP tools require:

  • A staff user (is_staff = True)
  • A Personal API Key carrying both batch_import_support:read and user:read, explicitly
  • Postgres migrations applied (ClickHouse not required)

Why both scopes: the backend accepts batch_import_support:read alone, but MCP tool discovery verifies staffness via /api/users/@me/ and hides the tools (fail-closed) when the key cannot make that call. A * wildcard does not substitute for either — the discovery gate requires the hidden scope explicitly, and the backend's INTERNAL scope handling rejects wildcard keys outright.

Reviews

Log in to leave a review.

No reviews yet — be the first.

Explore related

Other things in this space — across every part of the ecosystem, not just skills.

Subagents

All subagents →

agent-creator

Use this agent when the user asks to "create an agent", "generate an agent", "build a new agent", "make me an agent that...", or describes agent functionality they need. Trigger when user wants to create autonomous agents for plugins. Examples: <example> Context: User wants to create a code review a

32.8K stars

agent-sdk-verifier-ts

Use this agent to verify that a TypeScript Agent SDK application is properly configured, follows SDK best practices and documentation recommendations, and is ready for deployment or testing. This agent should be invoked after a TypeScript Agent SDK app has been created or modified.

32.8K stars

pr-test-analyzer

Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Typical triggers include the user asking whether tests on a freshly-creat

32.8K stars