agentleFS
dagonetdagonet/claude-code-toolkit/skills/mcp-usage/SKILL.md

mcp-usage

Skill4 starsChanged 7 months agoMITView on GitHub

Occasional MCP procedures — use when digesting a large input, extracting structured data, mapping an unfamiliar repo, looking up a library API, or running a headless batch.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before local_first_pass or extract_json:

    line 14
  2. Distinctive:

    If Ollama is unavailable: say so, proceed without local preprocessing when the task is small, and do not retry indefinitely or fail …

    line 20
  3. Distinctive:

    Only then implement or answer.

    line 28
  4. Distinctive:

    When the task needs structured data — errors, TODOs, requirements, entities, acceptance criteria, cause/effect:

    line 32
  5. Distinctive:

    Treat the returned JSON as the authoritative structure.

    line 35
  6. Very specific:

    Do not hand-infer structure when extraction is available.

    line 38
  7. Distinctive:

    Prefer the bundled and superpowers skills over ad-hoc reading:

    line 46
  8. Distinctive:

    Prefer MCP tools for preprocessing and automation.

    line 83

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

MCP Usage

Procedures that used to live inline in every project's CLAUDE.local.md. They are needed occasionally, not on every turn, so they load on demand.

That always-on half — which servers are registered, the git/GitHub MCP-only requirement, Open Brain, trust/verification, and failure handling — lived in CLAUDE.local.md for a project bootstrapped before v4.0.1. The template no longer ships that file; for a newer project the always-on channel is CLAUDE.md's PROJECT-CUSTOM region.

Ollama availability & warm-up

Before local_first_pass or extract_json:

  1. ollama_health — is the server up?
  2. ollama_list_models — are the required models present?
  3. warm_models (optional) — pre-load for faster first inference.

If Ollama is unavailable: say so, proceed without local preprocessing when the task is small, and do not retry indefinitely or fail silently.

Large inputs / context digestion

For any input over ~200 lines, or complex regardless of length (requirements, logs, architecture, policy):

  1. local_first_pass to compress or plan.
  2. Verify important details against the original — the summary is assistive, not authoritative.
  3. Only then implement or answer.

Structured information extraction

When the task needs structured data — errors, TODOs, requirements, entities, acceptance criteria, cause/effect:

  1. extract_json with an explicit schema.
  2. Treat the returned JSON as the authoritative structure.
  3. Act on it (prioritize, implement, fix).

Do not hand-infer structure when extraction is available. If extract_json returns invalid JSON, retry through the tool — never continue on a guessed structure.

Project orientation

Getting your bearings in a repo: call map_project_structure (or map_dotnet_structure in .NET repos) and let the returned structure decide which files to open. For open-ended exploration, dispatch the Explore subagent instead of walking directories by hand — it returns compressed locations, not raw file contents.

Code quality & security sweeps

Prefer the bundled and superpowers skills over ad-hoc reading:

NeedSkill
Review checklist (correctness, design, security, performance)/code-review (bundled code-review plugin)
Requesting or digesting a reviewsuperpowers:requesting-code-review / superpowers:receiving-code-review
Diagnosing a failure before changing codesuperpowers:systematic-debugging
Environment / config sanity check/doctor (bundled)

In .NET repos, analyze_method_complexity, find_god_classes, and find_large_files give complexity hotspots; nuget_check_vulnerabilities and nuget_list_outdated cover dependencies.

Context7 library documentation

For unfamiliar library APIs: resolve-library-id, then query-docs, then verify the code against what came back before committing.

Use it for unfamiliar framework APIs and controls, third-party patterns, and any library whose surface has changed recently. Skip it for well-known standard-library APIs and patterns already established in the codebase — follow the existing pattern first.

Headless mode for batch operations

For repeatable non-interactive work across repos or variants, use claude -p. Start it with env -u CLAUDE_CODE_SESSION_ID: a nested claude inherits the parent's session id, and its SessionEnd would delete the parent's cct marker (the parent's next tool call in a synced project is then refused).

# Single-variant template sync
env -u CLAUDE_CODE_SESSION_ID claude -p "Run /cct:sync-template, resolve merge conflicts, commit and push"

# Multi-variant propagation
for variant in general dotnet dotnet-maui rust-tauri java python; do
  env -u CLAUDE_CODE_SESSION_ID claude -p "Apply the same change to templates/$variant/ — implement, verify, commit, push"
done

Use when the pipeline is well-defined and repeatable — template propagation, release steps, batch syncs. Do not use for multi-step sprints needing checkpoints, debugging sessions, or first-time operations whose pattern has not been validated.

On Windows, run headless commands from Git Bash.

Performance guidance

Prefer MCP tools for preprocessing and automation. Do not dump logs, directory trees, or full diffs into the conversation. Reserve reasoning budget for design decisions, code changes, test logic, and architectural trade-offs.

Default workflow pattern

Unless told otherwise: MCP preprocessing → plan from tool output → verify against sources → implement → re-run build/tests → update issues if relevant → commit → summarize.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.