MCP integration reference pattern

This is a template skill. It shows how to structure a skill that wraps an MCP server. Replace sentry with your MCP server name and adapt the reference file at references/sentry-mcp.md.

What this pattern solves

When a skill calls an MCP server without prior context, Claude guesses at the query syntax. This works for simple calls but breaks on anything with non-obvious behavior: pagination quirks, required parameter combinations, rate limits, or subtle format restrictions.

The fix: a references/<mcp-name>.md file that captures all the gotchas. The skill reads this file before making any MCP call. Zero guessing.

Three types of content go in the reference file:

1. Parameter semantics that differ from what the tool name implies
2. Known error patterns and their root causes
3. Working query examples (copy-paste, no thinking required)

---

Step 1: Read the MCP reference file

Before doing anything else, read the full MCP reference:

Read: references/sentry-mcp.md

This file contains query syntax, known gotchas, and working examples for the Sentry MCP. Do not skip this step.

---

Step 2: Gather scope from user

Ask the user:

• Time range: Last 24h? 7 days? Custom range?
• Environments: production, staging, or both?
• Projects: All projects or specific ones? (Default: all)

If the user says "just run it with defaults", use:

• Time range: last 72 hours
• Environment: production only
• Projects: all

---

Step 3: Fetch error data

Using the tool knowledge from Step 1, fetch:

1. Issue list: Active unresolved issues, ordered by frequency
2. Event details: Full stack traces for the top 5 issues by event count

Cap results at 50 issues. If more exist, note the count and focus on the highest-frequency items.

---

Step 4: Group and analyze

Group issues by root cause, not by error message. Two issues with different messages can share the same underlying cause (shared code path, same external dependency, same config).

For each group:

• Count of issues in the group
• Earliest first-seen date
• Affected users count (if available)
• Most likely root cause (one sentence, evidence-based)
• Relevant file paths from the stack trace

---

Step 5: Generate report

Output a markdown report with this structure:

# Error Report: [Project or Scope]

**Period**: [start] to [end]
**Environment**: [env]
**Total active issues**: [N]

## Summary

[2-3 sentences: what is the overall health picture?]

## Issue Groups

### Group 1: [Root Cause Label]

| Attribute      | Value                    |
|----------------|--------------------------|
| Issues         | N                        |
| Total events   | N                        |
| Affected users | N                        |
| First seen     | YYYY-MM-DD               |
| Key file       | path/to/file.py:line     |

**Root cause**: [One paragraph. Specific, evidence-based. Point to file and line.]

**Suggested investigation**: [One or two concrete next steps.]

---

[Repeat for each group]

## Out of Scope

[List issues explicitly excluded and why. Example: "404s on /static/ excluded - expected behavior for SPA asset versioning."]

---

Scope rules

• This skill detects and describes issues. It does not modify code or create tickets.
• If an issue is ambiguous, flag it as "needs investigation" rather than guessing.
• Do not include informational logs or warnings unless they correlate directly with errors.

---

Adapting this template

To fork this skill for a different MCP:

1. Copy this directory: cp -r examples/skills/mcp-integration-reference examples/skills/<your-skill>/
2. Rename references/sentry-mcp.md to references/<your-mcp>.md
3. Replace the reference file content with your MCP's gotchas
4. Update allowed-tools in the frontmatter to match your MCP tool names
5. Adjust the analysis steps to match your data domain

The pattern works for any MCP that has non-obvious query behavior: Datadog, PagerDuty, Linear, Jira, Posthog, Mixpanel, etc.