Skip to main content
Glama

MCP for Claude & ChatGPT

Edit HTML fields by section

odoo_html
Destructive

Work on one html field (e.g. knowledge.article body, project.task description) by its parts, on the raw HTML. action='outline' lists the headings (unique anchors: the heading text, 'Text#2' when repeated) with each section's size; 'read' returns the field or one section; 'grep' finds the literal pattern across ids with the blocks around each hit; 'edit' applies exact {find, replace} edits (each find must match once, or nothing is written; replace_all:true renames a term everywhere in the field); 'replace_section' swaps the body under a heading for html (the body runs to the next heading of the same or a higher level, so its subsections go too). outline/read/grep return a version of the value; edit/replace_section REQUIRE it and write nothing if the field changed since. Writes need the model on the write whitelist. The answer carries the saved HTML of what changed, the new version and warning when Odoo's sanitizer altered it. Html fields take markdown, converted the Odoo way: - [ ]/- [x] checklists, pipe tables, ##/### sections, --- separators. No inline style, invented classes or invented image URLs. edit takes raw HTML, not markdown: write the same markup, <ul class="o_checklist"> (<li class="o_checked"> when done), <table class="table table-bordered o_table">. When updating, fit new content into its section or list instead of appending it at the end, and keep what is there unless the user asked to remove it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "model": "<model>",
      "field": "<field>",
      "action": "<action>"
    },
    "name": "odoo_html"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoRecord id (all actions but grep).
idsNoRecord ids for grep.
htmlNoreplace_section: the new body under the heading (the heading stays), raw HTML; markdown is converted.
editsNoedit: exact raw-HTML find/replace pairs, applied in order.
fieldYesAn html field of the model.
modelYesOdoo model technical name.
actionYes
contextNogrep: blocks before and after each hit.
patternNogrep: literal text, case-insensitive.
sectionNoSection anchor from outline (read, replace_section).
versionNoRequired for edit/replace_section: the `version` from your last read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructiveHint=true, and the description adds the operational detail that matters: optimistic concurrency via `version` (edits write nothing if the field changed), all-or-nothing matching ('each find must match once, or nothing is written'), a model whitelist requirement, and sanitizer-induced warnings. It also discloses what the response returns (saved HTML, new version, warning), which no annotation conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose followed immediately by the action inventory, so an agent can stop reading after the first two sentences in simple cases. The trailing markdown/HTML formatting rules are long and dense but arguably load-bearing for correct `edit` payloads; a few clauses (e.g. the checklist/table class examples) could be trimmed to a reference.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, five-action mutation tool with no output schema, the description covers the full loop: discovery (outline), retrieval (read/grep), concurrency contract (version), write semantics (edit/replace_section), and return shape. The markdown-vs-raw-HTML distinction, which is the most likely source of silent failure, is stated explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 91%, so the baseline is 3; the description still adds value by explaining anchor syntax ('the heading text, Text#2 when repeated') and tying `version`, `pattern`, `context`, and `html` to specific actions. It stops short of documenting `id` vs `ids` routing (left to schema) and doesn't clarify size limits on `ids`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Work on one html field ... by its parts, on the raw HTML', then enumerates the five actions with what each one does. This is clearly distinguishable from generic siblings like odoo_write or odoo_execute, which operate on whole records rather than HTML sections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Each action carries its own selection rule (outline before editing to get anchors; edit for exact find/replace; replace_section to swap a heading body). The sequential workflow is implied (outline → read → version → edit), but the description never explicitly says when to prefer this tool over odoo_write for HTML fields, so the sibling routing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.