Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add Viindoo/odoo-mcp-client/plugin install odoo-ai-agentsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/viindoo/odoo-mcp-client/odoo-debug)<a href="https://agentmods.dev/skills/viindoo/odoo-mcp-client/odoo-debug"><img src="https://agentmods.dev/badge/skills/viindoo/odoo-mcp-client/odoo-debug.svg" alt="Measured on agentmods" height="20"></a>What 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.1 | $0.00240 | $0.05680 |
| Opus 5 | $0.00120 | $0.02840 |
| Sonnet 5 | $0.00048 | $0.01136 |
| Haiku 4.5 | $0.00024 | $0.00568 |
Grade C, and why
odoo-debug scanned grade C with 1 finding 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 7d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
`find <ISOLATE_DIR>/visual/debug/ -mindepth 1 -maxdepth 1 -type d -mmin +43200 -exec rm -rf {} +` How it starts
The opening of the file, as written. The whole thing — 314 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
Odoo debugging conductor. Own a symptom from first report to a PROVEN root cause (no fix before the cause is proven). Keep your own context clean for decisions; delegate each heavy investigation to a specialist debug agent, choosing the model per phase. Every brief you write is self-contained; every output you demand carries evidence, not guesses.
Method SSOT: ${CLAUDE_PLUGIN_ROOT}/skills/_shared/debug-method.md (defines the loop and the
mandatory Output Contract). Odoo symptom catalog:
${CLAUDE_PLUGIN_ROOT}/skills/_shared/odoo-failure-modes.md.
Out of Scope
- Writing the fix once the cause is proven →
odoo-coding - Proactive scan with no specific symptom (audit a module for latent issues) →
odoo-perf-audit,odoo-security-audit,odoo-deprecation-audit - Static review of a diff / PR / pasted block →
odoo-code-review - Rating a working screen (aesthetics/a11y/perf verdict) →
odoo-ui-review - Comparing two builds for visual drift →
odoo-visual-regression
MCP tools
Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.
This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.
Do NOT use Odoo Semantic for:
- LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.
Look-live-but-static tools (return indexed source, never runtime data):
model_inspect,module_inspect,entity_lookup,validate_domain,validate_depends,validate_relation,describe_module,check_module_exists,resolve_orm_chain. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 7d ago First seen · 314 lines · 240 tokens per session scan C 72c76420c221
odoo-debug is a skill published in the GitHub repository Viindoo/odoo-mcp-client (7 stars, last pushed 4d ago), licensed MIT. It adds 240 tokens to every session and 5,680 once invoked, about $0.0012 per session on Opus 5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
debug-optimize-lcp
Guides debugging and optimizing Largest Contentful Paint (LCP) using Chrome DevTools MCP tools. Use this skill whenever the user asks about LCP performance, slow page loads, Core Web Vitals optimization, or wants to understand why their page's main content takes too long to appear. Also use when the user mentions…
systematic-debugging
Use when debugging a failing test, build error, or runtime issue that isn't immediately obvious. Guides a 4-phase root cause analysis instead of random fix attempts.
diagnose
Trace from a reproduced symptom to the source code that causes it. Pin the specific file and approximate line, rate confidence in the cause and clarity of the fix independently, and always propose a concrete fix.
repro-admin
Reproduce an EmDash admin UI bug. Attach a container, start the demo dev server, drive the admin with agent-browser using the dev-bypass session, and capture the reproduction as screenshots plus a replayable transcript.
log-error-digest
Analyze log files to troubleshoot errors, identify peak error periods, and produce error clustering, frequency statistics, and time distribution reports. Supports JSON, syslog, and Nginx formats with automatic detection. Use when a user uploads a .log file and asks to analyze errors, find patterns, debug issues, or…
byted-util-volcengine-detect-retry
An orchestration workflow for Volcengine Cloud Detect, a service that checks websites or network endpoints from test locations.