odoo-mcp-gateway

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, but some potential confusion exists between generic tools like create_record/update_record/delete_record and specific ones like create_ticket/update_ticket_stage. The generic tools could overlap with domain-specific operations, though descriptions help clarify their scope.
Naming Consistency4/5
Tools follow a consistent snake_case pattern with clear verb_noun structure (e.g., get_my_tickets, update_task_stage). Minor deviations include 'login' (no noun) and 'read_group' (unusual verb order), but overall naming is predictable and readable.
Tool Count3/5
With 27 tools, the count feels heavy for a single server, bordering on excessive. While Odoo is a broad ERP system, the toolset includes both generic (e.g., create_record) and specific operations, which could be streamlined or better organized.
Completeness5/5
The toolset provides comprehensive coverage for Odoo's core domains: attendance, sales, helpdesk, projects, and HR. It includes CRUD operations, specific workflows (e.g., confirm_order, request_leave), and utility tools (e.g., list_models, login), leaving no obvious gaps for agent interaction.
Average 3.1/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'execute a method' but doesn't disclose behavioral traits like whether it's read-only or destructive, what permissions are needed, error handling, or rate limits. This is inadequate for a tool that could perform arbitrary operations on Odoo models.
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?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded, though its brevity contributes to the lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations, but has an output schema), the description is incomplete. It doesn't explain the tool's role among siblings, behavioral implications, or parameter meanings. The output schema may help with return values, but the description fails to provide necessary context for safe and correct usage.
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?
Schema description coverage is 0%, so the description must compensate. It adds no meaning beyond the schema—it doesn't explain what 'model', 'method', 'record_ids', 'args', or 'kwargs' represent in Odoo context, leaving parameters semantically unclear. With 5 parameters, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('execute a method') and target ('on an Odoo model'), which provides a basic purpose. However, it's vague about what 'execute a method' entails—it could mean calling any Python method on any Odoo model, which is broad and lacks specificity compared to siblings like 'create_record' or 'update_record' that clearly indicate their operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for specific operations (e.g., 'create_record', 'update_record', 'get_record'), the description fails to indicate if this is a generic fallback or for specialized cases, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool updates records but lacks critical behavioral details: required permissions, whether changes are reversible, error handling, or side effects. This is inadequate for a mutation tool with zero annotation coverage.
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?
The description is a single, efficient sentence with no wasted words. It is front-loaded and directly states the tool's purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters, no annotations, but has an output schema), the description is insufficient. It lacks details on behavior, parameters, and usage context. The output schema may help with return values, but the description does not provide enough information for safe and effective use.
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?
Schema description coverage is 0%, so the description must compensate. It does not explain the parameters ('model', 'record_id', 'values') beyond what the schema titles imply, such as what 'model' refers to in Odoo or the format of 'values'. This leaves significant gaps in understanding.
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 clearly states the action ('Update') and target ('an existing record in an Odoo model'), making the purpose understandable. However, it does not differentiate from sibling tools like 'create_record' or 'delete_record' beyond the verb, missing specific distinctions about scope or constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid record ID), exclusions, or comparisons to siblings like 'create_record' or 'delete_record', leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool creates a record, implying a write operation, but does not disclose behavioral traits such as required permissions, whether the creation is idempotent, error handling, or what the output contains. This leaves significant gaps for a mutation tool.
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?
The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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?
Given that there is an output schema (which handles return values), the description's minimalism is somewhat acceptable. However, for a mutation tool with no annotations and 0% schema coverage, it should provide more context on usage, parameters, and behavior to be fully complete. It meets a baseline but has clear gaps.
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?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'record in an Odoo model' but does not explain what 'model' or 'values' parameters mean, their expected formats, or examples. It adds minimal semantic value beyond the bare parameter names.
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 clearly states the action ('Create a new record') and the resource ('in an Odoo model'), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'create_ticket' or explain what distinguishes this general record creation from other creation tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'create_ticket' or 'confirm_order', nor does it mention prerequisites like authentication or model availability. It lacks context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination behavior, error conditions, or what happens if no records match. The description is minimal and lacks critical operational context.
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 appropriately concise with two sentences: a clear purpose statement followed by parameter documentation. The parameter explanations are brief but informative. No unnecessary verbiage, though the formatting with indentation could be cleaner.
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?
Given the tool has an output schema (which handles return values), the description's main gaps are in behavioral transparency and usage guidelines. For a simple read tool with two parameters, the description is minimally adequate but lacks context about authentication, error handling, and sibling differentiation. It meets basic needs but leaves important questions unanswered.
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 0%, so the schema provides no parameter descriptions. The description adds basic semantics for both parameters: 'limit' as 'Max records to return (default 10)' and 'month' as 'Filter by month (YYYY-MM format, optional)'. This covers purpose and format but lacks deeper context (e.g., what happens if month is invalid, if limit applies before/after filtering).
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 clearly states the tool's purpose: 'Get attendance records for the current user.' It specifies the verb ('Get') and resource ('attendance records') with scope ('for the current user'). However, it doesn't explicitly differentiate from sibling tools like 'get_my_leaves' or 'get_my_tasks' which also retrieve user-specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the user must be logged in), nor does it contrast with other attendance-related tools (none are listed among siblings). The only implied usage is for retrieving personal attendance data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation, implying it's non-destructive, but doesn't cover critical aspects like authentication needs, error handling (e.g., for invalid IDs), rate limits, or the response format. This leaves significant gaps for a tool that interacts with a database.
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?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose, making it easy to scan and understand quickly without unnecessary elaboration.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but has an output schema), the description is incomplete. It covers the basic purpose but lacks usage guidelines, parameter details, and behavioral context. The presence of an output schema reduces the need to explain return values, but other gaps remain, making it only minimally adequate.
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?
Schema description coverage is 0%, meaning parameters are undocumented in the schema, so the description must compensate. It mentions 'by ID' which hints at the 'record_id' parameter and 'from any Odoo model' for the 'model' parameter, but doesn't explain the 'fields' parameter or provide details like format, constraints, or examples, failing to add sufficient meaning beyond the bare schema.
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 clearly states the action ('Read'), the resource ('a single record'), and the scope ('from any Odoo model'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar siblings like 'search_read' or 'get_order_details', which might also retrieve records, so it doesn't achieve full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid model name or record ID), exclusions, or compare it to siblings like 'search_read' for multiple records or 'get_order_details' for specific models, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation, implying it's non-destructive, but doesn't cover other important aspects like authentication needs, rate limits, error handling, or what the grouped output looks like. For a tool with 6 parameters and no annotation coverage, this is a significant gap in transparency.
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?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word contributes to understanding the tool's core function.
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?
Given the complexity (6 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for that in the description. However, for a data aggregation tool with multiple parameters and no behavioral annotations, the description should provide more context on usage and parameter meanings to be fully complete.
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?
Schema description coverage is 0%, meaning none of the 6 parameters have descriptions in the schema. The tool description mentions 'grouped/aggregated data' which hints at the purpose of 'groupby' and 'fields', but doesn't explain any parameters in detail—such as what 'model' refers to, how 'domain' filters data, or what 'orderby' does. It fails to compensate for the lack of schema descriptions.
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 clearly states the verb ('Read') and resource ('grouped/aggregated data from an Odoo model'), making the purpose understandable. It distinguishes this as a read operation with aggregation/grouping, which differentiates it from simple read operations like 'get_record' or 'search_read' among siblings. However, it doesn't explicitly contrast with all similar siblings like 'search_read' or 'get_sales_summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this grouped/aggregated read is preferred over other read operations like 'search_read' or 'get_record', nor does it specify prerequisites or exclusions. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('search and read') but lacks details on permissions required, rate limits, pagination behavior (beyond what the schema implies with limit/offset), error handling, or what the output contains. This is inadequate for a tool with 6 parameters and no annotation coverage.
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?
The description is a single, efficient sentence with zero waste—it directly states the tool's function without redundancy. It's appropriately front-loaded and concise for its 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?
Given the tool has 6 parameters, no annotations, and 0% schema description coverage, the description is incomplete—it lacks parameter explanations and behavioral context. However, an output schema exists (per context signals), which may cover return values, partially mitigating the need for output details in the description. This results in a minimal but not fully adequate level of completeness.
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?
Schema description coverage is 0%, meaning parameter titles like 'Model', 'Domain', and 'Fields' are not explained in the schema. The description adds no semantic context for these parameters—it doesn't clarify what a 'model' refers to in Odoo, what format 'domain' expects, or how 'fields' should be specified. This leaves critical gaps for an agent to use the tool correctly.
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 clearly states the action ('search and read records') and the resource ('from any Odoo model'), which is specific and informative. However, it doesn't explicitly differentiate from sibling tools like 'get_record' or 'search_count', which likely have overlapping functionality in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_record' (likely for single records), 'search_count' (likely for counting), and 'read_group' (likely for aggregated reads), there's no indication of context, prerequisites, or exclusions for this search-and-read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'moves' a task, implying a mutation, but lacks details on permissions, side effects, error handling, or rate limits. This is inadequate for a mutation tool with zero annotation coverage.
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 appropriately sized and front-loaded, with the core purpose stated first in a clear sentence. The 'Args' section is structured but includes some whitespace that doesn't add value, slightly reducing efficiency.
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?
Given the tool's complexity (mutation with 2 parameters), no annotations, and an output schema present, the description is minimally adequate. It explains the action and parameters but lacks behavioral details and usage context, making it incomplete for safe and effective use.
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 description includes an 'Args' section that lists and briefly describes the two parameters ('task_id' and 'stage_id'), adding meaning beyond the input schema's 0% description coverage. However, it doesn't specify format constraints, valid ranges, or examples, leaving gaps in parameter understanding.
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 clearly states the action ('Move') and resource ('a task to a different stage'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_ticket_stage' or 'update_record', which could involve similar operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for moving tasks, or comparisons to sibling tools like 'update_ticket_stage' or 'update_record', leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Create a new helpdesk ticket,' implying a write operation, but doesn't disclose behavioral traits like required permissions, whether it's idempotent, rate limits, or what the output contains. The description is minimal and lacks context beyond the basic action.
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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured Args section. There's no wasted text, though the formatting with indentation might be slightly verbose. Every sentence earns its place by adding 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?
Given the tool's complexity (a write operation with 4 parameters), no annotations, and an output schema (which exists but isn't shown here), the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. The output schema might handle return values, but the description doesn't hint at this, leaving gaps.
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 description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: 'name' as 'Ticket subject/title,' 'description' as 'Detailed description,' 'team_id' as 'Helpdesk team ID (optional),' and 'priority' with a detailed mapping ('0=Low, 1=Medium, 2=High, 3=Urgent'). This significantly clarifies the schema's bare fields.
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 clearly states the tool's purpose: 'Create a new helpdesk ticket.' This is a specific verb+resource combination that distinguishes it from siblings like 'get_my_tickets' or 'update_ticket_stage.' However, it doesn't explicitly differentiate from 'create_record' which might be a generic sibling, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), exclusions, or compare it to siblings like 'create_record' or 'update_ticket_stage.' The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a record, implying a destructive mutation, but fails to mention critical details like whether deletion is permanent, requires specific permissions, triggers cascading effects, or returns confirmation data. This leaves significant gaps for a mutation tool.
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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place in conveying the essential function.
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?
Given the tool's complexity (destructive mutation with 2 parameters) and the presence of an output schema (which may cover return values), the description is minimally adequate but incomplete. It lacks details on behavioral traits, parameter usage, and safety considerations, which are crucial for a delete operation, though the output schema might mitigate some gaps.
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 0%, so the schema provides no parameter details. The description adds minimal semantics by implying 'model' and 'record_id' identify what to delete, but it doesn't explain what an 'Odoo model' is, valid model names, or how record IDs are obtained. This partial compensation justifies a baseline score.
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 clearly states the action ('Delete') and resource ('a record from an Odoo model'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential alternatives like 'update_record' or 'create_record' in terms of destructive intent, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_record' or 'create_record', nor does it mention prerequisites (e.g., authentication, permissions) or warn about irreversible deletion. It's a basic statement of function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral aspects like authentication requirements, rate limits, error handling, or what the output contains. For a tool with no annotations, this leaves significant gaps.
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?
The description is a single, efficient sentence with no wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration.
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?
Given the tool has an output schema (which should document return values), the description doesn't need to explain outputs. However, with no annotations and 0% schema description coverage, it lacks context on usage, parameters, and behavior. The description is minimal but not fully adequate for a tool with three parameters and no annotation support.
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 0%, so the description must compensate. It mentions 'field definitions for an Odoo model,' which hints at the 'model' parameter but doesn't explain the other two parameters ('field_filter', 'include_readonly'). The description adds minimal value beyond the schema, failing to fully address the coverage gap.
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 clearly states the action ('Get') and resource ('field definitions for an Odoo model'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'list_models' or 'get_record', but the specificity of 'field definitions' provides reasonable distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_models' (which might list models) or 'get_record' (which retrieves data records). The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), implying non-destructive behavior, but doesn't mention authentication requirements, rate limits, pagination (beyond the 'limit' parameter), or what the output contains. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a concise parameter explanation. There's no wasted text, and the structure (purpose then args) is logical. Minor deduction because the parameter details could be slightly more integrated into the flow.
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?
Given that there's an output schema (which handles return values), no annotations, and only 2 parameters with good semantic coverage in the description, the description is minimally adequate. However, it lacks context on authentication, error handling, or how it differs from sibling tools, leaving room for improvement in completeness.
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 description adds meaningful context for both parameters: it explains that 'state' filters by specific states (draft, confirm, validate, refuse) and 'limit' sets a maximum record count with a default of 20. Since schema description coverage is 0% (titles only provide generic labels like 'State' and 'Limit'), this compensates well by clarifying the semantics beyond what the schema provides.
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 clearly states the tool's purpose: 'Get leave requests for the current user.' It specifies the verb ('Get') and resource ('leave requests'), and distinguishes it from siblings like 'request_leave' (which creates leave requests) and 'get_my_attendance' (which retrieves attendance data). However, it doesn't explicitly differentiate from all possible list/read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it over other 'get_my_' tools (e.g., 'get_my_tasks'), nor does it specify prerequisites like authentication or context. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get'), implying a read operation, but doesn't cover critical aspects like authentication requirements, rate limits, pagination (beyond the 'limit' parameter), error conditions, or what the output contains. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by parameter details in a structured format. There's no wasted text, though the formatting (indentation) could be cleaner. Every sentence adds value, making it efficient for an agent to parse.
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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is partially complete. It covers the purpose and parameters well, but lacks behavioral context (e.g., auth needs, error handling). The presence of an output schema means the description doesn't need to explain return values, but other gaps remain, making it adequate but with clear room for improvement.
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 description adds meaningful context for both parameters beyond the input schema, which has 0% description coverage. It explains that 'state' filters by specific states (draft, sent, sale, done, cancel) and 'limit' sets a maximum record count with a default of 20. This compensates well for the schema's lack of descriptions, though it doesn't detail data types or constraints (e.g., whether 'state' is case-sensitive).
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 clearly states the tool's purpose: 'Get quotations/orders where the current user is the salesperson.' It specifies the verb ('Get') and resource ('quotations/orders') with a clear scope filter ('where the current user is the salesperson'). However, it doesn't explicitly distinguish this tool from similar sibling tools like 'get_order_details' or 'search_read', which might also retrieve order-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_order_details' (for specific orders) or 'search_read' (for general queries), nor does it specify prerequisites (e.g., authentication status) or exclusions. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions filtering by state and project_id, and a default limit, but doesn't describe important behaviors like whether this is a read-only operation (implied by 'Get'), authentication requirements, pagination beyond the limit, error handling, or the format of returned data. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded: the first sentence clearly states the tool's purpose, followed by a structured 'Args' section that efficiently documents parameters. There's no unnecessary verbosity, and each part serves a clear function, though the formatting with indentation could be slightly cleaner for readability.
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?
Given that there's an output schema (which handles return values), no annotations, and moderate complexity with 3 parameters, the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral context (e.g., authentication, error handling) and usage guidelines. For a tool with no annotations, it should do more to compensate, but the presence of an output schema reduces the burden slightly.
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 description adds meaningful context for all three parameters: it explains that 'state' filters by task state with examples (e.g., '01_in_progress'), 'project_id' filters by project ID, and 'limit' sets a maximum record count with a default of 20. Since schema description coverage is 0% (titles only provide basic labels like 'State'), the description compensates well by clarifying parameter purposes and providing an example for 'state', though it doesn't detail data types or constraints beyond defaults.
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 clearly states the tool's purpose: 'Get tasks assigned to the current user.' It specifies the verb ('Get') and resource ('tasks assigned to the current user'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_my_tickets' or 'get_my_quotations' that follow similar patterns for other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites (e.g., authentication), exclusions, or compare it to similar sibling tools like 'get_my_tickets' or 'search_read' that might also retrieve task-related data. Usage is implied by the name and description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe important behaviors: whether this is a read-only operation, what authentication is required, how results are returned (format, pagination), error conditions, or rate limits. The description is functional but lacks operational context.
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 well-structured and appropriately sized. The purpose is stated clearly in the first sentence, followed by parameter details in a structured format. There's no wasted text, though the parameter documentation could be slightly more integrated with the main description rather than appearing as a separate 'Args' section.
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?
Given that there's an output schema (which handles return values), the description covers the basic purpose and parameters adequately. However, for a tool with 3 parameters and no annotations, it should provide more behavioral context about authentication, error handling, and typical usage patterns. The parameter documentation is strong, but operational context is lacking.
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 description provides excellent parameter semantics beyond the schema. While schema description coverage is 0%, the description explains: 'state: Filter by stage name (optional)', 'priority: Filter by priority (0=Low, 1=Medium, 2=High, 3=Urgent)', and 'limit: Max records (default 20)'. This adds crucial meaning about what each parameter does, including the priority encoding and default 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 clearly states the tool's purpose: 'Get helpdesk tickets assigned to the current user.' It specifies the resource (helpdesk tickets) and scope (assigned to current user). However, it doesn't explicitly distinguish this tool from potential siblings like 'get_my_tasks' or 'get_my_quotations' which follow similar patterns for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_ticket' (if it existed) or 'search_read' which might retrieve tickets with different filtering capabilities. There's no context about prerequisites, authentication needs, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, error conditions, or response format. This leaves significant gaps for a tool with no annotation coverage.
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 appropriately sized and front-loaded, with the main purpose stated concisely in the first sentence. The Args section is structured but could be more integrated; overall, it avoids unnecessary verbosity while conveying essential information 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?
Given the tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is minimally adequate. It explains what data is retrieved but lacks details on behavioral traits and usage context. The presence of an output schema mitigates the need to describe return values, but more guidance would improve completeness.
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 description adds meaningful context for the single parameter by specifying that 'project_id' is used to identify the project to summarize. With 0% schema description coverage and only one parameter, this adequately compensates, providing clear semantics beyond the basic schema type.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('project stats'), detailing what information is retrieved (task counts by stage, overdue, recent activity). It distinguishes itself from siblings like get_my_tasks or get_sales_summary by focusing on project-level summary data, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for active projects only or how it differs from get_record or get_sales_summary. Usage is implied only by the description's content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering but does not cover critical aspects like pagination, rate limits, authentication needs, error handling, or what 'available' entails (e.g., permissions-based). This leaves significant gaps for a tool that likely interacts with a database.
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?
The description is extremely concise—just one sentence—and front-loaded with the core purpose. There is no wasted verbiage, making it easy to parse quickly, though this brevity contributes to gaps in other dimensions.
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?
Given the tool's moderate complexity (listing models with filtering), no annotations, and an output schema that likely handles return values, the description is incomplete. It lacks behavioral details and usage context, but the presence of an output schema mitigates some need to explain returns, keeping it at a minimally adequate level.
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 description adds some meaning by mentioning 'filter by keyword,' which hints at the 'filter' parameter's purpose, but does not explain 'include_custom' or provide details beyond the schema's basic titles. With 0% schema description coverage, this partial compensation is minimal, aligning with the baseline for moderate value addition.
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 clearly states the verb ('List') and resource ('available Odoo models'), making the purpose evident. However, it does not distinguish this tool from potential siblings like 'get_model_fields' or 'search_read' that might also involve models, leaving room for ambiguity in a crowded toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance with 'Optionally filter by keyword,' but offers no explicit when-to-use advice, prerequisites, or alternatives among the many sibling tools (e.g., vs. 'get_model_fields' for field details or 'search_read' for records). This lack of context makes it hard for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions authentication methods but doesn't describe what happens after authentication (e.g., session creation, token return, error handling), whether it's idempotent, or what permissions are needed. The description provides minimal behavioral context beyond the basic action.
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?
The description is extremely concise with just one sentence that efficiently communicates the core purpose and available methods. Every word earns its place with no wasted text, making it easy to parse and understand quickly.
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?
Given this is an authentication tool with 4 parameters (2 required), 0% schema coverage, no annotations, but with an output schema, the description provides minimal but functional context. The output schema likely handles return values, but the description lacks details about authentication flow, error cases, or integration with other tools. It's adequate but has clear gaps for a security-critical operation.
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?
With 0% schema description coverage, the description partially compensates by listing the three authentication methods ('api_key', 'password', 'session') which helps interpret the 'method' parameter. However, it doesn't explain the 'credential', 'username', or 'database' parameters, leaving 3 of 4 parameters without semantic clarification beyond their titles.
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 clearly states the tool's purpose: 'Authenticate with Odoo' specifies the verb (authenticate) and target system (Odoo). It distinguishes from siblings by focusing on authentication rather than data operations. However, it doesn't explicitly differentiate from potential alternative authentication methods in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions three authentication methods but doesn't explain when to choose one over another, nor does it mention prerequisites like needing credentials or when authentication is required versus using existing sessions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool submits a leave request, implying a write operation, but lacks critical details: whether it requires authentication, approval workflows, rate limits, error conditions (e.g., invalid dates), or what happens on success/failure. This leaves significant gaps for a mutation tool.
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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. Each sentence adds value without redundancy. Minor improvements could include briefer formatting or integrating usage hints, but it remains efficient overall.
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?
Given a mutation tool with no annotations, 4 parameters, and an output schema (which reduces need to describe returns), the description is partially complete. It covers parameter semantics well but lacks behavioral context (e.g., auth needs, side effects) and usage guidelines, making it adequate but with clear gaps for reliable agent operation.
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 description adds meaningful semantics for all parameters beyond the schema's 0% coverage. It explains 'leave_type_id' with examples (e.g., annual leave), clarifies date formats (YYYY-MM-DD), and notes 'reason' as optional. This compensates well for the schema's lack of descriptions, though it could specify ID sources (e.g., from 'get_my_leaves').
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 clearly states the tool's purpose with a specific verb ('Submit') and resource ('leave request'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_my_leaves' or 'get_my_attendance', which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication via 'login'), exclusions (e.g., overlapping dates), or related tools like 'get_my_leaves' for checking existing requests, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions counting records but fails to describe critical behaviors: whether this is a read-only operation, if it requires specific permissions, how it handles large datasets or pagination, or what the output format looks like (though an output schema exists).
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?
The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose ('Count records') and directly states the key parameters ('matching a domain in an Odoo model'), making it easy to parse quickly.
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?
Given the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter explanations. The existence of an output schema mitigates the need to describe return values, but other gaps remain significant.
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 0%, so the description must compensate. It mentions 'domain' and 'Odoo model', which aligns with the two parameters ('model' and 'domain'), but doesn't explain what constitutes a valid model name, the structure of a domain array, or that 'domain' is optional with a default of null. This adds some meaning but leaves key details uncovered.
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 clearly states the action ('Count records') and target ('matching a domain in an Odoo model'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_read' (which likely returns records rather than just a count), leaving room for improvement in sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_read' for retrieving records or 'read_group' for aggregated counts, nor does it specify prerequisites such as needing a valid model name or authenticated session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It implies a mutation ('Move'), but doesn't disclose permissions needed, whether the operation is reversible, rate limits, error conditions (e.g., invalid stage), or what happens to ticket history. This is inadequate for a mutation tool with zero annotation coverage.
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 appropriately sized with two sentences: a clear purpose statement followed by parameter documentation. It's front-loaded with the core functionality, though the Args formatting adds some verbosity. Every sentence adds value, with no wasted content.
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?
Given the tool's mutation nature, 2 parameters, 0% schema coverage, no annotations, but with an output schema present, the description is partially complete. It covers purpose and parameters adequately, but lacks behavioral context (permissions, side effects) and usage guidelines. The output schema may handle return values, but the description should still address mutation risks.
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 description explicitly documents both parameters in the Args section, adding meaning beyond the schema (which has 0% description coverage). It clarifies that 'ticket_id' identifies the ticket to update and 'stage_id' is the target stage, compensating for the schema's lack of descriptions. However, it doesn't specify format details (e.g., numeric IDs) or constraints.
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 clearly states the tool's purpose with a specific verb ('Move') and resource ('helpdesk ticket'), and specifies the action ('to a different stage'). It distinguishes itself from generic update operations by focusing on stage transitions, though it doesn't explicitly differentiate from the sibling 'update_task_stage' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., ticket must exist, stage must be valid), exclusions (e.g., cannot move to certain stages), or compare it to similar tools like 'update_task_stage' or 'update_record'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation but doesn't disclose authentication requirements, rate limits, error conditions, or what 'employee profile' entails (e.g., personal details, role). This is inadequate for a tool with zero annotation coverage.
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?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a simple, parameter-less tool and avoids redundancy.
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?
Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and an output schema that likely defines return values, the description could better clarify the scope of 'employee profile' or authentication needs, leaving some contextual gaps.
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 tool has zero parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
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 clearly states the action ('Get') and the resource ('the current user's employee profile'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_my_attendance' or 'get_my_tasks' that also retrieve user-specific data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication status), exclusions, or relationships to other tools like 'get_record' or 'get_my_attendance', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a read operation ('Get'), which implies it's non-destructive, but doesn't disclose any behavioral traits like authentication needs, rate limits, error handling, or what happens if the order_id doesn't exist. This is inadequate for a tool with no annotation coverage.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args section is necessary given the schema coverage gap. There's minimal waste, though the formatting includes extra whitespace that slightly reduces efficiency.
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?
Given the tool's low complexity (single parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter semantics adequately, though it lacks behavioral context and usage guidelines, which holds it back from a perfect score.
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 description includes an Args section that documents the single parameter 'order_id' as 'The sale order ID', adding semantic meaning beyond the schema (which has 0% description coverage and only provides type integer). This fully compensates for the schema gap, but since there's only one parameter, it doesn't reach the highest score.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('full order details'), and specifies what details are included (lines, totals, partner info). However, it doesn't differentiate from similar sibling tools like 'get_record' or 'get_sales_summary', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_record' or 'get_sales_summary', nor does it mention any prerequisites or context for usage. The only implied usage is retrieving order details, but without comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the state requirement ('draft/sent state'), which adds some context, but fails to cover critical aspects like permissions needed, whether the action is reversible, side effects, or error handling. For a mutation tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, with the core purpose stated first. The Args section is clear but could be more integrated. There's minimal waste, though the formatting with indentation might slightly affect readability.
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?
Given the tool has an output schema (which handles return values) and only one parameter with good semantic coverage in the description, the description is moderately complete. However, as a mutation tool with no annotations, it should provide more behavioral context (e.g., confirmation effects, error cases) to be fully adequate.
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 description adds meaningful semantics for the single parameter: 'order_id: The sale order ID to confirm (must be in draft/sent state)'. Since schema description coverage is 0%, this compensates well by explaining what the parameter represents and its constraints. However, it doesn't detail format or validation rules beyond the state requirement.
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 clearly states the tool's purpose: 'Confirm a quotation, turning it into a sale order.' It specifies the verb ('confirm') and resource ('quotation'), and indicates the outcome ('sale order'). However, it doesn't explicitly differentiate from sibling tools like 'get_my_quotations' or 'get_order_details', which reduces the score from a perfect 5.
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 implied usage guidance by mentioning the prerequisite state ('must be in draft/sent state'), which helps indicate when to use this tool. However, it lacks explicit alternatives (e.g., when not to use it or what other tools might be relevant) and doesn't compare to siblings like 'update_record' or 'create_record', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the core behavior (finding open record and setting check_out time) but lacks important details: whether this requires authentication, what happens if no open record exists (error? silent failure?), what the output contains, or any side effects. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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?
The description is extremely concise—two short sentences that directly explain the tool's purpose and behavior. Every word earns its place, with no redundant information. The structure is front-loaded with the primary action, followed by implementation details. This is a model of efficiency.
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?
Given that this is a mutation tool with no annotations but has an output schema, the description is minimally adequate. It explains what the tool does but misses important context like error conditions, authentication requirements, and what 'now' means (server time vs. client time). The output schema will handle return values, but the description should cover more behavioral aspects for a tool that modifies data.
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 tool has 0 parameters with 100% schema description coverage. The description correctly doesn't waste space explaining non-existent parameters. It adds context about what the tool does internally (finds open record, sets check_out to now), which provides semantic meaning beyond the empty schema. This is appropriate for a parameterless tool.
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 the specific action ('Record attendance check-out'), the target resource ('attendance record'), and the scope ('for the current user'). It distinguishes from sibling tools like 'check_in' by specifying the opposite operation. The description provides a complete picture of what the tool does without being tautological.
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 implies usage context by mentioning 'Finds the open attendance record,' suggesting it should be used when there's an existing open attendance record to close. However, it doesn't explicitly state when NOT to use it (e.g., if no open record exists) or name alternatives like 'check_in' for starting attendance. The guidance is present but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action ('creates an attendance record') and timing ('set to now'), but lacks details on permissions, error handling, or response format, leaving gaps in understanding the tool's behavior.
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 and front-loaded with the main purpose in the first sentence, followed by additional details. However, the second sentence could be slightly more streamlined, and there is minor formatting whitespace that doesn't affect clarity.
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?
Given the tool's simplicity (0 parameters, has output schema), the description is reasonably complete. It explains what the tool does and its context, but could benefit from more behavioral details since no annotations are provided to cover safety or response aspects.
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 tool has 0 parameters with 100% schema description coverage, so no parameter information is needed in the description. The baseline for this scenario is 4, as the description appropriately focuses on the tool's purpose without redundant parameter details.
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 the specific action ('Record attendance check-in'), identifies the resource ('for the current user'), and distinguishes it from sibling tools like 'check_out' and 'get_my_attendance' by focusing on creating a check-in record rather than checking out or retrieving attendance data.
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 implies usage context by specifying 'for the current user' and linking to an employee, but it does not explicitly state when to use this tool versus alternatives like 'check_out' or 'get_my_attendance', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool returns and the optional period parameter, but doesn't cover important aspects like authentication requirements, rate limits, error handling, or whether it's a read-only operation (implied by 'Get' but not explicit). It adds some context about the period filter but misses broader behavioral traits.
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?
The description is well-structured and appropriately sized. It starts with the core purpose, lists the return values, then provides parameter details in a clear 'Args' section. Every sentence adds value without redundancy, making it easy to scan and understand quickly.
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?
Given the tool's moderate complexity (1 parameter, no annotations, but has output schema), the description is mostly complete. It explains the purpose, return values, and parameter semantics effectively. Since an output schema exists, it doesn't need to detail return values further. The main gap is lack of behavioral context like authentication or error handling, but overall it provides sufficient information for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema, which has 0% description coverage. It explains the 'period' parameter's purpose ('Filter period'), format ('YYYY-MM'), optional nature, and default behavior ('If omitted, returns all-time stats'). This fully compensates for the schema's lack of descriptions, providing clear semantics for the single parameter.
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 clearly states the tool's purpose: 'Get aggregated sales stats for the current user' with specific details about what stats are returned (counts by state, totals by month, top customers). It distinguishes itself from siblings like get_my_profile or get_my_tickets by focusing on sales data, though it doesn't explicitly differentiate from get_project_summary or get_order_details which might also involve data aggregation.
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 implies usage for retrieving sales statistics for the current user, but doesn't explicitly state when to use this tool versus alternatives like get_my_quotations or get_order_details. It provides some context by specifying it's for 'current user' and 'aggregated sales stats,' but lacks clear guidance on exclusions or direct comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![odoo-mcp-gateway MCP server](https://glama.ai/mcp/servers/parth-unjiya/odoo-mcp-gateway/badges/card.svg)](https://glama.ai/mcp/servers/parth-unjiya/odoo-mcp-gateway)

Score Badge

Copy to your README.md:

[![odoo-mcp-gateway MCP server](https://glama.ai/mcp/servers/parth-unjiya/odoo-mcp-gateway/badges/score.svg)](https://glama.ai/mcp/servers/parth-unjiya/odoo-mcp-gateway)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/parth-unjiya/odoo-mcp-gateway'

If you have feedback or need assistance with the MCP directory API, please join our Discord server