Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
LGTM — straightforward dev tooling addition with no production code changes.
Extended reasoning...
Overview
This PR adds @apify/mcpc as a dev dependency and wires it into the development workflow. Changes touch: .mcp.json (two new local server entries), CLAUDE.md (agent instructions for mcpc probing), DEVELOPMENT.md (refactored to be more concise, with mcpc workflow docs), a new .claude/skills/mcpc/SKILL.md skill file, and the corresponding package.json/package-lock.json updates. No production source code is touched.
Security risks
Minimal. The .mcp.json additions use ${APIFY_TOKEN} env-var expansion (consistent with existing entries) — no credentials are hardcoded. The @apify/mcpc package is dev-only and will not be included in the published NPM package or deployed server. The Authorization: Bearer ${APIFY_TOKEN} header on the dev HTTP entry is standard and correct. One minor note: the dev entry lacks an explicit "type": "http" field unlike the storybook and figma entries, but this is a local dev config and Claude Code likely infers the type from the url field.
Level of scrutiny
Low. These are purely developer experience improvements — a CLI tool for probing the local server during development, configuration for it, and updated docs. No logic, no auth paths, no data handling, no production-facing code changed.
Other factors
No bugs were reported by the automated system. The transitive dependency chain via viem (a blockchain library) is an unexpected choice in an MCP CLI tool, but since it is dev-only it has no impact on end-users or the published package. @apify/mcpc requires Node ≥ 20, but since it is a devDependency this does not conflict with the runtime minimum of Node ≥ 18 documented in DEVELOPMENT.md.
github-actions
Bot
added
the
tested
…mentation # Conflicts: # package-lock.json
…ge details # Conflicts: # .claude/skills/feature-spec/SKILL.md
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ctor discovery workflow - Add key principles section: prefer mcpc+jq pipelines, keep commands short, end-to-end focus - Add @stdio-full session to .mcp.json for testing with full tool set - Add "Testing different use cases" section showing search-actors + fetch-actor-details pattern - Clarify that server args come from .mcp.json and cannot be passed inline - Simplify jq examples for brevity Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
jirispilka
force-pushed
the
feat/add-mcpc-for-server-probing
branch
from
059f0cc to
fbf8bad
Compare
…ting Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jirispilka
changed the title
2 participants
What
Adds
mcpc(@apify/mcpc) as the standard tool for live end-to-end probing of the local MCP server during development and feature implementation.Changes:
.mcp.json— addsstdio(spawnsdist/stdio.js) anddev(connects tolocalhost:3001) server entriesCLAUDE.md— agent workflow: build → connect/restart → probe to verify spec complianceDEVELOPMENT.md— human setup, testing layer overview, mcpc examples, key behaviors to verify.claude/skills/mcpc/SKILL.md— repo-specific skill loaded when probing is neededWhy mcpc over direct Claude connection
Claude Code can connect to an MCP server via
.mcp.jsonlocally, but remote Claude sessions (claude.ai, CI, cloud agents) cannot reach a locally running server. mcpc is a CLI tool the agent controls via shell commands — it works identically in local and remote sessions. For local sessions the classic direct MCP connection (mcp__apify-dev__*tools) still works as an alternative.When to use
Not just after code changes — mcpc is the primary way to verify that a finished feature actually matches its spec end-to-end, before writing formal integration tests or opening a PR.