Skip to main content
Glama
Sign In
erp2pdf-studio-mcp

erp2pdf-studio-mcp

by c4pointer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

search_records

Searches real Odoo records to find and select record IDs for value inspection or template preview rendering.

Instructions

Search real records in the customer's Odoo (needs a configured connector) to pick a record_id for get_values / render_preview.

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>"
    },
    "name": "search_records"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
modelYes
searchNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries more burden. It usefully discloses the configured-connector prerequisite and implies a read-only search, but it does not describe permissions, pagination behavior, result limits, or what the response contains.

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?

It is a single compact sentence with no wasted text. The core action and the downstream purpose are front-loaded, and the connector caveat is included efficiently.

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 no-annotation, no-output-schema tool, the description covers the key prerequisite and downstream use, and it implies that results include record_id. However, it leaves parameter behavior and result-shape details underexplained.

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

Parameters2/5

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

The input schema has 0% description coverage across three parameters. The description does not explain what model means in Odoo terms, what search matches against, or how limit affects results; it only implies the tool returns record_id values.

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

Purpose4/5

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

The description states a specific verb and resource: searching real Odoo records. It also clarifies the intended outcome, picking a record_id for get_values or render_preview, which helps distinguish it from template-related siblings.

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?

It gives clear when-to-use guidance: use this to obtain a record_id before calling get_values or render_preview. It also states the prerequisite that an Odoo connector must be configured, though it does not name explicit alternatives or when-not-to-use conditions.

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

Deploy Server

Other Tools