Odoo Claude MCP

ai_usage_log_export

Export billing ledger rows as CSV for a specific tenant and date range to support month-end invoice generation and audit trails.

Instructions

Export billing ledger rows as CSV for a tenant + date range. Used for month-end invoice generation and audit trails.

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": "ai_usage_log_export"
  }
}

Input Schema

Name	Required	Description	Default
`date_to`	No	ISO-8601 UTC (inclusive).
`date_from`	No	ISO-8601 UTC (inclusive).
`connection`	No		default
`tenant_code`	No	Tenant slug. Derived from connection if omitted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0May 28, 2026

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. While 'Export' implies a non-destructive read operation, the description does not explicitly state that the tool is read-only, that it does not modify data, or any authentication/rate limit constraints. This leaves ambiguity about side effects.

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

Conciseness5/5

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

Two concise sentences: the first clearly defines what the tool does, and the second provides the intended use case. No redundant information; every sentence adds value.

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

Completeness3/5

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

For a tool without an output schema, the description does not specify how the CSV output is delivered (e.g., as a download URL, raw data in response). It also lacks details on execution limits or error conditions, leaving some gaps for the agent.

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

Parameters3/5

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

The input schema has 75% description coverage, with parameters for tenant, date range, and connection. The description reinforces the purpose of tenant and date range but does not add new meaning beyond the schema, nor does it explain the 'connection' parameter (which lacks a schema description).

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?

The description specifies the exact action (export), the resource (billing ledger rows), and the format (CSV), with a clear scope (tenant + date range). It distinguishes itself from sibling tools like ai_usage_log_query and ai_usage_log_stats by focusing on export for invoice generation and audits.

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

Usage Guidelines3/5

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

The description provides a usage context ('month-end invoice generation and audit trails') that implies when to use, but does not explicitly state when not to use or name alternatives. An agent would need to infer usage from context rather than direct guidance.

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

Deploy Server