Odoo 17 Project Management MCP

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 clear resource+action boundaries (list/get/create/update/delete), and descriptions explicitly disambiguate potentially similar pairs like task state vs. Kanban stage and archive vs. delete. The main residual ambiguity is between the generic update_task and specialized mutators such as move_task_to_stage, set_task_state, and set_task_tags.
Naming Consistency5/5
Tool names consistently follow a snake_case verb_noun pattern: get_, list_, create_, update_, delete_, set_, move_, archive_, add_, and check_. Minor outliers like check_odoo_connection are still predictable and do not break the overall pattern.
Tool Count2/5
With 32 tools, the surface is substantially above the 3-15 well-scoped range and falls into the 25+ 'too many' band. While the Odoo project-management domain is broad, the large number of specialized mutators and lifecycle operations creates meaningful selection overhead for an agent.
Completeness3/5
Core task and timesheet CRUD is well covered, and projects, stages, tags, and milestones have read/create/update support. However, there are notable lifecycle gaps: no delete or archive for projects, stages, tags, or milestones, and no way to read or delete task comments.
Average 3.6/5 across 32 of 32 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a useful project-scoping constraint not covered by annotations. However, it doesn't disclose side effects, permission requirements, or what 'allowed project' means concretely. Annotations already signal it is a non-read-only, non-destructive write, so no contradiction exists.
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 a single compact sentence that front-loads the core action and scoping constraint with zero filler. It is concise, though it omits important detail.
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?
With five parameters, two required, and an output schema, the tool is moderately complex. The description does not clarify how parameters should be populated (e.g., what 'scoped' means for project_id) or how to interpret 'allowed project'. An agent would need more context to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. It fails to explain project_id, name, sequence, fold, or description, leaving the agent without any semantic guidance for the five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('Kanban column'), and a scoping constraint ('exactly one allowed project'). This distinguishes it from sibling create tools like create_task and create_project, though it doesn't name an alternative directly.
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 update_project_stage or move_task_to_stage. It also doesn't mention prerequisites such as verifying the project is in the allowed list, nor does it state when not to use this tool.
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?
Annotations already indicate a non-read-only, non-idempotent mutation, and the description merely restates that a task is created. It adds no extra behavioral context such as side effects, permissions, duplicate handling, or consequences of missing required fields. There is no contradiction, but no added transparency beyond the annotation flags.
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 a single sentence with no filler and the main action is front-loaded. It is concise and all words contribute. However, the field list is unordered and flat, giving it slightly less structure than an ideal definition.
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?
With 12 parameters, 2 required, and no schema descriptions, the definition is too thin for reliable invocation. An agent cannot tell that project_id and name are mandatory or understand unmentioned optional fields. An output schema exists, but the input side is under-documented for a creation tool of this complexity.
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 is the only semantic source for parameters. It maps some schema names to domain terms (assignees, estimate, parent, blockers), but it omits the required project_id and name, as well as deadline, priority, and milestone_id. The term 'estimate' is ambiguous and types/units are not clarified.
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 opens with 'Create a task...' which is a specific verb and resource, and lists several configurable fields. It clearly signals this is a creation tool rather than a listing or update tool. However, it does not distinguish create_task from the sibling create_subtask, and the mention of 'parent' blurs that boundary.
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 given about when to use this tool versus alternatives like create_subtask, update_task, or create_project. It does not state prerequisites, such as whether the project must already exist or whether assignees/stages must be valid. An agent is left to infer usage from the tool name alone.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that the output is a point-in-time snapshot grouped by columns, which is useful context. It does not mention pagination, limit, or archived-item behavior, but those are partially reflected in the schema defaults.
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?
A single sentence that front-loads the key behavior and grouping. It contains no filler and does not duplicate schema or annotation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only board reader with an output schema and annotations, the description is workable but leaves the agent to infer usage context and parameter semantics. The missing guidance on when to use it and what include_archived means prevents it from being fully self-contained.
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% and the tool description does not mention project_id, limit, or include_archived. The parameter names are fairly self-explanatory and the schema provides types and defaults, but the description fails to clarify the effect of include_archived or limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('planning snapshot grouped by Kanban columns'), and names example columns ('Backlog/In Progress/etc.'). It conveys a board-level read distinct from task-level tools, though it does not explicitly differentiate from siblings like list_tasks or get_project_workload.
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 given about when to use this tool versus alternatives such as get_project, list_tasks, or get_project_workload. The read-only nature and column grouping imply a board-overview use case, but the description never states when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds two valuable behaviors beyond the annotations: it explicitly states that only supplied fields are modified, and it highlights the need for explicit clear flags to avoid accidental data loss. Annotations already cover idempotency and non-destructive intent, but the description enriches the safety model.
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 a single concise sentence that front-loads the primary action and packs the clear-flag warning into a compact clause. There is no fluff or redundancy. Given the tool's complexity, the extreme brevity is a slight drawback, but the structure is efficient.
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?
For a 19-parameter partial-update tool with zero parameter descriptions, one sentence is insufficient. The description does not explain how clear flags relate to the null-default fields, what constitutes an 'allowed task', or which fields are mutually exclusive. The output schema covers return values, so that gap is acceptable, but key invocation details are missing.
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?
With 0% schema description coverage, the description carries the full burden of explaining parameters, but it only mentions clear flags generically. It does not explain the meaning or valid values of the 19 parameters, nor the interaction between null-default fields and clear_* flags. Parameter names are self-evident, but the description adds minimal semantic value.
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 updates a task and specifies partial-update semantics ('only supplied fields'). It distinguishes this from specialized task tools like set_task_state or set_task_tags by describing a general field-update operation, though it does not explicitly name those siblings.
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 explicit guidance is given on when to use this tool versus alternatives such as set_task_state, set_task_tags, or move_task_to_stage. The only usage hint is the warning about clear flags preventing accidental erasure, which addresses how to update rather than when to choose this tool.
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 annotations present but only indicating readOnlyHint=false, destructiveHint=false, idempotentHint=false, the description adds some behavioral context by noting the task must be 'allowed'. However, it does not explain what happens for disallowed tasks, whether duplicates are prevented, or any side effects beyond creating a timesheet entry.
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 a single, efficient sentence with the action front-loaded. It avoids waste, though 'using the official Timesheets feature' is slightly redundant given the tool name.
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?
There is an output schema, so return values are covered, but the description leaves significant gaps: what defines an 'allowed task', how user_id and work_date interact, and the relationship to list_allowed_projects. It is not complete enough for an agent to confidently invoke without additional assumptions.
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 carries the burden for parameter meaning. It does add a constraint that the task must be 'allowed', giving some semantics to task_id, but it provides no information about hours format, description expectations, user_id, or work_date.
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 uses a specific verb ('Log time') and resource ('task'), and clearly identifies the operation as creating a timesheet via the official Timesheets feature. It distinguishes itself from sibling tools like update_timesheet, delete_timesheet, and list_timesheets by framing the action as logging time.
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 does not state when to use this tool versus alternatives, mention any exclusions, or reference sibling tools. It implies 'log time' as a creation operation, but offers no guidance on when to choose it over update_timesheet or list_timesheets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveness, and the description adds important context: the deletion is permanent, requires a hard-delete configuration, and corresponds to a specific command format ('DELETE TIMESHEET <id>'). This meaningfully extends the annotation-provided safety profile.
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 two short sentences with no filler. The main action is front-loaded, and the prerequisite and command format are compactly stated. Every word contributes to understanding.
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?
For a destructive tool with two required parameters, the description omits essential guidance on the confirmation parameter, which is likely critical for safe invocation. It also does not explain how to know whether hard-delete config is enabled or what happens if it is not. The output schema covers return values, so that gap is acceptable, but parameter guidance remains incomplete.
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 explain both required parameters. It implicitly maps line_id to the '<id>' in 'DELETE TIMESHEET <id>', but it never explains the confirmation parameter's purpose, expected value, or format, leaving a critical input undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('delete') and resource ('time', i.e., timesheet), and adds 'permanently' to disambiguate from soft operations. However, it does not explicitly distinguish this from sibling delete/archive tools and uses 'time' rather than 'timesheet', which is slightly informal.
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 gives a precondition ('Requires hard-delete config') but no guidance on when to use this tool versus alternatives like update_timesheet or archive_task. It also does not clarify when not to use it or what the confirmation parameter should contain.
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?
Annotations already mark this as non-read-only and non-idempotent, so the mutating create behavior is clear. The description adds the useful constraint that the tag is limited to one allowed project, though it does not disclose duplicate-handling or permission requirements.
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 a single sentence with no wasted words and puts the core action first. It is appropriately scoped, though it could have used the space to hint at parameter meanings without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, parameters appear in the schema, and an output schema exists, so the description does not need to explain return values. Still, it leaves some context to inference, such as how the tag relates to the allowed project and how creation differs from simply assigning an existing tag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter details beyond the implicit project scope. It does not explain that name is the tag label, project_id selects the project, or that color is optional with a default value, so the agent must work from the bare schema.
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 names a specific action and object: 'Create an Odoo tag scoped to one allowed project.' The verb 'Create' clearly distinguishes this from read/assign siblings like list_project_tags and set_task_tags, and the 'one allowed project' scope makes the tool's purpose specific.
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 create verb makes the trigger condition self-evident, and 'scoped to one allowed project' signals a project-related use case. However, it never explicitly names alternatives or states when not to use this tool versus set_task_tags or list_project_tags, leaving the routing mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: the search is always scoped to allowed projects and pagination is bounded. These are non-obvious guarantees an agent should know. It does not mention sort order or filtering exactness, but the additions are valuable and non-contradictory.
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?
A single sentence that front-loads the core action ('Search tasks') and then packs two high-value qualifiers (restricted to allowed projects, bounded pagination) with zero unnecessary words. The structure is exemplary for concise tool descriptions.
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?
For a 10-parameter search tool with no per-parameter descriptions, this one-sentence description is not enough. It omits details like query semantics, date format for deadline_before, pagination bounds, and how 'allowed projects' are determined. The output schema exists, but the input side is largely unexplained, making correct invocation uncertain.
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% for 10 parameters, so the description carries the burden of explaining them. It only hints at limit/offset through 'bounded pagination' and at project scoping through 'restricted to allowed projects'. No meaning is added for query, tag_id, stage_id, parent_task_id, deadline_before, assignee_user_id, or include_archived. This is insufficient given the large parameter surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Search tasks') and adds scope ('always restricted to allowed projects, with bounded pagination'). This clearly identifies it as a multi-task query tool distinct from singular siblings like get_task or create_task. However, it does not explicitly name a sibling alternative, so it misses the top score.
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 this is the general task search/list endpoint, but it does not state when to use it versus alternatives such as get_project_board or get_task. 'Always restricted to allowed projects' is a behavioral constraint, not a usage recommendation. No explicit when/when-not language is present.
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?
Annotations already indicate this is not read-only, and the description adds the useful 'policy-register' behavior and the environment-gating condition. It does not disclose more detailed side effects, failure behavior, or prerequisites, but it does not contradict the annotations.
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 entire description is one efficient sentence with no filler. It front-loads the core action and immediately includes the critical environment gate, making it easy to parse.
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?
For a creation tool with 8 parameters and no schema-level parameter descriptions, this one-sentence description is insufficient. While an output schema exists and return-value documentation is not needed, the agent still lacks guidance on parameter semantics, defaults meaning, and policy-registration implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the 8 parameters, including required 'name' or fields like privacy_visibility, allow_milestones, and date_start. The description does not compensate for the schema's lack of parameter documentation.
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 uses a specific verb ('Create and policy-register') with a clear resource ('a project'), and the conditional 'when ODOO_ALLOW_PROJECT_CREATION is enabled' adds precise scoping. This distinguishes it from siblings like update_project and create_task without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the enabling condition for using this tool (ODOO_ALLOW_PROJECT_CREATION being enabled), which gives clear operational context. It does not explicitly mention alternatives or when not to use it, but the 'create' wording strongly implies this is for new projects rather than updates.
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?
Annotations already cover readOnly, openWorld, idempotent, and destructive hints, so the description does not need to repeat those. It adds a useful prerequisite (milestones enabled, project allowed) but does not explain what happens if the condition fails or how existing milestones are handled.
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 entire description is one concise, front-loaded sentence with no filler. It states the action and the key precondition without redundant wording.
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?
Despite a simple tool shape and an output schema, the description omits essential invocation details such as deadline format, the meaning of the required fields, and failure behavior when milestones are disabled. An agent would need to infer too much from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter-level meaning. It does not explain that project_id identifies the target project, name is the milestone title, or deadline is an optional date. The schema only gives type and title, which is insufficient for confident invocation.
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 uses a specific verb and resource ('Create a milestone') and adds a meaningful scope condition ('when milestones are enabled on the allowed project'). It clearly distinguishes this creation tool from sibling tools like update_project_milestone and list_project_milestones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the correct usage context: use it only for allowed projects and only when milestones are enabled. It does not explicitly mention alternatives or when-not-to-use scenarios, but the condition gives clear contextual guidance.
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds useful context by specifying that the result is restricted to 'one allowed' project and includes 'planning settings'. It does not contradict annotations, but it stops short of explaining behavior for disallowed IDs or missing projects.
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, front-loaded sentence with no filler, redundancies, or repeated annotation information. Every word contributes to specifying the operation and its scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with an output schema and readOnly/openWorld annotations, the description is largely adequate. It clearly states what is read and what is included, though it could briefly mention that valid project IDs come from list_allowed_projects.
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%, and the description never explicitly explains that project_id identifies the allowed project. Although project_id is a simple, self-describing integer parameter, the description provides no additional meaning beyond the schema's 'Project Id' title.
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 uses a specific verb, 'Read', and identifies the exact resource, 'one allowed Odoo project', plus the included scope, 'planning settings'. This distinguishes it from siblings like list_allowed_projects (which lists multiple) and update_project (which mutates), and from get_project_workload (which targets workload rather than planning settings).
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 given about when to use this tool versus alternatives, such as list_allowed_projects for retrieving many projects or get_project_workload for workload-specific data. The description implies single-project retrieval but leaves the decision entirely to inference.
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?
Annotations already declare readOnlyHint=true, so the description's main contribution is specifying scope: global vs project-specific tags and the 'allowed project' restriction. This adds useful context but does not disclose other behavioral details such as permission handling or response characteristics. No contradiction with annotations.
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 focused sentence with no filler. It front-loads the verb and resource while efficiently adding the key scope distinction between global and project-specific tags.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only listing tool with an output schema and readOnlyHint annotation, the description is largely sufficient. The main missing element is explicit usage guidance versus related tag tools, but the core behavior is adequately conveyed.
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%, and the description does not explain what project_id means beyond loosely referencing an 'allowed project'. The single parameter's semantics are left mostly to the schema's name and type, which is a gap the description should have filled.
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 uses a specific verb ('List') and a clear resource ('global and project-specific task tags available to an allowed project'). It also differentiates itself from sibling tools like create_project_tag and set_task_tags, which are mutating 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?
The description provides no explicit guidance on when to use this tool versus alternatives. Sibling tools like list_task_states, create_project_tag, and set_task_tags suggest related but distinct purposes, yet the description does not mention any of them or state any 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?
The description adds the important behavioral nuance that only explicitly supplied fields are updated, which goes beyond the annotations. However, it does not explain the clear_* boolean behavior or the 'allowed project' constraint beyond a brief phrase. No contradiction with annotations 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 one short, front-loaded sentence with no filler or redundant phrasing. Every word contributes meaning.
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 12 parameters, no schema descriptions, and non-obvious clear_* flags, the description is far too thin to fully guide correct invocation. The output schema covers return values, but the description does not explain field interactions, required permissions, or the scope of 'allowed project.'
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 carries the burden of explaining parameters. It only says 'explicitly supplied planning fields,' which gives a general partial-update hint but does not clarify any specific field semantics, such as the difference between null values and clear_date_start/clear_date_end flags.
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 states a clear verb ('Update'), a specific resource ('project'), and specifies that it applies to 'planning fields' on 'an allowed project.' This is distinct from sibling tools like update_project_stage or update_task.
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 phrase 'planning fields' and 'allowed project' implies when this tool should be used, but the description gives no explicit guidance about when not to use it or which alternative tool to prefer. Usage context is implied rather than stated.
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?
Annotations already flag this as a non-read-only, non-destructive, idempotent operation, so the description's job is lighter. It adds an 'allowed-project' scope caveat not present in annotations. However, it fails to mention the clear_deadline behavior (how to remove a deadline), which is a meaningful behavior beyond the annotated traits.
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?
A single sentence with no filler, front-loaded with the verb and objective. It earns its place, though at the cost of omitting clear_deadline details.
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?
With an output schema present and annotations covering safety, the description doesn't need to explain return values. But the clear_deadline parameter's purpose is not described, and 'allowed-project' is left undefined. These are notable gaps for an update tool with five parameters.
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 names three of the five parameters (name, deadline, is_reached) but omits milestone_id and, more importantly, clear_deadline, whose semantics are not inferable from the schema alone. This leaves a required field and a functional flag unexplained.
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 uses the verb 'Update' with the resource 'milestone' and lists the specific mutable fields (name, deadline, reached flag). 'Allowed-project' helps distinguish from unconstrained milestone tools, and the update verb separates it from create/list siblings.
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?
No explicit guidance on when to use this tool versus create_project_milestone or list_project_milestones. The 'allowed-project' qualifier implies a scope constraint, but there is no statement of conditions or alternatives, leaving the agent to infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description need not restate safety. It adds useful behavioral context by noting that the tool resolves and checks the 'real Odoo project' before reading, which suggests project-context validation not evident from the schema or annotations.
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, concise sentence with the core action front-loaded. Every word contributes meaning, and there is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation with an output schema and read-only annotations, the description is nearly complete. The only slight gap is the cryptic phrase 'real Odoo project,' which could be expanded to clarify failure behavior, but overall the essential context is present.
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%, and the description does not explain the task_id parameter beyond the schema's name/type. While the single parameter is self-evident, the description fails to compensate for the absence of schema-level documentation, which the rubric requires at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and resource ('one task'), making the primary purpose clear. It is distinguishable from the sibling 'list_tasks' by the singular focus, though it does not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied by 'Read one task' — use when you need a single task by ID. However, there is no explicit guidance on when to prefer this over list_tasks or other task-related tools, and no exclusions or prerequisites are mentioned.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the constraint 'one allowed project', which hints at permission scoping, but does not disclose ordering, pagination, filtering, or error behavior. This is acceptable given the annotations but not rich.
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?
A single, direct sentence with no filler. It communicates the essential action and scope efficiently, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with an output schema and annotations, the description is adequate. However, it would benefit from explicitly referencing list_allowed_projects as the source of valid project_id values and clarifying what 'allowed' means in terms of access restrictions.
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 only implies that project_id is a project the agent is allowed to use, without explaining where valid IDs come from or how the 'allowed' constraint is enforced. This adds minimal meaning beyond the parameter name.
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 uses a specific verb ('List'), a clear resource ('milestones'), and a scope ('one allowed project'), which differentiates it from sibling create/update milestone tools. It is concise and immediately understood.
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 usage context is implied: it is the tool for listing milestones for a single project. However, there is no explicit guidance about when to prefer this tool over alternatives, nor any mention of prerequisites such as using list_allowed_projects to obtain valid project IDs.
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?
The readOnlyHint annotation already conveys that this is a safe read operation, and the description adds project-scoping context. It does not disclose details such as ordering, whether archived columns are included, or permission-related behavior, but no contradiction 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?
One tightly worded sentence that front-loads the verb and resource with no redundant phrasing. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only list with an output schema available, the core calling information is sufficiently specified. It does not explain the relationship to the similar sibling list_task_states, but the simple inputs and annotations make the description mostly complete.
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 single project_id parameter is self-explanatory by name and type, and the description adds project-scoping context. With 0% schema description coverage, some compensation is expected, but the parameter is simple enough that the lack of further detail is only a minor 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?
States a specific verb ('List') and resource ('Kanban columns (task stages)') scoped to a project, making the operation clear. It does not explicitly contrast with the sibling list_task_states, so differentiation is implicit rather than stated.
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 phrase 'available to an allowed project' implies a project-scoped use, but the description never states when to prefer this over list_task_states or other project tools. There are no explicit exclusions or alternative routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is not read-only, is idempotent, and is not destructive. The description adds valuable behavioral context by specifying that global or cross-policy stages are intentionally read-only, meaning attempts to update them should fail or be rejected. This goes beyond the annotations and helps the agent avoid invalid calls.
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, front-loaded sentence that conveys both the core operation and an important scope limitation. Every word earns its place, with no filler or redundancy.
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?
For a tool with 7 parameters and zero parameter descriptions in the schema, this description is too sparse to fully guide correct invocation. It establishes the project-scoped constraint but leaves critical semantics around update behavior and fields like clear_description and fold unaddressed. The presence of an output schema and annotations helps, but the parameter gap makes the overall definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its 7 parameters, yet the description does not explain any of them. The phrase 'project-scoped' hints at the role of project_id and stage_id, but fields like fold, sequence, name, description, and clear_description remain semantically unexplained. The description should compensate for the schema's lack of parameter documentation but does not.
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 and resource: 'Edit a project-scoped stage.' It also notes that global or cross-policy stages are intentionally read-only, which helps distinguish the tool's scope from other stage-related operations. However, it does not explicitly name sibling tools such as create_project_stage or list_project_stages, so it falls just short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-not-to-use signal: global or cross-policy stages are not editable, so this tool should only be used for project-scoped stages. It does not name alternative tools for global or cross-policy stage editing, but for the common project-stage update case the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a mutating but non-destructive, idempotent operation. The description adds valuable behavioral context by specifying that the entire tag set is replaced, not appended to, and that tags must be validated global/project tags.
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, front-loaded sentence with no filler. Every word contributes to understanding the tool's core behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with output schema and annotations available, the description covers the essential behavior: complete replacement and tag validation. It lacks usage-level context, but that is accounted for in the usage dimension.
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%, and the description does not explicitly explain task_id or tag_ids. It only indirectly hints that tag_ids refer to validated global/project tags, which is insufficient to fully 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Replace') and resource ('a task's complete tag set'), clearly indicating the action. It differentiates from sibling tag tools like create_project_tag and list_project_tags by emphasizing complete replacement rather than creation or listing.
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 explicit guidance is given for when to use this tool versus alternatives such as create_task_tag or list_project_tags. The description implies the use case through 'complete tag set', but it does not state exclusions or recommended conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent. The description adds useful behavioral context beyond the annotations by stating the subtask inherits the parent's project and that the parent must be verified/allowed, which informs preconditions and likely validation behavior.
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 entire description is one focused, front-loaded sentence. Every phrase earns its place, and the key constraint about allowed projects and verified parent tasks is stated directly without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For the core purpose, the description is adequate: it identifies the action, the parent relationship, and the project constraint. However, given nine parameters and no schema-level descriptions, important invocation details like date formats, priority semantics, and valid ID sources are left unspecified. The output schema reduces some burden, but there are 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%, and the description only clarifies parent_task_id's role implicitly. The nine parameters, including required `name` and various optional fields, receive no semantic explanation. Property titles like 'Name' and 'Deadline' provide some surface meaning, but the description does not compensate for the coverage gap.
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 states a specific action ('Create') and resource ('subtask'), and adds a valuable distinguishing constraint: it must be placed in the same allowed project as its verified parent task. This clearly separates it from sibling tools like create_task or create_project.
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 when to use the tool: when a subtask needs to be created under an existing, verified parent task. However, it does not explicitly say when not to use it or mention alternatives such as create_task for top-level tasks, leaving some routing to inference.
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?
Annotations already declare readOnlyHint=true, so the description needs only add behavioral context. It adds the access-scoping fact that only allowed projects/tasks are returned, but it does not disclose pagination, date-range behavior, or how the allowed restriction is enforced. This is adequate but not rich.
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?
A single, front-loaded sentence with no filler. Every word contributes the essential verb, resource, and restriction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and readOnlyHint covers return shape and safety, but with six parameters and 0% schema description coverage, the minimal description leaves date filtering and user filtering unexplained. It is minimally viable for a project-scoped list call but not 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 coverage is 0%, so the description carries the burden of explaining the six parameters. It only hints at project/task scoping and says nothing about limit, date_from, date_to, or user_id, leaving the agent without meaningful parameter semantics.
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 names a specific action ('List') and resource ('official Odoo Timesheets entries') and adds the key scope ('restricted to an allowed project/task'). This is enough to distinguish it from sibling mutation tools like create_timesheet, update_timesheet, and delete_timesheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'restricted to an allowed project/task' gives a clear use context and prerequisite, and the read-only purpose is evident. However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a non-readonly, idempotent, non-destructive operation. The description adds valuable context by clarifying that only supplied fields are updated and that the entry must be for a verified allowed project, which goes beyond the structured annotation data.
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 concise sentence with no filler. It front-loads the action and target, 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 5 parameters, 0% schema coverage, and the presence of sibling tools, the description is minimally viable but lacking. It does not provide enough parameter semantics or usage alternatives, though the annotations and output schema cover safety and return shape.
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%, and the description does not explain any of the parameters. 'Update supplied fields' is generic and does not clarify the role of line_id, the meaning of nullable fields, or whether null clears a value. The schema property names are self-explanatory, but the description adds little semantic value.
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 uses a specific verb ('Update') and a specific resource ('timesheet entry'), with 'supplied fields' indicating a partial update. This clearly differentiates it from sibling tools like create_timesheet, delete_timesheet, and list_timesheets.
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 the tool is for modifying an existing timesheet entry, but it does not explicitly state when to use it versus create_timesheet or delete_timesheet. No alternatives or exclusion conditions are mentioned, so usage guidance is implied rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint and openWorldHint, so the description adds meaningful behavioral context by specifying that it summarizes active tasks and groups by assignee with estimated-hour shares. It does not cover edge cases like unassigned tasks, but this is beyond the core behavioral disclosure.
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 concise sentence, front-loaded with the action verb and containing no redundant or filler content. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description sufficiently conveys the summary nature and the grouping by assignee. It would be stronger if it explicitly connected the summary to the provided project_id, but the tool name and parameter name compensate reasonably.
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% and the description does not mention the project_id parameter at all. The agent must infer from the parameter name and tool name that the summary is scoped to a specific project, which is not explicitly stated.
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 uses a specific verb 'Summarize' and names the resource 'active task counts and estimated-hour shares by assignee', which clearly conveys a distinct aggregation function. This naturally differentiates it from sibling tools like list_tasks or get_project_board, even without naming them.
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 phrase 'for planning' provides a general intended use context but no explicit guidance on when to choose this tool over alternatives, nor any exclusions. It implies usage without stating when-not-to-use or naming sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotency, and destructive hints. The description adds valuable behavioral context by saying the move happens only after validating task and stage projects and that the destination must be an allowed column. This goes beyond the safe, idempotent, non-destructive profile already declared.
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 sentence, front-loaded with the core action, and contains no filler words. Every phrase contributes meaning to the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists, so return values are covered by structured data. Yet the description leaves 'allowed' and the validation failure behavior underspecified, and it would benefit from pointing to sibling tools like list_project_stages for discovering valid stage IDs. These gaps are not fatal but make it less than fully complete.
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 coverage is 0%, so the description must compensate. It clarifies that task_id identifies the task being moved and stage_id is the target Kanban column, and it hints at project compatibility validation. However, it does not explain how to obtain valid allowed stage IDs or describe the exact validation rule, leaving part of the burden unmet.
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 uses a specific verb ('Move'), identifies the resource ('a task'), and defines the destination ('allowed Kanban column'). The validation phrase also distinguishes it from sibling tools like set_task_state or update_task by describing a dedicated stage-move operation.
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 the tool is for moving tasks between Kanban stages, but it never explicitly states when to use it over alternatives such as set_task_state, update_task, or list_project_stages. No exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description does not need to restate safety. It adds useful context beyond annotations: the operation is permanent, requires a special hard-delete configuration, and requires the confirmation phrase. This helps the agent understand the precise behavioral contract without contradicting the annotations.
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, focused sentence that places the core purpose first and adds prerequisites immediately. There is no filler or repeated schema information; every clause earns its place.
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?
The description covers the essential context for a two-parameter destructive call: what it does, when it is available, and what confirmation string is required. With an output schema present and annotations covering safety, little else is needed. It could be slightly more explicit about the task_id field's own semantics, but the overall context is adequate.
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 for both parameters. It specifies the confirmation format ('DELETE TASK <id>'), which gives meaning to the confirmation parameter, but task_id is only referenced implicitly as the <id> placeholder. It does not fully explain the relationship between task_id and confirmation beyond that example.
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 states a specific verb and resource: 'Permanently delete a task.' The word 'permanently' signals irreversible destructive action and clearly differentiates this from sibling tools like archive_task or move_task_to_stage. An agent can identify the tool's function immediately.
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 gives important prerequisites: hard-delete config and confirmation. However, it does not explicitly mention when to prefer this over sibling alternatives such as archive_task, and it does not state any exclusions or when-not-to-use conditions. The usage context is mostly implied by the word 'permanently.'
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?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is established. The description adds the allowlist-filtering behavior, which is useful context beyond the annotations, but it does not disclose additional behavioral details like pagination, ordering, or authentication requirements. Consistent with the annotation baseline, this adds some but not rich behavioral context.
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, front-loaded sentence with no wasted words. It communicates the action, resource, and key filtering constraint efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool with an output schema and annotations, the description covers the essential behavior. It could be slightly more complete by explicitly mentioning that non-allowlisted projects will be omitted, but the phrase 'only projects in the configured MCP allowlist' strongly implies this.
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 the input schema is empty, so the baseline is 4. The description adds semantic meaning by identifying the resource and the allowlist filter, which is sufficient since no parameter-level documentation is needed.
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 uses a specific verb ('List') and resource ('projects'), and adds a clear scoping qualifier ('only projects in the configured MCP allowlist'). This clearly distinguishes it from sibling tools like get_project, which retrieves a single project, or list_tasks, which lists tasks rather than projects.
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 word 'only' and the phrase 'configured MCP allowlist' imply this tool should be used when the agent needs the restricted set of allowlisted projects. However, it does not explicitly state when not to use it or name alternatives, such as a general project listing tool if one exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds useful behavioral scope: returned users are active, internal, and eligible for assignment. It does not describe query/limit behavior in depth, but it does not contradict the annotations.
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 sentence with no filler. The key action and scope are front-loaded, and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description establishes the core purpose and target user population, and the output schema plus read-only annotations reduce the need for return-value and safety details. However, with no parameter semantics given and no explanation of how query/limit affect results, the definition is only minimally complete for an agent planning to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the limit or query parameters. While the parameter names are reasonably self-explanatory, the tool description adds no meaning about how query filters results or how limit behaves, so an agent has to guess.
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 states a specific resource and purpose: resolving active internal Odoo users assignable to tasks/timesheets. It clearly identifies what the tool does and is easily distinguishable from the project/task/timesheet-focused sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when an agent needs users that this MCP can assign to tasks or timesheets, scoped to active internal users. It does not explicitly mention alternatives or exclusions, but no sibling tool directly competes with this user-listing function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing that the operation is performed as the configured service account and only on allowed tasks. This adds auth and authorization context that the annotations do not provide. It does not contradict the annotations, which simply mark the operation as non-read-only, non-idempotent, and non-destructive.
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?
A single, well-structured sentence contains the action, target, scope, and identity context with no redundant words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema and clear annotations, the description covers the essential behavioral context: what is posted, where, and under whose identity. It could add more detail about error cases or restrictions, but the low complexity makes the current description largely sufficient.
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, but it adds little detail about the parameters. 'body' is implicitly the comment text and 'task_id' the target task, but there is no added meaning about formats, constraints, or how the allowed-task restriction actually applies to task_id.
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 a specific action ('Post a comment') and a specific resource ('task's Odoo chatter'), which is distinct from every sibling tool. It also adds useful scope qualifiers ('allowed task', 'configured service account'). No ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to add comments to tasks that the service account is permitted to access. It does not explicitly contrast with alternatives, but no sibling tool performs comment posting, so the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond the readOnlyHint annotation by specifying exactly what is checked: authentication, capabilities, policy, and model permissions. It does not contradict the annotations and makes the read-only diagnostic nature clear.
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 concise sentence that front-loads the action and resource. Every word contributes meaning, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only connectivity check with an output schema, the description is fully sufficient. It names the relevant aspects checked and gives enough context for an agent to invoke it appropriately.
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?
This tool has zero parameters, so the description correctly does not need to explain parameter behavior. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter-related clutter.
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 verb 'Check' and the resource: Odoo 17 authentication, capabilities, policy, and model permissions. This distinguishes it from all sibling tools, which focus on project, task, and timesheet operations.
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 this tool is used to verify the Odoo connection and its configuration, but it does not explicitly state when to use it versus other diagnostic or setup tools. It provides a clear purpose but no direct usage guidance or alternatives.
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?
The readOnlyHint annotation already covers safety, so the description does not need to repeat that. It adds the useful conceptual distinction that task state is separate from Kanban stage, but does not disclose additional operational behaviors such as whether the list is sorted, paginated, or reflects real-time changes beyond the word 'live'.
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 entire description is one concise sentence that states the action, the resource, and the key distinguishing concept. It is front-loaded and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool with an output schema present, the description provides sufficient context. The clarification about Kanban stage separation is the main piece of domain knowledge needed to use the tool correctly.
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, so the description has no parameter semantics to convey. With an empty input schema, the baseline of 4 is appropriate; no additional parameter explanations are needed.
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 uses a specific verb ('List') and resource ('live Odoo 17 task state keys'), making the tool's purpose immediately clear. It also explicitly distinguishes task state from Kanban stage, which separates it from sibling tools like list_project_stages and set_task_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving task state keys rather than Kanban stages, providing a useful when-not context. It does not explicitly name an alternative tool, but the sibling list includes obvious related tools and the distinction is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the core safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds a genuinely useful behavioral trait — reversibility — that reinforces why this is safe to invoke. It does not contradict the annotations, though it could disclose more about side effects (e.g., whether archived tasks disappear from list_tasks).
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?
One tight 11-word sentence with two clauses: the action is front-loaded first, followed by positioning context. There is zero filler, and both clauses earn their place — the first states what it does, the second tells the agent why it exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (2 params, no nesting, output schema present, annotations covering the safety profile), the description is nearly complete. Minor gaps remain: no mention of how archiving interacts with task states, subtasks, or list visibility, and no behavior on nonexistent task_ids — but these are acceptable omissions given the tool's simplicity.
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?
With 0% schema description coverage, the description must compensate, and the 'Archive or unarchive' phrasing effectively documents the semantic effect of the `archived` boolean (true=archive, false=unarchive). task_id's meaning is self-evident from context. It does not explicitly map parameter names to behaviors, but the dual-verb construction carries the essential meaning.
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 opens with a precise verb-resource pair ('Archive or unarchive a task') that captures both modes of the tool via the boolean parameter. It also differentiates itself from the sibling delete_task by positioning archiving as the reversible alternative, so an agent can distinguish this from deletion without opening any schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'preferred reversible alternative to deletion' gives explicit routing guidance away from delete_task, which is the most confusable sibling. However, it does not address potential overlap with set_task_state or update_task, which could also plausibly manage a task's archival state in some systems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly=false, destructive=false, and idempotent=true, so the description does not need to restate those. It adds useful behavioral context by explaining that the state value must be a key returned by list_task_states, which is critical for correct invocation.
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?
A single sentence that front-loads the action and resource while including the necessary key-source instruction. There is no filler or redundant restatement of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters, an output schema, and safety annotations, the description provides the needed prerequisite (state keys from list_task_states) for correct invocation. Nothing critical is missing for an agent to select and call this tool appropriately.
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 carry parameter meaning. It clarifies that 'state' is a key returned by list_task_states, which is essential; 'task_id' is left to its self-explanatory title. This is strong compensation for the main ambiguous parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('set') on a specific resource ('a task's Odoo state') and names the source of valid values ('list_task_states'). This makes it clearly distinguishable from sibling tools like list_task_states, update_task, and move_task_to_stage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the prerequisite workflow: obtain a key from list_task_states before calling this tool. It does not explicitly discuss when to prefer alternatives, but the 'Odoo state' qualifier and key-source hint provide sufficient contextual guidance.
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:

[![Odoo17-Project_management-MCP MCP server](https://glama.ai/mcp/servers/fatemeh-mohseni-AI/Odoo17-Project_management-MCP/badges/card.svg)](https://glama.ai/mcp/servers/fatemeh-mohseni-AI/Odoo17-Project_management-MCP)

Score Badge

Copy to your README.md:

[![Odoo17-Project_management-MCP MCP server](https://glama.ai/mcp/servers/fatemeh-mohseni-AI/Odoo17-Project_management-MCP/badges/score.svg)](https://glama.ai/mcp/servers/fatemeh-mohseni-AI/Odoo17-Project_management-MCP)

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/fatemeh-mohseni-AI/Odoo17-Project_management-MCP'

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