PlanfixMCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are grouped by resource (contact, task, project, comment) with clear prefixes, making most purposes distinct. However, the two datatag tools for new vs existing comments and the generic comment tools could cause some confusion.
Naming Consistency3/5
Naming is mixed: some tools follow verb-first (update_contact, create_task) while others are noun-first (contact_list, task_by_id). While still readable, the inconsistency makes it harder to predict tool names.
Tool Count2/5
With 37 tools, the set is quite large, exceeding the 25-tool threshold. Many tools cover niche features like datatags and templates, which adds cognitive load and makes the set feel over-scoped.
Completeness3/5
The toolset covers create, read, and update for contacts, tasks, and projects, but lacks delete operations for these core resources. Comments and datatags are well handled, but the missing deletes are a notable gap.
Average 2.3/5 across 37 of 37 tools scored. Lowest: 1.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no information about side effects, return values, or required permissions. The description is essentially a label with zero 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single noun phrase does not earn its place as a useful description; it provides no actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a schema and output schema, the tool's overall purpose and usage are not adequately explained. The description is too minimal to be considered complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contributes no parameter information, but the input schema thoroughly documents all three parameters, including a detailed enumeration of possible system fields for the 'fields' parameter. Since schema coverage is 100%, the description need not add anything, though it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Контакт по номеру' merely restates the tool name in Russian, lacking any verb indicating an action such as retrieving or fetching. It does not differentiate from sibling tools like contact_list or update_contact, leaving the tool's function ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like contact_list or create_contact. It fails to state that this tool is for retrieving a single contact by its identifier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is read-only, what it returns, error behavior, or any side effects. The single noun phrase gives no behavioral context whatsoever.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It has no sentence structure and fails to convey the tool's purpose. The brevity does not earn its place because it contributes no useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete because it does not explain what the tool actually does. For a simple retrieval-by-ID tool, a minimal but clear statement like 'Gets a project by its ID' is expected. The current description is insufficient for an agent to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions for id, fields, and sourceId. The description adds nothing beyond the schema, but the schema itself adequately documents parameters, warranting a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'Проект по номеру' ('Project by number'), which is essentially a restatement of the tool name 'project_by_id'. It lacks a verb or action, so it does not specify what the tool does (e.g., get, retrieve, fetch). It also fails to distinguish from sibling tools like project_list 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Sibling tools also lack differentiation, leaving the agent to guess based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses no behavioral traits—nothing about read-only nature, response format, pagination, or error conditions. The description is a label, not an explanation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specification rather than effective conciseness. It has no structure or front-loaded core action, just a noun phrase that adds no value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description fails to indicate what the output contains or how it behaves. A tool with one optional param and no behavioral explanation is incomplete for an AI agent deciding to invoke it.
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 describes the 'fields' parameter with full coverage (100%), so the schema provides meaning. The tool description adds no param information, but the baseline of 3 applies due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Группы проектов' ('Project groups'), a noun phrase that merely restates the tool name. It lacks a verb and does not specify what the tool does (e.g., list, retrieve, manage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools like project_list and project_by_id exist, but no distinctions or usage context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It fails to state that this is a read-only listing operation, whether pagination is supported, or any side effects. The phrase 'Project templates' gives zero behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two words, which is under-specification rather than conciseness. It lacks a verb and essential context, making it unhelpful. A one-sentence description like 'List project templates' would be both concise and valuable; this is not.
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?
Although the input schema and output schema provide parameter and return-value detail, the description itself is extremely incomplete. It does not state the tool's core purpose (listing templates) or any behavior. The rich schema cannot compensate for a description that fails to explain what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all four parameters have descriptions in the schema. Per the rubric, this yields a baseline of 3 even though the tool description itself adds no parameter context. The description does not reference or clarify any parameter, but the schema already handles this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Шаблоны проектов' ('Project templates') is a noun phrase that restates the resource without indicating any action. It does not say 'list' or 'get', making it essentially a tautology of the tool name project_template_list. There is no differentiation from sibling tools like task_template_list or contact_template_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No mention of use cases, prerequisites, or exclusions. Sibling tools exist for other template types, but there is no contrasting information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It does not mention whether the operation is read-only, whether pagination is involved, or any side effects. This leaves the agent without critical safety or behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, but this is under-specification rather than concise efficiency. It is a single noun phrase that fails to convey any operational detail, so the brevity does not serve a useful purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's six parameters and numerous sibling tools, the description is inadequate. Even with an output schema present, the lack of purpose, usage guidance, and behavioral transparency makes the tool selection and invocation ambiguous and error-prone.
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 67%, leaving typeList and resultOrder without descriptions. The tool description adds no parameter explanations and does not compensate for the gaps. It repeats nothing that the schema already provides, and offers no additional semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Комментарии к задаче' ('Task comments') is a noun phrase that simply restates the tool name without stating what action it performs. It lacks a verb (e.g., list, get, create) and does not clarify whether the tool retrieves, creates, or updates comments, making it essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus sibling tools such as add_task_comment, comment_list, or task_by_id, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It incorrectly mentions a 'comment' which implies a different behavior than what the schema suggests (adding a data tag to a contact). It does not disclose side effects, permissions, or whether the operation creates or updates a comment. The description is actively misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it is inaccurate and omits the core term 'data tag'. It fails to earn its place because it provides misleading information rather than clarifying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of data tags and the existence of a comment-specific sibling tool, the description is severely incomplete. It does not explain what a data tag is, how it applies to a contact, or how it differs from adding to a comment. The output schema exists, but the description's misinformation undermines overall understanding.
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 input schema has 100% description coverage, with clear descriptions for id, items, and dataTag. The description adds no additional parameter semantics and even introduces confusion with the word 'comment'. Since the schema is comprehensive, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Add value of an additional field to a new contact comment', but the tool name and schema indicate it adds a data tag to a contact, not to a comment. This is misleading and does not clearly distinguish from the sibling tool add_contact_datatag_to_comment. The verb is present, but the resource is ambiguous and potentially incorrect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 the sibling add_contact_datatag_to_comment. There is no mention of alternatives, prerequisites, or typical scenarios. This lack of usage context makes it hard for an agent to choose the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It merely states 'list of comments' with no mention of read-only behavior, pagination limits, return structure, or how filters behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. A single phrase that restates the tool name wastes its opportunity to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — 7 parameters, complex filter objects, pagination, typeList enums, and an output schema — a one-phrase description is grossly incomplete. It leaves agents without essential context for correct invocation.
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 description adds no parameter meaning. Schema coverage is 57% — some parameters like typeList and resultOrder lack full descriptions, and the tool description does not clarify them or their intended usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Список комментариев' is a direct translation of the tool name 'comment_list', providing no additional specificity. It does not distinguish this list tool from sibling comment tools like contact_comments, task_comments, or comment_by_id.
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 usage guidance is provided. The description does not explain when to use this tool versus alternatives, nor does it mention filtering, pagination, or result ordering options that are evident from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses nothing about behavior such as whether the tool returns a list, supports pagination, or has any side effects. The description carries the full burden but is only a label, so the agent has no idea what to expect from invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. A single noun phrase that restates the title does not earn its place; it fails to convey the operation or usage. Effective concision would still include a verb and key context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, a required id, and an output schema, this description is grossly incomplete. It does not state the core action, the return type, or the relationship to the contact, making it impossible for an agent to correctly use the tool without external knowledge.
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 description adds no meaning about parameters. Although the schema covers 67% of parameters with descriptions, the description itself does not clarify how the 'id' parameter relates to the contact context or how fields/typeList work in this specific tool, so it offers zero value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Комментарии к контакту' is a noun phrase that restates the tool name in Russian, essentially providing no action verb. It identifies the resource (contact comments) but does not specify whether this tool lists, creates, or updates comments, nor does it distinguish from sibling tools like task_comments or comment_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description gives no context about prerequisites, typical scenarios, or exclusions, leaving the agent without clues for tool selection among the many comment-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits such as pagination, filtering, or return payload. The description gives none of this context, offering only a generic resource label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but under-specification is not conciseness. The single phrase adds little value beyond the tool name and does not earn its place, as it fails to communicate the operation or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, output schema, multiple sibling template tools), the description is critically incomplete. The agent cannot determine what this tool returns, when to use it, or how it differs from contact_list or task_template_list.
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?
All five parameters have rich descriptions in the input schema (100% coverage), so the schema already explains field meanings, defaults, and constraints. The description adds no additional parameter semantics, but the high schema coverage meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase ('Шаблоны контактов и компаний') that merely restates the resource implied by the tool name 'contact_template_list'. It does not specify the action (list/get) and fails to distinguish this tool from sibling tools like contact_list or contact_group_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of the intended use case, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as required permissions, side effects, return values, or whether the operation is reversible. The description carries the full burden and completely fails to address it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. The single phrase merely repeats the tool name and does not contribute meaningful content; it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 23 parameters and an output schema, the description is essentially empty. It lacks any high-level context about the creation process, required fields (even though none are formally required), or expected outcomes. This is severely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter information beyond what the schema already provides, but it doesn't need to because the schema is thorough. However, it also doesn't highlight any important parameters or usage patterns, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Создать проект' is essentially a translation of the tool name 'create_project', providing no additional specificity or differentiation from sibling tools like update_project or project_by_id. It states the obvious action but does not clarify scope or unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool versus alternatives such as create_task or update_project. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on, and the description does not disclose any behavioral traits such as read-only nature, return format, potential errors, or side effects. It is a bare label that provides no transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concise. It is a single vague phrase that does not earn its place because it fails to communicate the tool's function adequately, similar to a tautological label.
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?
Although an output schema exists, the description remains incomplete for tool selection. It does not clarify which type of comment (contact, task, project, or general) this tool handles, leaving ambiguity given the many sibling comment tools. The sparse description is insufficient for an AI agent to correctly choose this tool.
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 input schema has 100% description coverage, with each parameter (id, fields, sourceId) explained. The description itself adds no parameter semantics, but the schema already carries the burden, justifying the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Комментарий по номеру' (Comment by number) merely restates the tool name 'comment_by_id' with no explicit verb or scope. It does not clarify what action is performed (e.g., retrieve, get) or distinguish this from sibling comment tools like comment_list or contact_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. Among many sibling tools for comments, this omission is critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'list' without any details about read-only nature, pagination, sorting, or what exactly the filters are or how they are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified. It is a noun phrase rather than a structured sentence, offering no additional value beyond the tool name. This is more under-specification than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too minimal to understand the tool's function or context. It does not explain what contact filters are, what they are used for, or how they relate to other contact tools, making it inadequate even for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it does not attempt to do so, which is appropriate in this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Список фильтров контактов' translates to 'List of contact filters', which is essentially a direct restatement of the tool name. It lacks a clear verb and resource structure and does not differentiate from sibling tools like 'contact_list' or 'contact_by_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions no context, prerequisites, or exclusions, and does not reference any sibling tools or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Create task' with no mention of permissions, side effects, required fields, or the fact that it creates a persistent record. This is a mutation tool with zero behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but this is under-specification rather than conciseness. A useful description for a tool with 36 parameters and no annotations would need at least a sentence or two explaining core behavior. The brevity here fails to convey essential information, so it is not an appropriate size.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complex schema (36 parameters, nested objects, enums) and the absence of annotations, the description provides no context about creation semantics, required fields, potential side effects, or how to determine success. The presence of an output schema does not excuse the lack of high-level context for this create operation. This is completely inadequate for the tool's complexity.
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 schema covers 100% of the 36 parameters with descriptions, so the baseline is 3. The tool description itself adds no parameter-level meaning, but the schema already provides thorough documentation for each field, including examples and enums. Thus the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Создать задачу" simply restates the tool name 'create_task' in Russian, offering no additional specificity about what a task is in this context or how this operation differs from related tools like update_task or task_list. This is a tautology, not a purpose clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools (e.g., update_task, task_list, create_project). There is no mention of prerequisites, typical use cases, or situations where this tool is preferred over alternatives. The absence of any usage direction results in a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure, but only states the bare fact of listing projects. It does not mention pagination, default sorting, filter behavior, side effects, or any operational traits, making the tool's behavior nearly opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, constituting under-specification rather than effective conciseness. A single noun phrase does not provide adequate structure or information for an agent to select and invoke the tool appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complex filter structure and five parameters, the description provides no orienting context. Although an output schema exists, the description still needs to convey the tool's overall purpose and capabilities, which it entirely fails to do.
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 high (~80%), and the schema itself provides detailed parameter descriptions, including examples. The description adds no parameter semantics, but the baseline 3 applies because the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Список проектов' (List of projects) directly restates the tool name 'project_list' without adding specificity about scope, filtering, or pagination. It reads as a noun phrase rather than a clear verb+resource action, failing to distinguish from sibling tools like project_by_id.
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 such as project_by_id or project_template_list. The description gives no context for use cases, exclusions, or preferred scenarios, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it simply says 'Contact groups' without indicating read-only operation, return format, pagination, or any side effects. It adds no behavioral information beyond the terse label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than effective conciseness. It fails to convey any actionable information, making the phrase low-value despite its brevity.
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?
Although the output schema exists and the tool is simple, the description is too sparse to be considered complete. It lacks any indication of returned data, typical usage, or relationship to siblings, leaving the agent without sufficient context to select or invoke the tool correctly.
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 schema description coverage is 100% (the single 'fields' parameter has a description), so the baseline is 3. The description adds nothing about parameters, but the schema already documents what fields are accepted and possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Группы контактов' ('Contact groups') is a noun phrase that essentially restates the tool name without specifying the action (listing). It does not clearly state that the tool returns a list of contact groups, nor does it differentiate from sibling tools like contact_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context about typical use cases, relationship to contact_list, or scenarios where group listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states 'Task by number' without indicating whether the operation is read-only, what it returns, or any side effects. The existence of an output schema partially covers return values, but no behavioral traits are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase. While brief, it is under-specified rather than effectively concise; it lacks substantive content needed to understand the tool. It does not earn its place because it adds minimal value over 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?
With no annotations and a vague one-phrase description, the tool is inadequately contextualized. The agent cannot determine the tool's scope, how the 'fields' parameter affects the response, or when to choose this over task_list. The output schema exists but does not compensate for the missing usage context.
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 input schema provides descriptions for all three parameters, including a detailed list of available field names for the 'fields' parameter. Since schema description coverage is 100%, the baseline is 3, and the tool description adds no additional meaning about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Задача по номеру' (Task by number) is a noun phrase that does not explicitly state an action like 'retrieve' or 'get'. It indicates the resource (task) and key (number/id) but lacks a verb, making the purpose only inferable from the tool name. It does not clearly differentiate from sibling tools such as task_list, though 'by number' hints at retrieving a single task.
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?
There is no guidance on when to use this tool versus alternatives like task_list or create_task. The description does not mention appropriate contexts, exclusions, or alternative tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, and the description merely states the update action without disclosing behavioral traits such as whether existing values are overwritten, permission requirements, or any side effects. It adds no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it under-specifies by repeating the tool name. It lacks informative content that would justify its brevity, so it is not effectively concise.
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 11 parameters and no output schema or annotations, the description only covers the basic action. It does not explain the update behavior, required identifiers, or notification implications, leaving the agent with significant inferential gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all 11 parameters (100% coverage), so the baseline is 3. The description itself does not add any parameter semantics, but the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Обновить комментарий к задаче' is a direct translation of the tool name, providing no additional information. It is a tautology that restates the name, so it fails to differentiate from siblings beyond the resource naming.
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 no indication of when to use this tool versus alternatives like add_task_comment or delete_comment. No context, exclusions, or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden, but 'Importar lista de contactos' reveals nothing about duplicate handling, templates, side effects, or whether it updates existing records. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is severely under-specified for a tool with 8 parameters and a complex nested schema. Conciseness is achieved at the expense of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool (8 parameters, nested objects, many options) with no output schema and no annotations. The description provides no details on return values, duplicate import behavior, template usage, or other critical context needed to select and invoke it 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?
The description contains zero parameter information. With only 63% schema description coverage, the tool description should compensate for ambiguous parameters like optionImportDuplicate and optionImportUniqueField, but it 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 action ('import') and resource ('contacts'), so the basic purpose is evident. However, it does not distinguish from sibling tools like create_contact or update_contact, missing the 'list' aspect as a potential differentiator.
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?
There is no guidance on when to use this tool versus create_contact/update_contact, no exclusions, and no mention of batch vs. single insert. The description does not help the AI decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It provides none: no mention of side effects (e.g., whether it appends data tags or replaces existing ones), required permissions, error behavior, or what the response contains. For a mutation tool, this is a serious gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no unnecessary words. It is front-loaded with the action and resource. However, it is so brief that it sacrifices clarity and completeness, which slightly lowers the score from 5.
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?
The tool has a complex input schema with nested objects, but the description only gives a high-level one-liner. It does not explain the concept of 'data tag entries', how 'items' relates to the comment, or what the output schema contains. Despite an output schema existing, the description is too thin to give an agent sufficient context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all four parameters (100% coverage): 'id' as task number, 'commentId' as comment number, 'dataTag' as data tag reference, and 'items' as data tag entries. The description adds no additional parameter semantics, so the baseline of 3 applies because the schema already handles parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('add value of additional field') and resource ('existing task comment'), but it does not explicitly mention the core entity 'data tag' (datatag) that appears in the tool name. This makes the purpose somewhat vague and it could be confused with updating a comment's custom fields. It does distinguish from siblings like 'add_task_comment' by mentioning 'additional field', but not strongly.
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. The description does not mention related tools such as 'add_task_datatag' (for tasks) or 'add_contact_datatag_to_comment'. Without context, an agent cannot decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It only states a list of contacts and companies, omitting details like default value of isCompany, pagination, filtering capabilities, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse—a single noun phrase—which borders on under-specification rather than effective conciseness. It omits essential operational details and doesn't earn its place as a helpful guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, output schema, no annotations), the description is far too minimal. It fails to add context about how to construct requests, interpret results, or handle filters, leaving the agent to rely entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 89% schema description coverage, parameters are well-documented in the schema (e.g., fields, offset, filters, pageSize, isCompany). The description itself adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Список контактов и компаний' identifies the resource as a list of contacts and companies but lacks an explicit verb like 'list' or 'retrieve'. It distinguishes from siblings like contact_by_id and create_contact, but is vague about scope or action.
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 on when to use this tool versus alternatives like contact_by_id. There is no mention of prerequisites, typical use cases, or when filtering/pagination is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral information beyond what the schema already includes. With no annotations, the description carries the full burden but discloses nothing about pagination, default behavior, or output characteristics, making it wholly uninformative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and easy to read, but it is more of a title than a description. It is not bloated, but it is also under-specified, lacking the structure of a useful tool description.
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 simple list tool, the description only names the resource. It does not explain what a task template is, what the list contains, or any practical context. The presence of an output schema covers return values, but the description is still inadequate for an agent to understand the tool's full purpose.
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?
All four parameters have rich descriptions in the schema (100% coverage), so the description adds no additional meaning. The schema fully documents fields, offset, pageSize, and sourceId, so the bare description does not need to compensate.
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 'Список шаблонов задач' (List of task templates) clearly identifies the resource and action (list), and distinguishes it from sibling tools like project_template_list and contact_template_list. However, it lacks an explicit verb and is phrased as a title rather than a full sentence.
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. There is no mention of filtering, typical use cases, or context that would help an agent decide between this and other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'update project by number' with no details on side effects, silent mode behavior, or whether fields are appended or replaced. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is under-specification rather than conciseness. It does not front-load key usage details nor explain what happens on update, making it less helpful than a slightly longer but informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 24 parameters, no annotations, and an output schema, the description 'Обновить проект по номеру' is completely inadequate. It gives no indication of update semantics, optionality, or expected behavior, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description. The tool description adds no parameter-specific value, but the schema comprehensively documents each field, so baseline 3 is appropriate.
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 'Обновить проект по номеру' translates to 'Update project by number', clearly stating the verb and resource. It distinguishes from siblings by resource type, but lacks explicit scope or additional differentiator beyond the tool name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_project or update_task. No context about prerequisites, permissions, or whether it supports partial updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It merely says 'update' without explaining whether the update is partial or full, what happens to unspecified fields, whether it is idempotent, or any side effects. This is a significant gap for a mutation tool with 40 parameters.
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, front-loaded with the core purpose. It is not verbose and earns its place, though it is extremely brief given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 40 parameters, an output schema, and no annotations, yet the description is only one short phrase. It fails to provide essential context about update semantics, field mutability, or behavioral expectations, making it completely inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents all parameters. The description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
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 'Обновить задачу по номеру' (Update task by number) clearly states the action (update) and resource (task), with the 'by number' qualifier indicating identification via task number. It is unambiguous and sufficiently specific, though it does not explicitly differentiate from sibling tools like create_task or task_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_task or explicit conditions for updating. There are no exclusions, prerequisites, or context about preferred usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention side effects, such as notifications, permissions, or whether the comment is created or appended, nor any return behavior. The description essentially repeats the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it merely restates the tool name without adding any useful structure or information. It is under-specified rather than helpfully concise, especially given the tool's complexity.
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?
Although the schema and output schema are rich, the description is incomplete for an 11-parameter tool. It lacks any context about when to use the tool, its relationship to sibling comment tools, or behavioral expectations. The agent must rely entirely on the schema, which does not explain the tool's role.
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 input schema provides detailed descriptions for all 11 parameters (100% coverage), so the schema already documents parameter meaning. The description itself adds no parameter-related context, but this is acceptable given the schema's completeness.
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 translates to 'Add a comment to a contact', providing a specific verb and resource. It distinguishes from sibling tools like update_contact_comment and add_task_comment by explicitly targeting contacts and the action of adding.
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 no explicit guidance on when to use this tool vs alternatives such as update_contact_comment or delete_comment. There is no mention of exclusions, prerequisites, or preferred use cases, leaving the agent to infer usage solely from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing whether the deletion is permanent, reversible, or what side effects might occur. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—essentially a translation of the tool name. While it is concise, it adds no substantive information beyond the name, making it under-specified rather than appropriately concise.
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?
The tool has one required parameter and no output schema. The description does not explain return values, success/failure behavior, or the types of comments it applies to. It is minimal and leaves the agent without enough context for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'id' parameter as 'Number of comment' with 100% coverage. The tool description adds no additional meaning about the parameter beyond what the schema provides. Baseline of 3 is appropriate.
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 'Удалить комментарий' which means 'Delete comment'. This is a clear verb+resource action. However, it does not specify the type of comment (e.g., contact comment vs task comment) or provide any distinguishing details beyond the tool name.
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. The description does not mention exclusions, prerequisites, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It only implies a read-only list operation without describing pagination, filtering, sorting, or return format. This is insufficient for an agent to anticipate tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it is under-specified to the point of being merely a label. There is no structure or additional helpful information, so it fails to earn its place as a useful description.
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 having an output schema and well-documented parameters, the description provides no context about the tool's purpose in a workflow, differences from sibling tools, or expected behavior. The tool appears to be one of many list operations, and the description does not complete the picture.
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 input schema provides full descriptions for all 4 parameters, so baseline is 3. The description adds no additional parameter context, but the schema already documents fields, offset, pageSize, and sourceId effectively.
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 indicates a list operation targeting recurring tasks. It specifies a distinct resource (recurring tasks) that differentiates it from the sibling 'task_list', though it does not explicitly name an alternative.
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?
There is no guidance on when to use this tool versus alternatives like 'task_list' or 'contact_list'. The description provides no context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It only states the operation ('update') without disclosing side effects, permissions, partial-update semantics, or any other behavioral traits beyond the verb itself.
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, short sentence that immediately conveys the core action and identifier. It has no fluff or redundant information, earning its place.
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 34 parameters, an output schema, and sibling tools, the one-line description is insufficient. It omits that the endpoint also updates companies, that only provided fields are changed, and any other high-level context a user would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 34 parameters. The description's 'by number' adds no new meaning beyond the id__path parameter's existing description, thus it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Обновить контакт по номеру' clearly states the action ('update') and resource ('contact'), and adds the scope 'by number' to indicate the identification method. It distinguishes the tool from create_contact and contact_by_id, though it does not explicitly mention sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The description is a single phrase without any contextual advice about the update workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states a list by filter without disclosing pagination, sorting, or that it returns a filtered list. It does not add behavioral context beyond the literal meaning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise but may be under-specified. It communicates the core purpose but lacks a complete sentence structure, making it less informative than ideal.
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 rich input schema with complex filters and pagination, the description is minimal. With no annotations and an output schema present, the tool still requires more contextual guidance on its behavior, such as pagination and filter usage, so completeness is low.
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 86%, so the schema already documents parameters like fields, offset, filters, etc. The description adds no parameter-specific meaning, and the baseline for high coverage is 3.
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 'Список задач по фильтру' translates to 'List of tasks by filter', which clearly identifies the tool as a task-listing endpoint supporting filters. It stands out from siblings like task_by_id or create_task, though it lacks an explicit verb like 'get' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like task_by_id, create_task, or contact_list. There is no mention of use cases, exclusions, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update' and does not elaborate on side effects, notification behavior, silent mode implications, or what happens to existing comment data. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, making it concise. However, it is under-specified for an 11-parameter tool, lacking structure and additional context that would make the conciseness valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, no annotations), the description is incomplete. It does not mention return values, side effects, or business context, leaving the agent without enough information to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics, but the schema already documents each parameter's purpose and format, so the description does not need to compensate.
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 'Обновить комментарий к контакту' (Update contact comment) clearly states a specific action on a specific resource, and the name itself distinguishes it from add/delete comment tools. However, it lacks details on what fields can be updated, so it's not fully comprehensive.
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 offers no guidance on when to use this tool versus alternatives like add_contact_comment or update_task_comment. No mention of prerequisites, such as needing an existing contact ID and comment ID, or when updating is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose that this is a write operation, any permission requirements, or what the response contains. The presence of an output schema is not leveraged to explain return behavior. Minimal behavioral information is given.
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 with no wasted words. It is efficient but extremely sparse, lacking context that could be added without much verbosity. It earns a 4 for being concise, not for richness.
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, no annotations, and a complex domain (comments, recipients, files, hidden/pinned flags), a one-sentence description is insufficient. It omits context about prerequisites (e.g., existing task), side effects (e.g., notifications), and return values, making it incomplete for effective tool selection.
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 schema description coverage is 100%, so all 12 parameters already have descriptions in the structured schema. The tool description adds no additional parameter semantics, warranting the baseline score of 3.
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 cleanly states the action: 'Add a comment to a task' (in Russian). It clearly identifies the verb (add) and resource (task comment), distinguishing it from contact comment tools. However, it does not explicitly differentiate from update_task_comment or other comment operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that the task must already exist, that this is for creating new comments, or that update_task_comment serves for edits. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only indicates 'add', but does not explain whether a new comment is created, whether existing data is overwritten, what permissions are required, or any resulting side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no redundant wording. It is front-loaded with the action verb and target, making it efficient. Although it lacks detail, conciseness is about avoiding waste, which it achieves.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested arrays) and an output schema, the one-sentence description is incomplete. It fails to explain the data tag concept, the relationship between customFieldData and dataTag, or whether a new comment is created. The agent would have to rely entirely on schema hints and sibling tool names to infer usage.
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 schema descriptions already cover 100% of the parameters, including id as the task number, items as data tag entries, and dataTag as the tag reference. The description adds little beyond a vague reference to 'additional field value', so it does not compensate beyond the baseline schema coverage.
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 action and resource: adding an additional field value to a new task comment. This clearly differentiates from sibling tools like add_task_datatag_to_comment, which target existing comments. However, it uses the vague term 'additional field' rather than 'data tag' or 'items', leaving some ambiguity about the exact data structure involved.
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 usage guidance is provided. The description does not mention when to choose this tool over alternatives such as add_task_comment or add_task_datatag_to_comment, nor does it describe prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral details. It only says 'files attached to the contact' without mentioning pagination, filtering, ordering, or access requirements. For a read-only list operation, this is a minimal disclosure.
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 phrase in Russian that gets straight to the point. No unnecessary words or repetition. However, it is quite brief, which limits the information conveyed.
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?
There is an output schema and both parameters are documented in the schema, so the description need not describe return values or param formats. However, it still lacks usage context and behavioral details that would help an agent decide when to invoke it. The description is minimally sufficient for a simple list tool but not 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?
The input schema already provides 100% coverage for both parameters (id and onlyFromDescription), including descriptions and an example for id. The tool description adds no additional parameter semantics, so it does not compensate or extend beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Files attached to the contact' clearly identifies the resource (files) and scope (contact), distinguishing it from similar list tools for tasks and projects. However, it lacks an explicit verb (e.g., 'list' or 'get'), relying on the tool name for action.
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 instead of sibling tools like task_file_list or project_file_list. The description only states what the tool returns without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It merely says 'Create contact or company' and does not mention permissions, validation rules, side effects, or response behavior. For a mutating operation, this is minimal transparency.
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, short sentence with no filler or unnecessary words, making it easy to parse. It is not as rich as it could be, but from a conciseness perspective it is efficient and front-loaded with the action and resource.
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 rich input schema and presence of an output schema fill in many operational details, so the terse description is acceptable for a simple create operation. However, with 32 optional parameters and no annotations, the description still lacks high-level guidance on when to choose this tool over bulk import or how to structure a typical request, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all 32 parameters (100% coverage), so the description does not need to repeat field meanings. However, the description adds no additional semantic value beyond what the schema already offers; it only implies the contact/company distinction, which is explicitly covered by the isCompany parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Создать' / create) and the resource ('контакт или компанию' / contact or company). It is specific enough to indicate the tool's purpose, but it does not explicitly differentiate it from sibling tools like import_contacts or update_contact, so it falls 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as import_contacts for bulk creation or update_contact for modifying existing records. The description only names the action and provides no context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states what the resource is. It does not mention that this is a read operation, pagination behavior, auth requirements, or any side effects. The description is purely nominal and provides no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short phrase) and front-loaded, containing zero fluff. However, it is so sparse that it borders on under-specification, yet as a standalone sentence it is efficient and directly states the core purpose.
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?
The description is too minimal for a tool with pagination parameters and a list output. It does not explain that it returns a paginated list, nor does it describe the output shape or any edge cases. The presence of an output schema mitigates the need to detail return values, but the description still lacks essential context for an agent to know when and how to invoke it effectively.
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 input schema has 100% coverage with descriptions for all parameters (id, offset, pageSize). The description adds no parameter-specific meaning, but the schema already documents them, so the baseline of 3 is appropriate.
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 'Files attached to the project' clearly identifies the resource and scope (project files). While it lacks an explicit verb like 'list', the tool name 'project_file_list' implies a list operation, and it differentiates from sibling tools like task_file_list and contact_file_list by specifying 'project'.
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 on when to use this tool vs alternatives. It does not mention conditions, prerequisites, or alternative tools. The description is a bare noun phrase, providing no contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not state whether the operation is read-only, how the onlyFromDescription flag affects behavior, or any other runtime characteristics, leaving the agent to infer safety and side effects from the name alone.
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 short phrase with zero waste, front-loading the core purpose. It slightly sacrifices clarity by not being a complete sentence, but remains efficiently sized for the tool's simplicity.
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 tool with a complete schema and output schema present, the description gives the essential purpose but omits any behavioral context or usage nuance. It is minimally viable but lacks guidance on optional parameters or typical use cases.
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 100% with both parameters described in the input schema. The description itself adds no parameter-specific meaning, so the baseline of 3 applies, as the schema does the heavy lifting.
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 indicates the tool returns files attached to a task, combining a specific resource (task files) with an implied list operation. It distinguishes from sibling tools like contact_file_list and project_file_list by naming 'task', though it lacks an explicit verb like 'list' or 'get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as task_by_id or task_list, nor any exclusions. It simply states the tool's function without contextualizing it among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and a minimal description, there is no disclosure of behavior such as read-only nature, authentication needs, or response format. The description only states the resource, so the agent gains no insight into side effects or access 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 short phrase with no redundancy or fluff. It is appropriately brief for a simple list tool, but it is under-specified rather than richly concise, lacking a full sentence or explanatory structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema, and a straightforward list function, the description provides enough to understand the resource at a basic level. However, it misses practical context such as how filters are scoped, whether they are shared across projects, or how to interpret the output, making it minimally complete.
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 schema defines no properties, so the description correctly omits parameter details. The baseline for a 0-parameter tool is 4, and no additional semantic information is needed.
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 'Список фильтров задач' ('List of task filters') clearly identifies the resource (task filters) and the intent (list). It distinguishes from sibling tools like task_list (which lists tasks) and contact_filters (which filters contacts), though it lacks an explicit verb and does not elaborate on the filter types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or refer to sibling tools such as contact_filters or task_list, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, idempotency, permission requirements, or error conditions. It only states the action, leaving the agent without knowledge of consequences beyond the schema.
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 core action. There is no unnecessary phrasing or repetition. It is appropriately minimal in length, though it sacrifices content for brevity.
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 that this is a mutation tool with no annotations and an output schema that is not described, the description fails to provide adequate context. It lacks information about when to use it, how it fits into the workflow, or what the consequences are. The minimal description is insufficient for an agent to select and invoke the tool correctly without additional context.
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 input schema provides full descriptions for all four parameters (id, items, dataTag, commentId), covering 100% of the parameter documentation. The description adds no additional meaning beyond what the schema already states, so it meets the baseline for high schema coverage.
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 action: adding a value of an additional field to an existing contact comment. It uses a specific verb and resource, and distinguishes it from sibling tools like 'add_contact_datatag' (which adds to the contact itself) and 'add_contact_comment' (which creates a new comment).
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 on when to use this tool over alternatives, nor any mention of exclusions or prerequisites. The description simply states the action without contextualizing it relative to similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![PlanfixMCP MCP server](https://glama.ai/mcp/servers/alexd73/PlanfixMCP/badges/card.svg)](https://glama.ai/mcp/servers/alexd73/PlanfixMCP)

Score Badge

Copy to your README.md:

[![PlanfixMCP MCP server](https://glama.ai/mcp/servers/alexd73/PlanfixMCP/badges/score.svg)](https://glama.ai/mcp/servers/alexd73/PlanfixMCP)

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/alexd73/PlanfixMCP'

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