MCP for Claude & ChatGPT

Read an attachment

odoo_attachment_content

Read-only

List attachments on an Odoo record or fetch the content of one attachment. In list mode (res_model + res_id) returns only metadata (no binary). In fetch mode (attachment_id) returns the content itself: text for text/, json/xml/csv/yaml, SVG and Office documents (docx/xlsx/xls, text-extracted). In the chat its text comes whole when it fits, and with the sandbox on the file is also there under the name in file: when the text does not fit, read it with execute_code. Without the sandbox a text that does not fit comes in pages: call again with the offset it gives. Pass limit for a slice of your own (in the chat it is capped by what is left of the turn's share). Elsewhere the text is paginated via offset/limit, in chars. The image for image/ (tiff/bmp/heic are converted to PNG); the document for application/pdf. A PDF is routed by what it is: mostly-scanned pages travel as the document itself, a text PDF comes back as Markdown you can page through. Text and Office have size caps (5 MB / 10 MB), and a PDF or image that travels as BYTES has one too; oversize ones return an error with metadata so the LLM can explain. Audio (up to 25 MB) comes back as its transcript, paged like any text: transcribing spends from the chat budget, once per file, and over MCP it needs a chat seat. Video and archives return metadata with an explicit reason — for a video on Google Drive, use video_ask instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "odoo_attachment_content"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max chars to return for text content (default 8000 outside the chat). In the chat, omit it to get the whole text when it fits.
`offset`	No	Char offset for text content pagination.
`res_id`	No	Record ID to list attachments for (use with res_model).
`res_model`	No	Model name to list attachments for (use with res_id).
`attachment_id`	No	ID of the ir.attachment record to fetch.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Well beyond the readOnly/destructive hints, it discloses the full behavioral profile: per-type return shapes (text, image, PDF as document or Markdown, audio transcript), size caps (5 MB text / 10 MB Office / 25 MB audio), what happens on oversize (error with metadata returned), transcription budget cost 'once per file' and the chat-seat requirement, and that video/archives deliberately return metadata with a reason. This is exactly the context annotations cannot carry.

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

Conciseness3/5

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

Front-loaded correctly with the two modes, and most sentences carry load, but it is delivered as one long undifferentiated block mixing return types, pagination, size caps and budget rules. A few sentences are dense run-ons ('The image for image/* (tiff/bmp/heic are converted to PNG); the document for application/pdf') that would scan far faster as mode-grouped bullets.

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?

There is no output schema, so the description carries the entire return-value burden — and it does, covering text, Office extraction, image conversion, PDF routing by scan-vs-text, audio transcripts, and the metadata-only outcomes for video/archives. Combined with the mutation-free annotations, an agent has everything needed to call it and interpret the result.

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 100%, so the baseline is 3, but the description adds real semantics on top: limit is capped by what remains of the turn's share in chat, offset/limit are measured in chars, and omit-limit yields whole text when it fits. It does not clarify whether res_model/res_id together constitute an implicit requirement (schema shows zero required params), which is the remaining ambiguity.

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 dual-mode statement: 'List attachments on an Odoo record or fetch the content of one attachment,' and immediately binds each mode to its parameters (res_model + res_id vs attachment_id). An agent knows exactly what the tool does and which mode it will get without opening the schema. It also implicitly distinguishes itself from odoo_search_read/odoo_execute siblings by being attachment-specific.

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?

Gives explicit mode-selection conditions and names real alternatives: read oversized text with execute_code, and 'for a video on Google Drive, use video_ask instead.' It does not state when to prefer listing attachments here versus querying ir.attachment via odoo_search_read, which is the one adjacent alternative left to inference.

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

All MCP for Claude & ChatGPT tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.