verify-live-mcp

name	verify-live-mcp
description	Use skill when verifying, smoke-testing, or describing the live mcp-researchpowerpack server (https://research-mcp.yigitkonur.com/mcp) — the exact 3-tool surface, post-deploy contract check, schema/health/SSRF/Reddit/PDF acceptance, or any "does the deploy actually expose X" question. Query the live server with mcpc; never describe its tools from memory.

Verify the live mcp-researchpowerpack surface

Project-specific harness for smoke-testing this server with the mcpc CLI. It pins the acceptance contract of mcp-researchpowerpack so you verify the real, deployed surface instead of recalling a stale one. It adapts the general test-by-mcpc-cli skill; for exhaustive mcpc CLI mechanics (auth, stdio, x402, tasks, proxy) read that upstream skill — this file intentionally carries only what this HTTP-only, 3-tool research server needs.

• Live URL: https://research-mcp.yigitkonur.com/mcp
• Manufact server id: 188771a3-172e-41d0-926d-bb15bb609802
• Full acceptance matrix + copy-paste smoke script: references/acceptance-contract.md
• Repo contract this mirrors: root AGENTS.md §2 (tool surface), §13 (acceptance criteria)

Prime rule — never describe the surface from memory

The tool surface is whatever tools-list returns right now, and nothing else. This server's history is a trap: it shipped a 5-tool surface (start-research, raw-web-search, smart-web-search, raw-scrape-links, smart-scrape-links) and later a get-research-consultancy include_playbook parameter — all removed. Those dead names still live in model training data, so an agent that answers "what tools does this server have?" from memory will confidently emit the old 5-tool table. That is a hallucination, not the contract.

So:

• Never hand-write or paraphrase the tool list, a tool's parameters, or "how this MCP is designed to work" from recall. Run mcpc … tools-list / tools-get and quote what it returns.
• If you catch yourself about to render a table of tools you did not just fetch live, stop and fetch it.
• The current, correct surface is exactly 3 tools: get-research-consultancy (goal?:str), web-search (keywords:[str]), scrape-link (urls:[str], extract:str). If a live probe ever shows more, fewer, or the old names, that is a real regression — investigate, do not "correct" it from memory.

Do NOT trust the version string to detect a deploy

mcp-researchpowerpack has no auto version bump — package.json.version (and thus health://status.version) only moves when someone bumps it by hand. A shipped change (e.g. removing include_playbook) can be fully live while the version string is unchanged. Confirm a deploy by the tool/schema surface and the active-deployment commit, never by the version number alone:

npx mcp-use servers get 188771a3-172e-41d0-926d-bb15bb609802   # active deployment commit == your merged SHA?

Interpret health snapshots with a real call

health://status is a snapshot, not the verdict. A single llm_planner_ok: false with consecutive_planner_failures: 1 and llm_runtime_available: true can just mean one brief parse/validation probe failed; it can coexist with successful brief generation on the next real call. Do not diagnose CI/CD or deploy failure from that flag alone. Pair it with:

• active deployment commit == merged SHA (mcp-use servers get),
• llm_runtime_available, consecutive_planner_failures, and extractor health,
• a real get-research-consultancy call checked for isError:false, ## The tools, and (when planner is healthy on that call) ## Your research brief.

Standard smoke (mcpc 0.2.x is session-first)

mcpc requires connecting a named @session before any operation. Inspect the JSON isError, never the green human-mode banner — a call can exit 0 and still be "isError": true.

mcpc connect research-mcp.yigitkonur.com/mcp @rp --no-profile   # https:// auto-added; --no-profile forces anonymous
mcpc @rp tools-list --full | grep -E "name|Input"               # MUST show exactly 3; MUST NOT show any removed name
mcpc @rp tools-get get-research-consultancy                     # Input MUST be only `goal`; no `include_playbook`
mcpc --json @rp resources-read health://status | jq '.contents[0].text | fromjson | {version, llm_planner_ok, planner_configured}'
mcpc --json @rp tools-call get-research-consultancy '{"goal":"smoke"}' | jq '.isError // false'   # expect false
mcpc close @rp

Full assertion set (schemas, health fields, SSRF refusal, Reddit routing, PDF via Jina, degrade-not-error) and a ready-to-run script are in references/acceptance-contract.md. Run that whenever you touch the tool surface, deploy, or need to answer "what does this server actually expose?".

When to reach for this skill

• Post-deploy verification of main (pair with AGENTS.md §11/§12).
• Any request to describe, document, or diagram this server's tools.
• Diagnosing "the agent thinks the server has different/old tools".
• Confirming a schema change (a removed/added field) actually reached prod.

Load-bearing mcpc rules (from the upstream contract)

1. Always connect a named @session first; target-first one-shot syntax is gone in 0.2.x.
2. Inspect isError and payload text, not the success banner.
3. Use --no-profile to force anonymous HTTP tests when saved OAuth would otherwise inject auth.
4. Close sessions (mcpc close @rp) or mcpc clean when done; never leave dangling sessions that pollute later checks.
5. If a session is disconnected/expired, make a fresh one — do not reuse a stale session for a smoke check.