Menu
Use to verify MCP tool server availability before relying on external tools, and to manage fallback strategies when tools are unavailable.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | mcp-validation |
| description | Use to verify MCP tool server availability before relying on external tools, and to manage fallback strategies when tools are unavailable. |
Use this skill to catch tool-server mismatches early, before they cause silent failures during task execution.
Many agent platforms (e.g., VS Code Copilot, Claude with tool routing) already handle MCP tool availability checks natively. If your agent platform provides built-in MCP error handling, mark this skill as [AGENT-NATIVE] in prompt-budget.yml and skip it. See docs/operating-rules.md → Agent-deference principle.
This skill activates only when project/project-manifest.md contains a ## MCP tool declarations section with at least one declared tool. If the section is empty or absent, this skill short-circuits — no action needed.
Run this check at the start of every task that may use MCP tools. For Small tasks with no expected MCP tool usage, skip this check.
Read project/project-manifest.md → MCP tool declarations. Collect the list of declared tool names and their fallback mappings.
For each declared tool, attempt a minimal no-op invocation (e.g., list capabilities, ping, or a read-only query that produces negligible side effects). Record:
Produce an availability summary before proceeding with the task:
**MCP tool availability**:
- tool-a: available
- tool-b: unavailable → fallback: built-in-equivalent-b
- tool-c: degraded (read-only mode)
If all tools are available, proceed normally. If any tool is unavailable or degraded, apply the fallback strategy below.
When a declared MCP tool is unavailable:
Check fallback mapping — look up the Fallback builtin column in the MCP tool declarations table (this maps to the fallback_builtin field).
Use the fallback — if a built-in equivalent exists, use it and log the substitution in the handoff artifact or task summary:
**Tool substitution**: tool-b unavailable → using built-in-equivalent-b
No fallback available — if no built-in equivalent is declared, report the gap to the user and ask whether to proceed without that capability or wait for the tool to become available.
Never silently skip — do not proceed as if the tool call succeeded when it failed. Always log the substitution or the gap.
During long-running tasks (Medium/Large scale), tool availability may change. Revalidate when:
When MCP tool substitutions occur during a task, include them in the handoff artifact:
- **Tool substitutions**: [list] lineopen_risks array with severity low, or as a note in deliverable_summaryDeclare MCP tools in project/project-manifest.md → ## MCP tool declarations:
| Tool name | Server / endpoint | Fallback builtin | Notes |
|---|---|---|---|
| mcp_github_create_issue | github MCP server | — | Required for issue automation |
| mcp_figma_get_design_context | figma MCP server | — | Optional, design-to-code only |
If no MCP tools are used, leave the table empty or omit the section entirely.
project/project-manifest.mdBefore completing a task where this skill applies, verify:
Use for general product implementation work that is not primarily backend architecture, pure integration wiring, or screenshot-driven design-to-code.
Use when the main deliverable is maintainable documentation such as repository rules, onboarding guides, runbooks, ADRs, or architecture notes.
Use on first entry to a new repository to run environment scanning and ask targeted boundary questions before implementation.
Use after writing or modifying code to enforce the mandatory write → test → fix → repeat validation cycle.
Use before committing to a design or plan to force assumption-surfacing. The agent challenges your design, questions edge cases, and flags gaps — you patch vague decisions. Prevents the failure mode where a design "feels explained" but contains hidden flaws that only appear during implementation.
Use to establish and maintain a shared domain glossary (UBIQUITOUS_LANGUAGE.md). Creates a single source of term definitions that all agents, prompts, and documents must use — preventing semantic drift and repeated re-explanation across sessions.