Prosp

Connect Odoo CRM

set_odoo_credentials

DestructiveIdempotent

Connect your own Odoo CRM so your discovered prospects sync into it. Provide your Odoo URL, database name, API-user id and API key (generate one under Preferences -> Account Security -> New API Key). The connection is validated live against your Odoo before it is saved; your API key is stored encrypted and is NEVER shown back — present a masked confirmation (e.g. odoo_api_key: ****) to the user. Calling this again updates the existing connection.

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": {
      "credentials": "<credentials>"
    },
    "name": "set_odoo_credentials"
  }
}

Input Schema

Name	Required	Description	Default
`credentials`	Yes	A customer's own Odoo CRM connection details. Mirrors the ``POST /api/v1/tenant/odoo-connection`` request body the odoo-sync onboarding router expects (``_validate_shape``) field-for-field — the endpoint contract is the single source of truth, so we do NOT invent a divergent schema. ``customer_id`` is deliberately absent: identity is the JWT-derived ``X-Customer-Id`` header set at the gateway, so a customer can only ever set THEIR OWN credentials. The connector adds no validation of its own — the live ``/jsonrpc`` auth probe + SSRF guard + FK audit all run server-side before anything is stored (a thin bridge; business logic lives behind the gateway). ``odoo_api_key`` is a SECRET: it is sent in the request body (never a query param, never logged) and is never echoed back — the gateway + odoo-sync response filters strip it, so any confirmation the agent shows must mask it.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds real context beyond the annotations: live validation against Odoo before saving, encrypted key storage, the key never being echoed back, and the instruction to present a masked confirmation. This is exactly the kind of secret-handling guidance annotations cannot convey. It does not explain what the destructiveHint=true means in practice — whether an existing connection's settings or synced prospects are replaced on re-call — which is the one behavior an agent could still get wrong.

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 purpose, then credentials, then secret/masking handling — a sensible order. It is dense but every sentence carries operational weight; the only mild redundancy is repeating the key-generation path already present in the schema.

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

Completeness4/5

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

For a single-nested-object mutation tool with an output schema and rich annotations, the description covers purpose, inputs, validation timing, secret handling, and idempotence. It omits what a failed validation returns and what exactly gets overwritten on an update, which would matter given destructiveHint=true.

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?

Schema description coverage is 100%, so the nested credential fields (including the optional team_id, user_id, stage_id, lead_type, enrichment_stage_id) are already fully documented. The description restates the four required fields and the key-generation path, adding convenience but no meaning the schema lacks. Baseline 3 applies.

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?

States a specific verb and resource ("Connect your own Odoo CRM") plus the outcome ("so your discovered prospects sync into it"). An agent can easily separate this from siblings like get_crm_connection, disconnect_crm, or set_seller_profile.

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 clear preconditions (supply URL, db, API-user id, API key) and the key lifecycle rule "Calling this again updates the existing connection," which tells the agent this is safe to re-run rather than needing a separate update tool. It stops short of explicitly routing the agent (e.g. check get_crm_connection first, or use disconnect_crm to tear down), so it isn't a full when/when-not/alternatives statement.

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

All Prosp 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.

Resources

Need Help?