MCP Skill
When to use
Use this skill when:
- Deciding which MCP tool to use for a task
- Combining multiple MCP tools in a workflow
- Troubleshooting MCP tool errors or unexpected results
- Building commands or skills that reference MCP tools
Procedure: Use MCP tools
- Inspect available MCP servers — List configured servers (Sentry, Jira, GitHub, Playwright, Context7, Sequential Thinking) and confirm credentials/permissions for the task.
- Pick the right tool per task — Match user intent to the server table below; prefer the most specific tool over generic search.
- Chain tools when needed — Apply the Combining tools in workflows patterns; capture intermediate IDs (org slug, project slug, ticket key) before deeper calls.
- Verify and handle errors — Apply Error handling and Permission boundaries; confirm the result answers the original question before moving on.
Sentry (augment-partner-remote-mcp-sentry)
Error tracking and performance monitoring.
| Tool | Purpose | When to use |
|---|---|---|
find_organizations |
Find org slug | First call — needed for all other Sentry tools |
find_projects |
Find project slug | When filtering by project |
find_teams |
Find team slug/ID | Team-based queries |
find_releases |
Recent releases | Check deploy timing, release versions |
get_issue_details |
Full issue: stacktrace, tags | Investigating a specific error |
get_issue_tag_values |
Distribution by tag | Analyzing who/what is affected |
get_trace_details |
Trace overview | Performance investigation |
get_event_attachment |
Download attachments | Screenshots, logs on events |
search_issues |
List issues by criteria | "Show me unresolved errors" |
search_events |
Count/aggregate events | "How many errors today?" |
search_issue_events |
Filter events in an issue | "Events from last hour" |
analyze_issue_with_seer |
AI root cause analysis | When stacktrace alone isn't enough |
Key pattern: Always get org slug first → then use other tools.
See: sentry-integration skill for investigation workflow.
Jira (jira-integration)
Issue tracking and project management.
| Tool | Purpose | When to use |
|---|---|---|
GET /search/jql |
Search with JQL | Find tickets by criteria |
GET /issue/{key} |
Read ticket details | Get context for a task |
POST /issue |
Create ticket | New bugs, tasks, stories |
PUT /issue/{key} |
Update ticket | Change fields, assignee |
GET /issue/{key}/transitions |
Available status changes | Before transitioning |
POST /issue/{key}/transitions |
Change ticket status | Move to "In Progress", etc. |
POST /issue/{key}/comment |
Add comment | Progress updates, analysis |
GET /project |
List projects | Find project key |
GET /field |
List available fields | Before writing JQL |
Key pattern: Check fields (GET /field) before writing JQL. Check transitions before changing status.
See: jira-integration skill for JQL patterns and ADF format.
GitHub (github-api)
Repository, PR, and CI management.
| Tool | Purpose | When to use |
|---|---|---|
GET /repos/{o}/{r}/pulls |
List PRs | Find open PRs for branch |
POST /repos/{o}/{r}/pulls |
Create PR | Open a new pull request |
GET /repos/{o}/{r}/pulls/{n}/files |
PR changed files | Review what changed |
GET /repos/{o}/{r}/issues |
List issues/PRs | Search by label, assignee |
GET /search/issues |
Search issues/PRs | Complex queries with q= |
GET /repos/{o}/{r}/actions/runs |
CI runs | Check build status |
GET /repos/{o}/{r}/actions/jobs/{id} |
CI job details | Read failure logs |
GET /repos/{o}/{r}/commits/{sha}/check-runs |
Check runs | Detailed CI status |
GET /repos/{o}/{r}/commits/{sha}/status |
Commit status | Quick pass/fail check |
Key pattern: Use head=org:branch to filter PRs by branch. Use q=is:pr or q=is:issue to separate.
See: git-workflow and code-review skills.
Browser / Playwright (Playwright)
Web interaction and testing.
| Tool | Purpose | When to use |
|---|---|---|
browser_navigate |
Open URL | Load a page |
browser_snapshot |
Accessibility snapshot | Read page content (better than screenshot) |
browser_click |
Click element | Interact with UI |
browser_type |
Type text | Fill forms |
browser_evaluate |
Run JavaScript | Extract data, manipulate DOM |
browser_take_screenshot |
Visual capture | Document UI state |
browser_network_requests |
Network log | Debug API calls |
Key pattern: Use browser_snapshot over screenshots — it returns structured data the agent can act on.
Context7 (Context_7)
Library documentation lookup.
| Tool | Purpose | When to use |
|---|---|---|
resolve-library-id |
Find library ID | First — before querying docs |
query-docs |
Query documentation | Get up-to-date API docs and examples |
Key pattern: Always resolve library ID first → then query. Max 3 calls per question. Use for: Laravel, React, Django, Tailwind, or any library docs.
Sequential Thinking (Sequential_thinking)
Structured problem-solving.
| Tool | Purpose | When to use |
|---|---|---|
sequentialthinking |
Step-by-step reasoning | Complex problems, planning, analysis |
Use for: Breaking down complex tasks, planning before implementation, multi-step reasoning.
Best Practices
Tool selection
| Need | Tool |
|---|---|
| Error investigation | Sentry → get_issue_details |
| Ticket context | Jira → GET /issue/{key} |
| CI failure | GitHub → actions/runs + actions/jobs/{id} |
| Library docs | Context7 → resolve-library-id + query-docs |
| Web scraping | Playwright → navigate + snapshot |
| Complex planning | Sequential Thinking |
Combining tools in workflows
Bug investigation:
Jira (ticket context) + Sentry (stacktrace) + codebase-retrieval (code)
Feature planning:
Jira (requirements) + codebase-retrieval (existing code) + Context7 (library docs)
CI fix:
GitHub (failure logs) + codebase-retrieval (failing code) + launch-process (run locally)
PR creation:
GitHub (create PR) + Jira (transition to "In Review")
Error handling
- If an MCP tool returns an error, retry once with corrected parameters
- If org/project slug is unknown, use
find_organizations/find_projectsfirst - Sentry and Jira tools need the correct org — don't guess, look it up
- GitHub API has rate limits — batch related calls, avoid unnecessary requests
Permission boundaries
- Read operations — always safe, use freely
- Write operations — ask user permission first:
- Creating Jira tickets or changing status
- Creating GitHub PRs or pushing code
- Posting comments on issues/PRs
Tool-tier ladder — most-specific first, no silent fall-through
Pick the most specific tool available for the job: a dedicated tool > a generic tool > a lowest-level/raw call. The ladder has an anti-fall-through rule:
- A dedicated tool erroring is a signal to debug/report, never to silently retry the same job via a broader/slower tier. Silent degradation masks the real failure (the dedicated tool broke) behind a worse-but-working path.
- The broader tier is for unavailability (the specific tool isn't present), not for error recovery (it's present but failed). Unavailable → step down a tier; errored → stop and surface.
This is tool-selection discipline. Delegation (when to hand work to a
subagent at all) is subagent-orchestration's
concern, not this ladder's — keep the boundary explicit.
Related
- Skill:
sentry-integration— Sentry-specific investigation patterns - Skill:
jira-integration— Jira-specific JQL and ticket management - Skill:
git-workflow— GitHub PR and branch conventions - Skill:
copilot-config— GitHub Copilot integration - Rule:
no-commit.md— permission boundaries for write operations
Output format
- MCP server configuration or tool integration code
- Tool capability mapping for the agent workflow
Gotcha
- MCP servers are token-expensive — prefer CLI equivalents when available (see
rtk-output-filteringskill). - Don't chain 5+ MCP tool calls when a single CLI command could do the same thing.
- MCP server availability varies — always handle connection failures gracefully.
- Sentry and Jira MCP provide unique capabilities — those are worth the token cost.
Do NOT
- Do NOT call MCP tools without understanding their side effects.
- Do NOT use MCP tools when simpler alternatives exist.
Auto-trigger keywords
- MCP
- Model Context Protocol
- MCP server
- MCP tools
- agent tools