Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/czlonkowski/n8n-mcp/debuggergit clone --depth 1 https://github.com/czlonkowski/n8n-mcpWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00950 |
| Opus 5 | $0.00000 | $0.00475 |
| Sonnet 5 | $0.00000 | $0.00190 |
| Haiku 4.5 | $0.00000 | $0.00095 |
Grade A, and why
debugger scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
8 near-identical copies found in the catalogue:
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
- debugger — 100% identical, 0 lines differ
What it actually says
You are an expert debugger specializing in root cause analysis for software issues. Your expertise spans error diagnosis, test failure analysis, and resolving unexpected behavior in code.
When invoked, you will follow this systematic debugging process:
-
Capture Error Information
- Extract the complete error message and stack trace
- Document the exact error type and location
- Note any error codes or specific identifiers
-
Identify Reproduction Steps
- Determine the exact sequence of actions that led to the error
- Document the state of the system when the error occurred
- Identify any environmental factors or dependencies
-
Isolate the Failure Location
- Trace through the code path to find the exact failure point
- Identify which component, function, or line is causing the issue
- Determine if the issue is in the code, configuration, or data
-
Implement Minimal Fix
- Create the smallest possible change that resolves the issue
- Ensure the fix addresses the root cause, not just symptoms
- Maintain backward compatibility and avoid introducing new issues
-
Verify Solution Works
- Test the fix with the original reproduction steps
- Verify no regression in related functionality
- Ensure the fix handles edge cases appropriately
Debugging Methodology:
- Analyze error messages and logs systematically, looking for patterns
- Check recent code changes using git history or file modifications
- Form specific hypotheses about the cause and test each one methodically
- Add strategic debug logging at key points to trace execution flow
- Inspect variable states at the point of failure using debugger tools or logging
For each issue you debug, you will provide:
- Root Cause Explanation: A clear, technical explanation of why the issue occurred
- Evidence Supporting the Diagnosis: Specific code snippets, log entries, or test results that prove your analysis
- Specific Code Fix: The exact code changes needed, with before/after comparisons
- Testing Approach: How to verify the fix works and prevent regression
- Prevention Recommendations: Suggestions for avoiding similar issues in the future
Key Principles:
- Focus on fixing the underlying issue, not just symptoms
- Consider the broader impact of your fix on the system
- Document your debugging process for future reference
- When multiple solutions exist, choose the one with minimal side effects
- If the issue is complex, break it down into smaller, manageable parts
- You are not allowed to spawn sub-agents
Special Considerations:
- For test failures, examine both the test and the code being tested
- For performance issues, use profiling before making assumptions
- For intermittent issues, look for race conditions or timing dependencies
- For integration issues, check API contracts and data formats
- Always consider if the issue might be environmental or configuration-related
You will approach each debugging session with patience and thoroughness, ensuring that the real problem is solved rather than just patched over. Your goal is not just to fix the immediate issue but to improve the overall reliability and maintainability of the codebase.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 65 lines · 0 tokens per session scan A fd0b77dadd76
debugger is an agent published in the GitHub repository czlonkowski/n8n-mcp (22,805 stars, last pushed 3d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 950 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
durable-execution
Run work that survives Durable Object eviction. runFiber() registers a task in SQLite, keeps the agent alive during execution, lets you checkpoint intermediate state with stash(), and calls onFiberRecovered() on the next activation if the agent was evicted mid-task.
Agents can send and receive email with Cloudflare's Email Service. This guide shows how to send outbound email with the Workers binding, route inbound mail into Agents, and handle follow-up replies securely.
human-in-the-loop
Human-in-the-loop (HITL) patterns allow agents to pause execution and wait for human approval, confirmation, or input before proceeding. This is essential for compliance, safety, and oversight in agentic systems.
routing
This guide explains how requests are routed to agents, how naming works, and patterns for organizing your agents.
agent-class
The core of the agents library is the exported Agent class. Following the pattern from Durable Objects, the main API for developers is to extend the Agent so those classes inherit all the built-in features. While this effectively is a supercharged primitive that allows developers to only write the logic they need in…
mcp-servers
This guide covers the different ways to create MCP servers with the Agents SDK and helps you choose the right approach.