Odoo Claude MCP

telegram_auth

Authenticate with the Odoo Claude MCP server via Telegram. Provide your phone number to receive a verification code, then submit the code to complete login.

Instructions

Authenticate with Telegram. Two-step process: 1) Call with phone → code is sent to Telegram. 2) Call with phone + code → authenticated. If 2FA enabled, provide password too.

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": {
      "phone": "<phone>"
    },
    "name": "telegram_auth"
  }
}

Input Schema

Name	Required	Description
`code`	No	Verification code from Telegram (step 2)
`phone`	Yes	Phone number with country code (e.g. +359886100204)
`password`	No	2FA password if enabled

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0May 28, 2026

TDQS

A4/5.0

Behavior3/5

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

The description discloses the two-step process and the optional 2FA step, which is a key behavioral trait. No annotations are provided, so the description carries full burden. However, it omits details such as whether the tool sets a session or what happens on success/failure. It adequately explains the core behavior but lacks some edge cases.

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?

The description is concise, using one sentence with enumerated steps. It wastes no words. However, it could benefit from clearer structuring (e.g., bullet points or separate lines) to improve readability, but overall it is efficient and front-loaded with the purpose.

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?

The description covers the multi-step authentication process and all parameters adequately. However, it does not describe the return value or output of the tool after successful authentication, which is a gap. Given no output schema, the description should at least mention what to expect (e.g., 'returns session token'). It is complete for the process but incomplete regarding results.

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?

The input schema covers all three parameters with descriptions. The description adds value by explaining the role of each parameter in the authentication flow: phone for both steps, code for step 2, and password if 2FA enabled. Since schema coverage is 100%, baseline is 3, but the description provides meaningful ordering and conditions, earning a 4.

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 clearly states 'Authenticate with Telegram' and outlines the two-step process, distinguishing it from other Telegram tools like telegram_auth_status (checking status) or telegram_send_message (messaging). The specific verb 'Authenticate' combined with the step-by-step explanation makes the purpose unambiguous.

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?

The description provides clear context on when to use the tool: for authentication via two-step process. It explains the sequence of providing phone, then code, and optionally password for 2FA. However, it lacks explicit guidance on when not to use it (e.g., if already authenticated, use telegram_auth_status instead).

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

Deploy Server