vikunja-mcp

Server Quality Checklist

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

Latest release: v0.5.1
Disambiguation1/5
The tool set contains extensive overlap: curated tools like vikunja_get_project and vikunja_delete_task duplicate raw proxies such as vk_get_projects_25ac8903752b and vk_delete_tasks_88ea47d49817. Many raw proxies have generic names with random hex suffixes (e.g., vk_get_projects_*), and placeholders like vk_get_kind_* make it impossible to distinguish purposes. Agents will struggle to select the correct tool among dozens of near-identical options.
Naming Consistency1/5
Naming follows no uniform pattern: there is a mix of vikunja_* (verb_noun) and vk_* (http_verb_entity_randomhash) prefixes, with some tools using different verbs (get/delete/put/post) and inconsistent object ordering. The random hash suffixes on raw proxies make names unpredictable and hard to memorize. The overall style is chaotic and lacks any consistent convention.
Tool Count1/5
With 180 tools, this server is drastically over-scoped for an MCP integration. Even if the raw proxies are auto-generated, exposing every endpoint as a separate tool creates overwhelming selection burden and token bloat. A well-designed MCP server would typically expose 10-20 curated tools, not hundreds of raw HTTP proxies.
Completeness4/5
The sheer number of raw proxies means nearly every Vikunja API endpoint is represented, covering projects, tasks, labels, comments, attachments, teams, users, webhooks, subscriptions, and migrations. However, the curated subset lacks some high-level CRUD operations (e.g., update/delete labels or comments) which forces agents to use the obscure raw proxies. The domain is broadly covered but not cohesively organized.
Average 3.8/5 across 180 of 180 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action of creating a comment, with no information about required permissions, side effects, reversibility, return value, or whether the comment is immediately visible. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant information. It is clear and front-loaded, earning full marks for conciseness.
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 lack of annotations and output schema, the description is too sparse. It doesn't explain the relationship to task existence, authentication requirements, or the context of comments (e.g., who authored, privacy). The tool name and schema fill some gaps, but the description itself does not provide sufficient 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 both parameters (comment and task_id) described in the schema. The description adds no extra meaning beyond the schema, so the baseline score 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 clearly states the tool's action: 'Create a comment on a task.' It uses a specific verb ('create') and resource ('comment on a task'). It distinguishes from siblings like list_task_comments by explicitly indicating a create operation, though it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as vikunja_list_task_comments or vikunja_update_task. It doesn't mention prerequisites (e.g., task must exist) or any exclusions. No usage context is 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 fully carries the burden of behavioral disclosure. It only says 'Update an existing Vikunja project' and fails to mention whether the update is partial, what side effects occur, required permissions, or the response format. This provides no transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it concise and front-loaded. However, it is so minimal that it lacks helpful details, which keeps it from receiving a higher score.
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 has 9 parameters, no output schema, and no annotations, the one-sentence description is inadequate. It does not explain the update semantics (e.g., partial vs full replacement), the meaning of the required project_id, or what happens on success/failure. More context is needed for an agent to use it 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?
The schema covers 100% of parameter descriptions, so the baseline is 3. The description adds no additional meaning to parameters beyond what the schema already documents, but it also does not need to compensate for missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (update) and resource (an existing Vikunja project), which is easy to understand. However, it does not differentiate this tool from the many sibling vk_put_projects_* tools that also appear to update projects.
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 about when to use this tool versus alternatives such as vikunja_create_project, vikunja_delete_project, or the numerous vk_put_projects_* siblings. The need to update a project is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions authentication, parameter aliases, and top-level field handling, but does not disclose response format, side effects, or idempotency. The statement that body is 'optional' contradicts the schema's required field, undermining transparency.
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 short but repeats 'Updates a project' and ends with an unresolved 'see below'. It could be tightened, but it is still reasonably front-loaded with the key action.
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 no output schema, the description should explain return values and errors. It covers authentication and parameter passing but omits response behavior and fails to resolve the optional/required body contradiction, leaving the tool under-specified for reliable 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?
Schema coverage is 100% with descriptions for both id and body, so the baseline is 3. However, the description explicitly calls the body field 'optional' while the schema marks it required, creating confusion. It adds useful notes about aliases and top-level fields, but the contradiction hurts the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates a project' and specifies the raw REST proxy endpoint POST /projects/{id}. It distinguishes from adding a task, though it does not differentiate among the many sibling project update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context ('Raw Vikunja REST proxy', authentication required, payload placement) but lacks explicit when-to-use vs alternatives. The phrase 'see below' is dangling and provides no additional guidance.
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 fully disclose behavior. It discloses authentication and parameter aliases, but does not state side effects (e.g., whether the task is removed from its previous bucket), error conditions, or return behavior. The description also contradicts the schema by calling the required body field 'optional', creating confusion about the request format.
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 brief and mostly front-loaded with the purpose followed by proxy details. It avoids unnecessary filler, but repeats 'Update a task bucket' and 'Updates a task in a bucket', and the 'optional body field' phrasing is misleading. Still, it is appropriately sized for a simple proxy tool.
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 low-complexity tool with no output schema, the description covers authentication and parameter passing, but misses important context such as the actual operation effect (moving a task into a bucket) and the fact that body is required. The internal contradiction about the optional body reduces completeness, but the endpoint path and schema fill some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description's instruction to 'Pass the JSON request payload in the optional body field' conflicts with the schema's description of body as just the task ID. The aliases note is helpful but generic. Overall, the description does not add value and slightly obscures the parameter meaning.
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 the action ('Update a task bucket') and resource ('task in a bucket'), and gives the exact REST path, making the purpose clear. However, the phrasing 'Update a task bucket' is slightly ambiguous because the tool actually moves a task into a bucket, not updates the bucket itself. The endpoint path differentiates it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 versus alternatives is provided. The description does not mention that it is for moving tasks between buckets, nor does it contrast with other task update tools. It only says authentication is required, which is a prerequisite, not a usage scenario.
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 carries the full burden. It discloses aliases and authentication but misstates the body field as 'optional' while the schema marks it required, a clear contradiction. It also fails to mention side effects, update semantics, or return values, leaving key behavioral traits undisclosed.
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 moderately concise, but 'Updates a team' appears twice, and the phrase 'Path and query parameters are top-level fields' is vague. The extra sentences add value but suffering from redundancy prevents a higher score.
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 2-parameter tool with no output schema or annotations, the description covers auth and parameter passing, but omits expected response format, partial update behavior, and field constraints. The optional-body contradiction further undermines completeness, leaving users with ambiguity.
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 already described ('Team ID Required', 'The team with updated values'). The description adds useful alias and top-level parameter info, but the erroneous 'optional body field' muddles semantics. It neither fully compensates nor detracts beyond 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 tool updates a team via a raw proxy for POST /teams/{id}, which is a specific verb+resource. However, it repeats 'Updates a team' twice and does not explicitly contrast with sibling tools like vk_put_teams_*, so it is clear but not fully distinguishing.
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 invocation details (body field, top-level parameters, aliases, auth) but offers no guidance on when to use this tool versus alternatives. Given many sibling team tools (e.g., PUT, DELETE, GET), it lacks exclusions or alternative references, leaving usage context implicit.
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 must disclose behavior itself. It mentions authentication requirement and parameter alias handling, but contradicts the schema by calling the body 'optional' when the schema lists it as required. It also does not disclose return behavior or side effects of creation.
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 relatively compact but redundant: 'Create a label' and 'Creates a new label' duplicate the same idea. It could be tightened without losing content, though it is not overly verbose.
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 create tool with one parameter and no output schema or annotations, the description covers basic usage but omits expected response details and fails to resolve the body optionality conflict. It also leaves the relationship to similar tools ambiguous, making it incomplete for an agent deciding between alternatives.
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 helpful parameter context ('JSON request payload', 'camelCase and snake_case aliases'), but it incorrectly labels the body as optional and mentions 'path and query parameters' that are not present in the schema (which has additionalProperties false). This causes confusion about the actual accepted parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a label' with a specific verb and resource, and identifies as a raw proxy for PUT /labels. It distinguishes from sibling vikunja_create_label by emphasizing its low-level REST proxy nature, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for direct REST access to the Vikunja API but provides no explicit when-to-use vs alternatives. It offers procedural details like passing the JSON payload in the body field and top-level parameter handling, but these are not usage selection guidelines.
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 create action and resource, without disclosing required fields, return behavior, permission requirements, or side effects. For a mutating tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It conveys the core operation in the most concise form possible while remaining clear.
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 8 parameters, no annotations, and no output schema, a one-sentence description is not enough context for confident invocation. The schema covers parameters, but the description omits expected response, behavioral caveats, and any additional contextual details beyond the basic action.
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 documented (e.g., 'Project title.', 'Hex color like #4F46E5.'). The description adds no parameter-specific meaning, but the schema fully compensates, so the 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 'Create a new Vikunja project' uses a specific verb and resource, clearly identifying the operation. It distinguishes from sibling mutation tools like update/delete/list projects and create task/label. However, it does not add extra detail about scope or special behavior.
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 such as vikunja_update_project, vikunja_delete_project, or the numerous vk_post_projects variants. The verb implies creation, but no prerequisites, context, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does mention authentication is required and lists what gets migrated, but it does not disclose that this is a mutating operation (creates projects/tasks), potential side effects like duplicates, or the response format. The optional-body contradiction further muddies the expected behavior.
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 moderately concise but contains redundancy: 'Migrate all projects, tasks etc.' is repeated as 'Migrates all tasklists, tasks, notes and reminders.' It also includes a typo ('tasklinsts'). While it starts with a clear purpose, the extra sentences do not all add value.
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 migration tool with no output schema and no annotations, the description should explain more about the results, error cases, and side effects. It only says authentication is required and lists what is migrated. The optional/required body contradiction and lack of response details make the tool incomplete for an agent to use confidently.
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 some meaning by referring to the body as a 'JSON request payload' and mentioning parameter naming aliases, but it fails to specify the payload structure. It also introduces a confusing statement about top-level path/query parameters that conflicts with the schema's additionalProperties: false. The schema's body description (auth token) appears misplaced, creating additional ambiguity.
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 tool's purpose: 'Migrate all projects, tasks etc. from Microsoft Todo.' It also names the exact endpoint (POST /migration/microsoft-todo/migrate) and lists the migrated items (tasklists, tasks, notes, reminders), which distinguishes it from other migration tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for Microsoft Todo migration) but provides no explicit exclusions or alternatives. More importantly, it gives contradictory guidance: the description says the body is optional ('optional body field') while the schema marks body as required. This could mislead an agent into omitting a required parameter.
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 fully disclose behavior. It states authentication is required and migration scope, but it directly contradicts the schema: the description says the body is an optional JSON request payload, while the schema marks body as required and describes it as the auth token. This inconsistency is misleading. It also mentions path/query parameters that do not appear in the schema, adding confusion.
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 relatively short but repeats the migration scope twice ('Migrate all projects, tasks etc.' and 'Migrates all projects, tasks, notes, reminders, subtasks and files'). It is front-loaded but has redundancy and no clear structure separating purpose, usage, and parameter instructions.
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 migration tool with no output schema, the description should explain what happens on success, error behavior, or return values. It does not. The internal contradictions about the body parameter further reduce completeness, making it insufficient for an agent to invoke 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 schema describes the body parameter as 'The auth token previously obtained from the auth url', while the tool description says to pass the JSON request payload in the body. This contradiction leaves the agent unsure what to provide. The extra notes about aliases and top-level fields conflict with additionalProperties=false and only one body property. Despite 100% schema coverage, the semantics are actively misleading.
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 tool migrates all projects, tasks, notes, reminders, subtasks, and files from Trello to Vikunja, with a specific verb and resource. It also names the raw REST endpoint (POST /migration/trello/migrate), distinguishing it from sibling migration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this tool is for Trello migrations, and mentions authentication is required. However, it does not explicitly exclude alternatives or mention when not to use it, though the context is clear enough for an agent.
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 contradicts the input schema by calling the body field 'optional' while the schema marks it as required. It also mentions 'path and query parameters' and 'original parameter names' that do not exist in the schema (additionalProperties is false). These misleading statements fail to disclose behavior transparently, especially in the absence of any annotations.
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 fairly short, but it redundantly repeats 'Creates a new team' twice. The additional proxy-specific notes are relevant but could be condensed, and the structure is not ideally front-loaded with unique information. It earns a mid score for being brief but not optimally 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?
For a simple tool with no output schema and no annotations, the description should explain return value/response and any caveats. It fails to mention what is returned or error behavior, and it introduces a schema contradiction. The description is not complete enough to guide an AI agent without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100% (body has a description), the tool description adds some context like 'JSON request payload' and alias support. However, the misleading 'optional body field' undermines the accuracy of the parameter semantics. The extra information is partially incorrect, so the description does not cleanly add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a new team.' It also specifies the raw Vikunja REST endpoint 'PUT /teams', which distinguishes it from sibling tools that handle other HTTP methods or resources. The verb and resource are explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage instructions such as passing the JSON payload in the body field, handling path/query parameters as top-level fields, and supporting camelCase/snake_case aliases. However, it does not explicitly state when to use this tool versus alternatives (e.g., other team creation tools), leaving the usage context only implied by calling it a 'raw proxy.'
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 side effects and requirements. It does mention authentication and the enabling action, but it incorrectly states the body is optional when the schema requires it, misleading agents about call requirements. This is a significant transparency issue.
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 purpose is repeated almost verbatim in the first and third sentences ('Enable a previously enrolled totp setting' twice), there is a typo ('..'), and the generic proxy instructions add noise. It is not a well-structured or concise 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 one-parameter tool, the description should clearly state that the body is required and explain the expected input format. It fails by contradicting the schema and omits any response or error behavior. The authentication note is useful but insufficient overall.
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 schema has one required parameter 'body' (described as 'The totp passcode'). The description contradicts this by calling the body 'optional' and adds irrelevant boilerplate about top-level parameters and name aliases. This actively misleads the agent about required inputs.
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: enabling a previously enrolled TOTP setting using a passcode, and specifies the exact REST endpoint (POST /user/settings/totp/enable). This is a specific verb+resource that distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful context: the TOTP must be previously enrolled, implying this is a follow-up step. It also notes that authentication is required. While it doesn't explicitly mention alternatives, the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since there are no annotations, the description carries the full burden. It discloses that authentication is required, mentions parameter aliases (camelCase/snake_case), and indicates it's a 'Raw Vikunja REST proxy', which implies direct passthrough behavior. However, it does not describe return values, error handling, or side effects, so transparency is partial.
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 repetitive—'Creates a new saved filter' appears twice—and is poorly punctuated ('filter Pass the JSON'). There is no front-loading of critical information; the key action is stated but immediately repeated. The structure feels rushed and would benefit from tighter editing.
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 no output schema, so the description should explain what is returned, but it does not. It also omits details about error conditions, whether the operation is idempotent, or what the response body looks like. While it mentions authentication and parameter passing, the lack of return-value information makes it incomplete for an agent to safely confirm success.
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 only contains 'body' with a generic description. The description adds significant meaning by explaining that the body can hold the JSON payload, and that path and query parameters are top-level fields (though not enumerated). It also introduces camelCase/snake_case aliases, which is not in the schema. This compensates well for the schema's minimalism.
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 'Creates a new saved filter' and identifies the underlying REST endpoint 'PUT /filters'. This gives a specific verb and resource. However, the phrase is repeated twice, and there is no explicit differentiation from the sibling tool vk_post_filters_52aa420f91fd, which likely also creates filters, causing slight ambiguity.
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 some usage hints, such as 'Pass the JSON request payload in the optional body field' and 'Authentication is required', but it does not mention when to use this tool versus alternatives like vk_post_filters or vk_put_projects. No explicit exclusions or recommended contexts are given.
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 carries full responsibility for disclosing behavioral traits. It only states 'Create a new label' and does not mention side effects, required permissions, idempotency, or what happens on success/failure. For a mutating operation, this is insufficient.
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, front-loaded sentence with no wasted words. It is concise and to the point, though it could benefit from a brief expansion on usage or output details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain what the tool returns or any relevant post-conditions. It does not. Given the tool's simplicity (three parameters) and low complexity, the description is minimally viable but lacks the completeness needed for an agent to fully anticipate the tool's behavior.
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 input schema already describes all three parameters (title, hex_color, description) clearly. The description adds no additional semantic value beyond what the schema provides, but since the schema is complete, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new label' uses a specific verb and resource, clearly indicating the action of creating a label. It distinguishes itself from sibling tools like vikunja_list_labels and vikunja_delete_task without ambiguity.
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 vikunja_add_label_to_task or vikunja_list_labels. The description lacks context about prerequisites, use cases, or situations where a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds value by noting authentication is required, the user needs read access, the endpoint usually doesn't require a request body, and parameters have aliasing. However, it does not disclose return format, error behavior, or pagination, which are important for a GET-all-comments operation.
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 short but redundant, repeating 'Get all task comments' twice. There are also grammar issues ('need to have'). It's not poorly structured, but the duplication wastes space and the sentences could be tightened.
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 no output schema, the description should explain what the tool returns, but it does not. It also lacks info on failure modes, pagination, or the fact that taskID is required (despite schema saying optional). For a task comments list endpoint, this is incomplete. The presence of sibling 'vikunja_list_task_comments' suggests a friendlier alternative, but this tool's description does not position it clearly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context: parameters are top-level fields, original names accept camelCase and snake_case aliases, which clarifies the duplicate schema properties. However, it does not clarify that taskID is effectively required despite the schema marking no required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all task comments' and identifies itself as a raw Vikunja REST proxy for GET /tasks/{taskID}/comments. It is specific about verb and resource, but does not explicitly distinguish itself from sibling tool 'vikunja_list_task_comments' which likely serves the same purpose in a more user-friendly way.
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 vs alternatives. It mentions 'Raw proxy' and gives parameter conventions, but fails to state conditions like 'use this if you need raw API access' or compare to sibling tools. The read access requirement and authentication are mentioned but not as selection criteria.
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 must disclose behavioral traits. It mentions 'Authentication is required' and that parameters accept aliases, which is useful. However, it incorrectly calls the body field 'optional' while the schema marks it as required, and it does not disclose side effects, return values, error behavior, or idempotency. 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 somewhat repetitive ('Create a task' and 'Inserts a task into a project' say nearly the same thing) and could be tightened. The information about aliases and authentication earns its place, but the redundant phrasing and the incorrect 'optional body' statement reduce clarity.
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 lack of annotations and output schema, the description should make the tool fully self-explanatory. It covers purpose, authentication, and parameter conventions, but it omits the response format, possible validation rules, and the distinction between this raw proxy and the high-level create-task sibling. The body-required inconsistency further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions, so baseline is 3. The description adds value by explaining that parameters are top-level and that original names accept camelCase/snake_case aliases. However, it explicitly says the body is 'optional' when the schema requires it, which is misleading and undermines the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a task' and specifies the exact endpoint 'PUT /projects/{id}/tasks', which unambiguously identifies the operation and resource. It also distinguishes itself as a 'Raw Vikunja REST proxy', differentiating it from higher-level sibling tools like vikunja_create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by calling it a 'Raw Vikunja REST proxy' and clarifies how to structure the request (body field, top-level path/query parameters, aliases). However, it gives no explicit guidance on when to choose this tool over siblings such as vikunja_create_task or vk_post_tasks, and it does not state exclusions or alternative scenarios.
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?
The description implies a mutation ('attach') but with no annotations, it fails to disclose idempotency, duplicate attachment behavior, error conditions, or permission requirements. The agent receives no safety or side-effect information beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It front-loads the verb and is immediately understandable.
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 attach operation with two parameters, the description is minimal. It lacks usage guidelines, behavioral traits (e.g., idempotency, failure modes), and return-value expectations. This is especially critical since no output schema is provided.
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 task_id and label_id, covering 100% of parameters. The description adds the 'existing label' context, which clarifies that the label must already exist, but it does not explain ID formats or relationships beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Attach an existing label to a task' uses a specific verb ('attach') and clearly identifies the resource (label) and target (task). It distinguishes itself from sibling tools like vikunja_remove_label_from_task or vikunja_create_label.
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 creating a new label or removing a label. The description only states the action without any contextual prerequisites, exclusions, or mention of related operations.
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 available, the description carries the full burden of disclosing behavioral traits. It only states 'Delete a task by ID' without revealing that deletion is typically irreversible, may cascade to related data, or requires specific permissions. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is front-loaded with the action and resource, making it easy to parse and remember.
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 the tool's simplicity (one parameter, no output schema), the description omits crucial context such as irreversibility, potential side effects, or what a successful deletion returns. Since no annotations or output schema exist to fill these gaps, the description is incomplete for a destructive action.
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 100% coverage for the single parameter 'task_id' with description 'Task ID.' The description's 'by ID' is redundant, adding no new meaning. Baseline of 3 is appropriate since schema fully documents the parameter and the description offers no additional semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('task') with the scope 'by ID', making the tool's purpose immediately clear. It distinguishes itself from sibling tools like vikunja_get_task or vikunja_update_task, though it does not explicitly point out the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are prerequisites or consequences (e.g., task must exist, deletion is permanent) mentioned. The description states only the action itself, leaving the agent without context for appropriate usage.
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 carry the full burden of behavioral disclosure. It only restates the basic function without mentioning the optional expand parameter, response format, error behavior, or access requirements. This leaves significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get a single task by ID.' Every word contributes to the core meaning, and there is no fluff or redundancy. It is exactly as concise as its simple purpose requires.
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 an optional expand parameter with four documented enum values (subtasks, buckets, reactions, comments), but the description omits this entirely. With no output schema or annotations, the agent is left without critical context about how to use expand and what the response will contain, making the description incomplete for effective invocation.
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 descriptions for both task_id and expand. The description reinforces that task_id identifies the target task, but adds little meaning beyond the schema. The expand parameter's semantics remain generic ('Expand task details'), so the description does not compensate or enhance beyond baseline.
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 'Get a single task by ID' clearly identifies the specific verb (get), resource (task), and distinguishing feature (by ID). It unambiguously differentiates from sibling list, create, update, and delete task operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as vikunja_list_tasks or vikunja_update_task. There is no mention of prerequisites, ideal use cases, or when a different tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully states that 'Authentication is required' and that the endpoint 'does not usually require a request body', and mentions parameter naming conventions. However, it does not disclose the destructive impact (e.g., whether related tasks are deleted), return format, or error behavior, which are relevant for a delete operation.
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 short and front-loaded, but it contains redundant statements: 'Deletes a project' appears twice (once with a typo 'Delets a project') and the phrase 'Raw Vikunja REST proxy' is repeated in a sense. This waste and inconsistency reduce clarity and professionalism, though the content is otherwise compact.
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, single-parameter delete tool, the description covers the core action, endpoint, request body expectation, authentication requirement, and parameter conventions. However, it does not explain the return value or error scenarios, and it does not clarify how this tool relates to the many similar sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear 'Project ID Required.' description for the only parameter. The description adds value beyond the schema by explaining that 'Path and query parameters are top-level fields' and that 'original parameter names also accept camelCase and snake_case aliases', which helps with correct parameter invocation.
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 'Deletes a project' and gives the specific endpoint 'DELETE /projects/{id}', which identifies the action and resource. However, it does not distinguish this tool from the numerous sibling tools that also delete projects (e.g., vikunja_delete_project, vk_delete_projects_*), so it misses the differentiation aspect of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the many alternatives. It mentions it is a 'Raw Vikunja REST proxy' but does not explain when a raw proxy should be preferred over the higher-level vikunja_delete_project or other vk_delete_projects variants. No exclusions, prerequisites, or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully notes that no request body is usually required, that path/query parameters are top-level, and that camelCase/snake_case aliases are accepted. However, it does not explicitly state the operation is read-only or describe pagination/error behavior.
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 front-loaded with a clear purpose but contains redundancy: 'Get all labels on a task' and 'Returns all labels which are assicociated with a given task' say the same thing. The multiple short sentences could be consolidated without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET proxy with no output schema and no annotations, the description covers the endpoint, auth, and parameter passing conventions. It omits explicit read-only/safety status and detailed pagination behavior, but the schema documents pagination parameters. Overall it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases. This helps agents understand how to pass parameters beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all labels for a task and identifies the exact REST endpoint (GET /tasks/{task}/labels). It distinguishes itself as a raw proxy, though it does not explicitly contrast with sibling tools like vikunja_list_task_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this raw proxy versus standard alternatives such as vikunja_list_task_labels. It provides implementation details (authentication, parameter aliases) but no contextual guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It does disclose authentication requirements and alias handling, but it incorrectly labels the body as 'optional' when the schema marks it required, which is misleading. It also omits details about response behavior or side effects (e.g., whether an export email is triggered).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded in the first sentence. It includes some generic proxy mechanics but stays within a short paragraph. Minor typo (double period) does not significantly hurt structure.
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 output schema and no annotations, the description should explain expected outcomes. It does not mention what happens after the request is made, the response format, or any asynchronous/email delivery aspects. Completeness is notably lacking for a side-effect-triggering operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds confusion rather than clarity. It calls the body 'optional' and says it is a 'JSON request payload', while the schema describes it as a required password string. This contradiction undermines the semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request a user data export' and identifies the exact endpoint 'POST /user/export/request', distinguishing it from other vk_post_user_* sibling tools. The verb 'Request' and resource 'user data export' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user data export needs to be requested, and it mentions authentication is required. However, it does not explicitly compare to alternative tools or state when not to use it. The 'Raw Vikunja REST proxy' characterization gives some context but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the action (subscribes), the authentication requirement, and the parameter style (top-level fields, aliases). However, it does not mention side effects, idempotency, response format, or permissions beyond authentication. The effect is stated, but key behavioral aspects are missing.
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 not overly long, but it contains a duplicate sentence ('Subscribes the current user to an entity') and a typo ('entity..'). The key information is front-loaded, but the redundancy and awkward formatting reduce efficiency.
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 mutation tool with no annotations and no output schema, the description is incomplete. It does not explain the response, error conditions, idempotency, or permission requirements beyond authentication. The required parameter ambiguity is unresolved, and the description does not offer enough context for an agent to safely invoke the tool in all scenarios.
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 covers all parameters, so the baseline is 3. The description adds the alias conventions (camelCase and snake_case) and clarifies the optional body usage, which goes beyond the schema. However, the schema has an inconsistency: the required array is empty but property descriptions mark entity/entityID as required, and the description does not resolve this. Redundant phrasing about the body adds little.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool subscribes the current user to an entity, and provides the underlying REST endpoint (PUT /subscriptions/{entity}/{entityID}). This distinguishes it from the sibling delete-subscription tool in meaning, though it does not explicitly name alternatives. The repetition of the same sentence slightly detracts from clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied through the verb 'Subscribes' and the REST path. It mentions authentication is required and describes parameter handling, but does not explicitly say when to use this tool versus other subscription-related tools, nor provide exclusions or alternative tool names. The guidance is clear enough but implicit.
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 carries full behavioral burden. It discloses authentication requirements and camelCase/snake_case aliases, but it inaccurately describes the body field as 'optional' when the schema marks it required, which is a significant misleading statement. For a mutating PUT operation, side effects or authorization details are not mentioned.
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 front-loads the purpose and includes several useful pieces of information, but it repeats 'Add a user to a team' verbatim, wasting a sentence. Overall structure is acceptable but not tight.
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 tool with two parameters and no output schema, this description is not fully complete. The body field's required shape is unclear, and the 'optional body' misstatement could lead an agent to omit a required payload. Authentication and aliases are covered, but the contradiction undermines execution confidence.
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% (both id and body have descriptions), so the baseline is 3. The description adds useful context about top-level path/query fields and parameter aliases, but the 'optional body' statement conflicts with the schema's required list and the body's exact structure remains vague.
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 verb and resource: 'Add a user to a team' and identifies the exact REST endpoint 'PUT /teams/{id}/members'. This distinguishes it from sibling team-related tools (e.g., vk_get_teams, vk_post_teams) by specifying the exact operation and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage whenever a user needs to be added to a team via the raw Vikunja REST proxy, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The raw proxy context hints at a low-level use case, but no explicit guidance is given.
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?
Without annotations, the description carries full burden, but it contradicts the input schema by calling the body field 'optional' while schema marks it as required. It also fails to disclose what the response looks like or any side effects, making this misleading for an agent.
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 fairly concise and front-loaded with the purpose. However, it repeats 'Create a new api token' twice, which is redundant. Still, it is short and organized well enough.
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 output schema, the description should explain return values and success behavior, but it doesn't. It mentions authentication and parameter handling, but omits what the agent should expect after invocation. The schema contradiction adds to the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'body' parameter, so the baseline is 3, but the description incorrectly states the body is 'optional' (schema requires it). It does add useful context about JSON payload and parameter name aliases, but the contradiction significantly reduces reliability.
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 verb and resource: 'Create a new api token' and 'Raw Vikunja REST proxy for PUT /tokens.' It also distinguishes from siblings by specifying creation on behalf of the user, which sets it apart from delete/get token tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it's a raw REST proxy, requires authentication, and explains how to pass parameters (body field, top-level fields, aliases). It does not explicitly mention alternatives or when-not-to-use, but the context is sufficient for distinguishing from other token 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 must disclose behavioral traits. It only says 'Delete,' which implies a destructive operation, but does not mention whether deletion is permanent, whether it cascades to tasks or related data, whether confirmation is required, or what permissions are needed. This leaves significant behavioral ambiguity for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Delete a project by ID.' It contains no filler, restates nothing, and is appropriately sized for a one-parameter tool. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description is minimally adequate but does not explain return values, error conditions, or side effects (e.g., whether related tasks are deleted). Given the simplicity, it is a passable baseline, but there is a clear gap in behavioral 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 already provides full coverage (100%) with a single parameter 'project_id' described as 'Project ID.' The description adds only 'by ID,' which mirrors the schema without adding new semantic detail. Since schema coverage is high, the baseline of 3 is appropriate.
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 'Delete a project by ID' uses a specific verb ('Delete') with a clear resource ('project') and method ('by ID'), distinguishing it from sibling tools like vikunja_get_project, vikunja_update_project, and vikunja_delete_task. It directly states the operation's purpose without ambiguity.
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 guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or scenarios where a different tool (e.g., vikunja_get_project or vikunja_update_project) would be more appropriate. The only implied usage is 'to delete a project,' which is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, idempotency, error behavior (e.g., removing a non-existent label), permissions, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that uses no filler words. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and parameters are fully described, but the lack of any behavioral context (return values, error handling, or relationship to sibling tools) leaves gaps. It is minimally viable but not comprehensive.
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 100% coverage with descriptions for both task_id and label_id, so the description does not need to explain them. It adds no additional semantic context beyond what the schema already conveys.
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 'Remove a label from a task' clearly states a specific verb (remove), a specific resource (label), and the target (task). It distinguishes itself from sibling tools like vikunja_add_label_to_task by indicating the reverse operation.
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 vikunja_add_label_to_task or vikunja_list_task_labels. There are no prerequisites or context hints, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses that authentication is required and explains the raw proxy behavior including top-level path/query parameters and alias conventions. However, it does not describe side effects beyond deletion, response format, or error behavior, leaving gaps 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the purpose stated first, followed by endpoint details, payload handling, aliases, and authentication. Each sentence adds value, though the phrasing 'optional body field' is a bit ambiguous but still compact.
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 complex raw proxy nature and lack of output schema/annotations, the description covers key aspects: endpoint, body, aliases, and auth. However, it omits crucial details like valid relationKind values and the structure of the relation object, and the body optionality contradiction undermines completeness. Schema property descriptions partially compensate but still leave the relation type undefined.
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 useful context about top-level fields and camelCase/snake_case aliases, but it states 'optional body field' while the schema marks body as required, creating a direct contradiction that could mislead the agent. Additionally, it does not clarify which of the path parameters are mandatory despite the schema property descriptions saying 'Required' but not being in the required array.
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 'Remove a task relation' with a specific verb and resource, and includes the exact REST endpoint (DELETE /tasks/{taskID}/relations/{relationKind}/{otherTaskID}), distinguishing it from sibling task deletion tools. This leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions 'Raw Vikunja REST proxy' which implies a low-level tool, but does not name higher-level alternatives or state when to choose this over them. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that authentication is required, that it's a raw proxy, and that parameters are top-level. However, it does not describe return values, error handling, idempotency, or side effects beyond the reaction removal, leaving behavioral details incomplete.
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 short but repeats itself: 'Removes the user's reaction' and 'Removes the reaction of that user' convey the same information. Front-loading is decent, but the redundancy could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and annotations are absent, so the description should explain return values and clarify request/response behavior. It does not mention what happens on success or failure, and the body parameter semantics are contradictory, leaving the agent with incomplete information 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 useful conventions (path/query top-level fields, camelCase/snake_case aliases), but it directly contradicts the schema by calling the 'body' field optional while the schema marks it required. It also fails to clarify the body content—the schema describes it as 'the reaction you want to add,' which conflicts with the tool's removal purpose. This undermines parameter understanding.
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 tool's function: 'Removes the user's reaction' and 'Removes the reaction of that user on that entity.' It identifies the specific resource (reactions on a Vikunja entity) and the action (removal), distinguishing it from sibling tools that handle other operations like creating tasks or projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on how to use the tool (raw REST proxy, auth required, parameter conventions) but does not explicitly state when to use it versus alternatives or mention any exclusion criteria. It implies usage for direct API access but lacks explicit 'use this instead of X' guidance.
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?
The description discloses useful behavioral traits such as returning a JWT token and accepting camelCase/snake_case aliases. However, it contains a critical misstatement: it calls the body field 'optional' while the schema marks it as required. This contradiction misleads agents about a mandatory parameter and undermines trust.
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 reasonably compact and front-loaded with 'Login', but contains redundancy ('Raw Vikunja REST proxy' vs 'Logs a user in') and generic proxy notes ('Path and query parameters are top-level fields') that may not apply. The incorrect 'optional' also detracts from clarity.
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?
Without an output schema or annotations, the description must fully explain invocation and expected results. It covers the token and auth requirement, but fails to specify what credentials the body should contain (e.g., username/password) and incorrectly labels body as optional, leaving important gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for body ('The login credentials'), so baseline is 3 given 100% coverage. The description adds 'JSON request payload' and alias handling, but the 'optional body field' claim directly contradicts the schema's required flag, providing misleading guidance rather than meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Login', 'Logs a user in', and 'Returns a JWT-Token to authenticate further requests'. It also identifies the exact endpoint ('POST /login') and 'Raw Vikunja REST proxy', distinguishing it from registration or other vk_post_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to log in and obtain a JWT for subsequent authenticated requests. It also notes that authentication is not required. However, it does not explicitly name alternative tools or state when not to use it.
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 must fully disclose behavior. It mentions migration scope and authentication, but it contradicts the input schema by calling the body field 'optional' while schema requires it. It also omits possible side effects, error behavior, or idempotency.
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 reasonably brief and front-loaded, but it contains redundancy: 'Migrate all lists, tasks etc.' is repeated by 'Migrates all projects, tasks, notes...'. Generic proxy boilerplate adds little value.
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 only one parameter and no output schema, the description should clearly state the expected result of migration, but it does not. The inconsistency about the body field's optionality undermines completeness, and no return format or async behavior is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single body parameter with its own description. The description adds guidance about aliases and body passing, but it incorrectly labels the body as optional and references non-existent path/query parameters, adding confusion rather than clarity.
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 tool migrates Todoist data to Vikunja with the explicit endpoint 'POST /migration/todoist/migrate'. It distinguishes itself from sibling migration/get_migratio tools by the action and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is the migration trigger and explains how to pass the body payload. It does not explicitly contrast with GET migration status tools, but the endpoint and verb make the use case clear.
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 transparency. It discloses authentication requirements and the raw proxy nature, but it contradicts the schema by calling the body 'optional' when it is actually required. This inconsistency undermines clarity about how to invoke the tool correctly.
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 concise but contains redundancy: 'Set an unsplash photo as project background' appears twice. It is structured logically but some sentences could be merged to reduce repetition without losing information.
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 no output schema and no annotations, the description should be more complete. It does not mention response format, side effects, or success/failure indicators. The contradiction regarding the required body leaves a critical gap in understanding how to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful alias information and path/query parameter handling, but it incorrectly states that the body is optional, which conflicts with the schema. This misdescription detracts from the semantic value and could mislead the agent.
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 tool's function: 'Set an unsplash photo as project background.' It specifies the verb 'set', the resource 'project background', and the specific source 'unsplash'. The endpoint is explicitly named, distinguishing it from other project-related post tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by specifying the exact REST endpoint and purpose. It does not explicitly mention alternatives or exclusions, but the focused endpoint description makes the usage context clear enough for distinguishing from other project update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions authentication and that it is a raw proxy, but it also misleadingly states the body field is 'optional' while the schema requires it. This internal contradiction reduces trust in the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and logically structured, starting with the purpose, then the endpoint, then usage notes. It repeats 'update' in the first and third sentences, but this is minor; overall every sentence carries useful information without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain inputs, outputs, and side effects. It covers input handling and authentication but omits any description of the response format or error cases, and the optional/required contradiction leaves a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds valuable context about the body being a JSON payload and path/query parameters being top-level. However, the false claim that the body is optional contradicts the schema's required flag, which is a significant semantic error that would mislead an agent.
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 tool updates an existing kanban bucket, with a specific REST endpoint (POST /projects/{projectID}/views/{view}/buckets/{bucketID}). This distinguishes it from sibling tools that target different resources or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical invocation details (JSON payload in body, top-level path/query parameters, camelCase/snake_case aliases, authentication required) but lacks explicit guidance on when to use this tool vs alternatives. It does not mention when not to use it or compare it to other update 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?
With no annotations, the description must fully disclose behavior. It does disclose authentication and permission requirements, but it incorrectly states the body field is optional while the schema marks it as required. This misstatement about a critical behavioral aspect undermines trust and makes the description misleading.
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 relatively short but contains redundancy: 'Add a label to a task' appears twice. It also mixes implementation details (raw proxy) with usage instructions. The structure is functional but not polished, with some wasted repetition.
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 2-parameter tool with no output schema and no annotations, the description covers the core purpose, auth, and permission requirements, but leaves gaps: it does not explain the response format, error conditions, or what the label object should contain. The misleading 'optional body' statement also detracts from completeness.
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 basic descriptions for both parameters. The description adds useful info about aliases and top-level fields, but it also introduces an error by calling the body optional. The added value is moderate, but the contradiction with the schema reduces confidence. 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 clearly states the tool adds a label to a task and identifies it as a raw REST proxy for PUT /tasks/{task}/labels, giving a specific verb and resource. However, it does not differentiate this from the sibling tool vikunja_add_label_to_task, which performs the same action, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context: it mentions write-access requirement, authentication, and how to pass parameters (top-level fields, aliases). It implies the raw proxy nature, but does not explicitly state when to prefer this over the typed vikunja_add_label_to_task, nor does it give exclusions. Clear context without explicit alternatives.
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 states the basic create operation without mentioning side effects, required permissions, whether the created task is returned, or any constraints (e.g., project must exist). For a mutation tool, this level of transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose without any unnecessary words. It is appropriately brief and front-loaded.
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?
While the schema covers all parameters, the description is incomplete for a tool with 14 parameters and no output schema. It does not explain what happens after creation, any prerequisites (e.g., project existence), or how the response is structured. The minimal description leaves significant gaps for the agent.
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 has 100% description coverage for all 14 parameters, so the baseline is 3. The description itself adds minimal parameter semantics beyond implying project_id ('inside a project'), but since the schema already documents every parameter thoroughly, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a task inside a project.' It uses a specific verb and resource, and the context 'inside a project' distinguishes it from task update, delete, or project creation tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'inside a project' implies that this tool is used when creating a task that belongs to a project, but it does not explicitly discuss when to prefer this over alternative tools (e.g., vikunja_update_task, vikunja_create_project). There is no exclusion or alternative comparison, so the usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses key behaviors: the endpoint is a GET (implying read-only), 'does not usually require a request body', 'Authentication is required', and parameter aliases (camelCase/snake_case) are accepted. This is substantial transparency, though it stops short of describing response structure or error handling.
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 somewhat repetitive: 'Search for a background from unsplash' and 'Search for a project background from unsplash' convey nearly the same meaning. While the remaining details are concise and structured, the redundancy wastes a sentence and reduces overall efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters and no output schema, the description covers important aspects like authentication, request body expectations, and parameter handling. However, it does not describe the response format or pagination semantics beyond the schema's page parameter, and it fails to differentiate from sibling tools. It is adequate for a simple proxy tool but not fully 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?
Schema coverage is 100% with clear descriptions for 'p' (page number) and 's' (search term), so the baseline is 3. The description adds useful invocation semantics: 'Path and query parameters are top-level fields' and 'Original parameter names also accept camelCase and snake_case aliases'. This goes beyond the schema to explain parameter naming flexibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search for a background from unsplash' and specifies the exact endpoint (GET /backgrounds/unsplash/search). It is a specific verb+resource pairing, but it does not distinguish this tool from similarly named sibling background tools (e.g., vk_get_backgrou_9a4b6fd79afd), so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, especially given multiple similar sibling tools. It provides some context about authentication and request body, but no explicit when/when-not or alternative recommendations, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It adds useful context: authentication is required, body field is optional, parameters are top-level, and camelCase/snake_case aliases are accepted. However, it omits side effects, response format, and whether updates are partial or full replacements.
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 first three sentences are redundant: 'Updates a saved filter' and 'Updates a saved filter by its ID' repeat the same idea. The remaining sentences provide useful details, but the redundancy makes it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the endpoint, authentication, and parameter conventions, but lacks details about success/failure responses and does not clarify the distinction between this POST endpoint and the sibling PUT filter endpoint. Given there is no output schema, additional behavioral context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters, but the description adds practical value by explaining that the body carries the JSON payload, parameters are top-level fields, and alias naming conventions are supported. This goes beyond the schema's 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 tool updates a saved filter via POST /filters/{id}. The verb and resource are specific, but it does not distinguish from sibling tools like vk_put_filters_dac0a4e19aa2 that may also update filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it updates a filter by ID and mentions authentication, but it does not explicitly explain when to use this over alternatives, such as PUT endpoints, or provide exclusion criteria. It offers clear context but no alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required and that it's a raw REST proxy, but does not explain side effects of moving a task (e.g., reordering behavior), idempotency, or error outcomes. This is a mutation tool, so more detail on consequences would be expected.
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 fairly short but repeats 'Updates a task position' twice, which is unnecessary. It is front-loaded with the main action, but the repetition and slight clutter reduce conciseness.
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 raw proxy with no output schema, the description should explain what the response contains, but it does not. It also fails to clarify the requiredness of the 'id' parameter and contradicts the schema regarding the 'body' parameter. The tool is relatively simple, but these gaps make it incomplete for an agent to use 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?
The description adds value by explaining that path/query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases. However, it describes the body field as 'optional' while the schema lists it as required, creating a contradiction. The schema already provides descriptions for both parameters, so the added value is moderate.
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 'Updates a task position', which is a specific action on a specific resource. It also names the exact endpoint (POST /tasks/{id}/position), distinguishing it from other task-related tools like vikunja_update_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the endpoint and action, but does not explicitly state when to use this raw proxy versus the higher-level vikunja_update_task tool. It mentions authentication is required but lacks exclusions or alternative recommendations.
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 carries the full transparency burden. It discloses the email trigger and auth requirement, but contradicts the input schema by calling the body field 'optional' when the schema marks it as required. It also does not explain the response format or any other side effects beyond the email trigger.
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 concise overall but contains redundancy: 'Request the deletion of the user' and 'Requests the deletion of the current user' are essentially repetitive. It is structured with useful technical details but could be tighter.
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 single-parameter tool, the description covers the email flow and authentication, which is reasonable. However, the optionality contradiction and lack of information about the response or post-request behavior leave notable gaps, especially given no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3, but the description actively misleads by describing the required body as 'optional'. While it adds info about parameter aliases and JSON payload, the contradiction significantly reduces the helpfulness for correctly invoking the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request the deletion of the user' and identifies the exact endpoint 'POST /user/deletion/request'. This is specific, uses a clear verb+resource structure, and distinguishes it from sibling tools that target other user-related endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: it explains the email confirmation flow and that authentication is required. However, it does not explicitly mention alternatives or when not to use it, which would have made it fully explicit.
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 must fully disclose behavior. It does mention authentication requirements, parameter alias conventions, and that path/query parameters are top-level fields. However, there is an internal contradiction: it calls the body 'optional' while the schema lists it as required, and it says 'Project ID Required' though the schema does not require id. This inconsistency undermines transparency and could mislead an agent about required inputs. No information about return values or side effects 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 relatively short (four sentences) and front-loaded with the primary action. It avoids excessive detail but includes a slight redundancy: 'Add a team to a project' and 'Gives a team access to a project' convey similar meaning. Most sentences carry useful information, so it is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple proxy, but as a mutating operation with no output schema and no annotations, the description should cover typical invocation concerns. It explains authentication, parameter placement, and alias handling, which is a good foundation. However, it omits response format, error scenarios, and any safety notes, and the internal requiredness contradiction leaves the agent with an incomplete and somewhat inconsistent picture. It is adequate but not comprehensive.
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 both parameters already have descriptions. The tool description adds value by clarifying that body contains the JSON payload and that parameter names accept camelCase/snake_case aliases, which is useful beyond the schema. However, it also introduces confusion about the body's requiredness, detracting from the semantic clarity. Overall, it adds some meaning but is partially offset by the inaccurate 'optional body' phrase.
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 with a specific verb and resource: 'Add a team to a project' and 'Gives a team access to a project.' It also identifies the exact REST endpoint ('PUT /projects/{id}/teams'), which distinguishes it from the many sibling vk_put_projects_* tools that likely target different endpoints. The purpose is unambiguous and self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by labeling the tool a 'Raw Vikunja REST proxy' and specifying the endpoint, implying it is for low-level access. However, it does not explicitly state when to prefer this over higher-level vikunja_* alternatives (e.g., vikunja_add_label_to_task) or other vk_put_projects_* variants. Usage context is implied but not fully mapped; no exclusions or alternative recommendations are given.
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?
The description discloses useful traits like authentication requirements, write-access prerequisite, and parameter aliasing. However, it incorrectly states that the body field is 'optional' when the schema marks it as required, which is a misleading behavioral contradiction that undermines trust.
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 reasonably concise but contains redundancy: 'Share a project via link' appears twice. This repetition wastes a sentence and could be tightened. The structure is clear otherwise, starting with the main 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?
Without annotations or an output schema, the description carries full responsibility. It covers the action, permission, and authentication but omits return-value expectations, error behavior, and fails to correct the body optionality contradiction. Incomplete for a mutation proxy 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?
Schema coverage is 100%, so parameters are documented. The description adds general guidance about 'path and query parameters being top-level fields' and alias support, but the false 'optional' statement regarding the body adds confusion rather than value. Baseline 3 is appropriate.
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 tool's purpose: 'Share a project via link' and specifies the underlying endpoint 'PUT /projects/{project}/shares'. This distinguishes it from sibling proxy tools, which target different endpoints or resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: requires write-access to the project and authentication. It doesn't explicitly mention alternatives or when not to use, but the endpoint specificity and permission requirement give sufficient guidance for a proxy tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool lists labels visible to the authenticated user, implying a read-only operation and authentication requirement, but does not disclose pagination behavior, default page size, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, succinctly conveying the tool's purpose without unnecessary elaboration. It is 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 tool is a simple list operation with three optional parameters documented in the schema. However, the description does not explain the return format or how pagination/search affect results, and with no output schema, the agent has limited context about what exactly will be returned.
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 (page, search, per_page) with 100% coverage, meeting the baseline for parameter semantics. The description adds no additional parameter details, which 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 uses the specific verb 'List' and identifies the resource 'labels' with the scope 'visible to the authenticated user'. This distinguishes it from sibling tools like vikunja_list_task_labels, which lists labels for a specific task, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that for task-specific labels, one should use vikunja_list_task_labels, nor 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action 'list comments' and does not mention non-destructive nature, permissions, response format, or pagination. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that directly conveys the tool's purpose. It is concise and front-loaded with the key verb and object, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two documented parameters, but the absence of annotations and output schema leaves gaps. The description does not mention what the response contains or any behavioral nuances, making it adequate but not comprehensive.
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 both parameters (task_id and order_by) with 100% coverage. The description adds no additional meaning about parameters, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('comments on a task'). It is implicitly distinguished from sibling tools like 'vikunja_list_task_labels' and 'vikunja_create_task_comment'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives or any exclusions. No context is given for ordering or filtering options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does well: it states the destructive action, the cascading side effect ('This will also remove the access for all users in that team'), and the authentication requirement. It does not mention irreversibility, error behavior, or response format, but the key behavioral traits are disclosed.
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 front-loaded with the key statement 'Deletes a team.' and is fairly compact, but it contains a redundant sentence: 'Delets a team.' repeats the first sentence with a typo. This wasted sentence prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete endpoint with no annotations or output schema, the description is reasonably complete: it covers the action, a critical side effect, the auth requirement, request body expectation, and parameter formatting. It could add error cases or response codes, but the core information an agent needs is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single 'id' parameter has a description), so the baseline is 3. The description adds value by explaining that parameters are top-level fields, accept camelCase/snake_case aliases, and that no request body is usually required, which clarifies how to supply 'id' beyond the schema's anyOf type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Deletes a team.' and maps it to the explicit REST endpoint 'DELETE /teams/{id}', which makes the verb and resource unambiguous. It distinguishes itself from delete tools for other resources (projects, tasks, labels), though it does not differentiate between the two similarly-named team deletion siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides invocation tips (authentication required, no request body usually, top-level parameters, camelCase/snake_case aliases) but gives no guidance on when to choose this tool over alternatives. It never mentions sibling tools like vk_delete_teams_e7d740105b63 or contrasts with team update/create endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses visibility criteria, optional request body, and auth needs. However, it omits response format, pagination behavior details, and error scenarios.
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 front-loaded with purpose and each sentence provides useful information. It is slightly long but not wasteful, balancing detail with readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify return value shape and pagination behavior. It covers purpose, visibility, and auth well but leaves response structure unspecified. For a simple list-get operation, it is adequate but not 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?
Schema already describes all parameters with 100% coverage. The description adds value by explaining that parameters are top-level query fields and accept camelCase/snake_case aliases, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves labels accessible to the user, with specific scope details. The 'Raw Vikunja REST proxy' hint distinguishes it from higher-level siblings, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context like parameter aliases, top-level fields, and authentication requirements, but does not explicitly state when to prefer this tool over alternatives such as vikunja_list_labels.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose meaningful behavior: 'Returns json on error,' 'does not usually require a request body,' 'Path and query parameters are top-level fields,' camelCase/snake_case aliases, and 'Authentication is required.' It does not, however, describe the successful response format (e.g., whether binary image data is returned), which keeps this from a 5.
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 reasonably short but repetitive: 'Get the project background' is effectively restated as 'Get the project background of a specific project.' The additional details are useful, yet the redundancy could be trimmed. It is structured with key facts scattered rather than tightly organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET proxy, the description covers authentication, error behavior, and parameter passing conventions. However, with no output schema, it fails to explain what a successful response returns (image bytes? JSON?), leaving a notable gap for an agent that needs to interpret results. It is adequate 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 documents the single 'id' parameter as 'Project ID Required' (100% coverage), so the baseline is 3. The description adds mild value by clarifying that path/query parameters are top-level fields and that original parameter names accept camelCase/snake_case aliases, but it does not fundamentally enrich the meaning of the parameter beyond what the schema states.
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 tool's function: 'Get the project background' and 'Get the project background of a specific project.' It identifies the exact REST endpoint (GET /projects/{id}/background), which distinguishes it from generic project tools like vikunja_get_project. The verb+resource pairing is specific and unambiguous.
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 on when to use this tool versus alternative tools is provided. The description does not name alternatives or exclusionary conditions. It only gives request-construction details (top-level fields, aliases) and authentication requirements, which are not about selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses authentication requirements, that a request body is usually unnecessary, and that parameters accept camelCase/snake_case aliases. It does not mention response format, pagination defaults, or explicitly confirm read-only behavior, leaving some gaps.
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 short and front-loaded, but it is redundant: 'Get all attachments for one task' and 'Get all task attachments for one task' repeat the same idea. There is also stray punctuation ('..') and a double space. It could be tightened to one clear purpose sentence followed by the technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET endpoint, the description covers purpose, auth, body expectations, and parameter placement. However, with no output schema and no annotations, it leaves the response shape implicit and does not address pagination behavior beyond the schema. It is workable but not fully complete for an agent needing to know what the call returns.
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 id, page, and perPage. The description adds general invocation guidance about top-level fields and aliases, which is helpful, but it does not add deeper per-parameter semantics beyond what the schema already provides.
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 and resource: 'Get all attachments for one task' and identifies the exact REST endpoint 'GET /tasks/{id}/attachments'. This is specific and distinguishes it from sibling task tools that operate on tasks rather than attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful invocation context: 'Path and query parameters are top-level fields', 'This endpoint does not usually require a request body', and 'Authentication is required'. However, it does not explicitly state when to use this tool versus alternatives, which is relevant given the large number of sibling task endpoints.
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?
Without annotations, the description must disclose behavior, and it does mention authentication requirements and alias handling. However, it contradicts the input schema by calling the body field "optional" when schema marks it as required, which could mislead the agent. It also omits any mention of side effects, conflicts, or error conditions beyond "creates a new user account."
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the key purpose stated early. Each sentence adds some information (resource, purpose, payload, aliases, auth), though the initial "Register." is redundant and the structure is somewhat fragmented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter proxy endpoint, the description covers purpose, request payload, and auth requirements. However, without an output schema or annotations, it does not mention what the response contains, how errors are surfaced, or the fact that body is required, leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% and the schema already describes body as "The user with credentials to create," the description's claim that the body is "optional" directly contradicts the required field. This actively undermines parameter understanding rather than adding value, so it scores below the baseline.
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 identifies the tool as a registration endpoint ("POST /register") and states its function: "Creates a new user account." The verb is specific and the resource is unambiguous, distinguishing it from sibling login or user-management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context that this is the registration endpoint for creating a new account and notes that authentication is not required. However, it does not explicitly name alternatives (e.g., vk_post_login for existing users) or provide exclusion criteria, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that authentication is required, notes the raw proxy nature, and explains parameter aliasing. However, it omits important details such as whether the update is partial or full replacement, what side effects occur on existing fields, and what the response format looks like. The claim that the body field is 'optional' is also inaccurate because the schema marks it as required, reducing trust.
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 moderately concise and information-dense. It repeats 'Update a task' twice, which is slightly redundant, but every other sentence contributes useful details (e.g., authentication, aliases, body handling). It is structured logically from purpose to special cases to usage mechanics, earning it a high but not perfect score.
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 raw proxy tool with no output schema and no annotations, the description explains how to call it (body, aliases, auth) but fails to provide context about expected responses, error behavior, or when to use it relative to higher-level sibling tools. It also leaves the body schema unspecified, which is a significant gap. Overall, it is minimally adequate but lacks completeness for an agent to invoke it confidently.
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 100%, so the baseline is 3, but the description introduces a contradiction by calling the body 'optional' while the schema requires it. Although it adds useful notes about top-level fields and camelCase/snake_case aliases, it fails to describe the body structure or expected fields beyond a generic 'task object.' This misleading characterization and lack of substantive param explanation push the score below baseline.
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 'Update a task' as the primary purpose, with a specific resource (tasks/{id}) and verb (update). It also explicitly mentions 'marking it as done,' which narrows scope and distinguishes it from simple creation or deletion. The 'Raw Vikunja REST proxy' phrasing additionally signals this is a low-level endpoint, aiding in differentiation from higher-level sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives some usage context: it tells users to pass JSON in the body field, that path/query parameters are top-level fields, and directs to individual endpoints for assignee/label updates. However, it does not explicitly state when to use this tool versus alternatives like 'vikunja_update_task' or other task-related siblings, nor does it provide exclusion criteria. The guidance is therefore implied rather than explicit.
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 carries full burden. It discloses authentication requirements and parameter alias behavior, but it misleadingly calls the body field 'optional' while the schema marks it required. It also fails to mention the response format or any side effects of downloading an export, leaving significant behavioral ambiguity.
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 short and mostly to the point, with three sentences covering purpose, usage, and authentication. Minor issues include a double period and the redundant phrase 'Raw Vikunja REST proxy' after the first sentence, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify what the agent can expect from the tool. It does not mention the return type or contents of the download, nor any prerequisites beyond authentication. Given the one-parameter complexity and absence of annotations, the description is incomplete for safe invocation.
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% for the body parameter, which already explains it's a user password. The description adds the notion of a JSON request payload and mentions camelCase/snake_case aliases, but these are not clearly applicable to the single body parameter and the 'optional' wording contradicts the schema. Thus the description adds little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a user data export, using a specific verb and resource. It further specifies it's a raw proxy for POST /user/export/download, distinguishing it from the many other vk_post_user_* sibling tools that handle different user operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it downloads a user export via a specific endpoint, and provides instructions on how to pass parameters (body, path/query, aliases). It also notes authentication is required, which guides the agent. However, it does not explicitly exclude alternatives or mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add useful context: it mentions the raw proxy nature, parameter alias conventions (camelCase and snake_case), top-level path/query parameters, and authentication. However, it describes the required 'body' as 'optional', contradicting the schema, and does not disclose response behavior or side effects beyond creation.
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 fairly compact but redundant: 'Create a project view' appears twice in the opening sentences. The remaining sentences each add useful information, but the repetition makes it slightly less crisp than it could be.
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 two-parameter tool, the description covers the core purpose, payload handling, aliases, and authentication. However, it lacks details about what fields the project view body should contain, what the response looks like, and it contains the body-optional inconsistency. No output schema exists, so some return-value guidance would improve completeness.
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%, so the baseline is 3. The description adds value by explaining JSON payload placement, parameter aliases, and top-level path/query fields. But it incorrectly labels the 'body' parameter as optional while the schema marks it required, and it claims 'Project ID Required' though 'project' is not in the schema's required list, creating confusion.
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 ('Create a project view') and the resource ('project view'), with the exact REST endpoint 'PUT /projects/{project}/views'. This distinguishes it from the many sibling vk_put_projects_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: create a project view in a specific project via a raw REST proxy, and notes that authentication is required. However, it does not explicitly mention when not to use this tool or suggest a higher-level alternative, so usage guidance remains implied rather than explicit.
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 disclosing behavior. It mentions the raw proxy nature, authentication, and parameter aliases, but omits error behavior, idempotency, and response shape. Critically, it calls the body 'optional' while the schema marks it required, which is misleading.
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 five short sentences, front-loaded with the core purpose, and every sentence adds relevant operational detail. There is no filler or repetition.
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 covers the core purpose, auth, and parameter passing style, but it omits the required body structure and contradicts the schema on whether body is required. Since there is no output schema and no annotations, the agent needs more precise payload details to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters at 100% coverage, so the baseline is 3. The description adds useful conventions (body field, top-level params, aliases), but the false statement that body is optional contradicts the schema's required field, and the body description gives no detail about its expected structure.
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: 'Add a user to a project' and identifies the exact REST endpoint 'PUT /projects/{id}/users'. It also explains the effect ('Gives a user access to a project'), distinguishing it from other project/user operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful usage context: pass payload in the body field, path/query parameters as top-level fields, camelCase/snake_case aliases, and authentication is required. It does not explicitly name alternative tools or when-not conditions, so it does not earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses error format ('Returns json on error'), authentication requirements, and parameter naming aliases. It stops short of describing the successful response format, but it is transparent for a simple GET endpoint.
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 not excessively long but repeats 'Get an unsplash image.' verbatim, which wastes a sentence. The remaining content is structured and informative, but the redundancy should be removed.
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 single-parameter GET tool with no output schema, the description covers authentication, error behavior, and parameter usage. It does not mention what a successful response returns (e.g., image binary vs. JSON), which would be useful since no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the image parameter already has a description in the schema. The description adds meaningful extra guidance by explaining that path/query parameters are top-level fields and that camelCase and snake_case aliases are accepted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets an unsplash image and identifies the exact REST endpoint (GET /backgrounds/unsplash/image/{image}). However, it does not distinguish itself from sibling tools with nearly identical names like vk_get_backgrou_a6990b2bc73a.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful usage context such as authentication being required, no request body usually needed, and parameter alias handling. However, it does not explicitly explain when to use this tool versus the many sibling background tools or offer any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds useful behaviors: 'does not usually require a request body', top-level parameters, aliases, and required authentication. However, it says 'all notifications' while the schema includes pagination parameters, creating ambiguity about whether all are returned in a single call. This lack of clarity reduces transparency.
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 five sentences long and contains redundancy: the first and third sentences both state 'all notifications for the current user'. While each other sentence adds useful detail (endpoint, body, params, auth), the repetition makes it less concise than it should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool with no output schema, the description covers the essential aspects: purpose, endpoint, authentication, parameter style, and return shape ('array'). It does not clarify pagination behavior or the item structure of notifications, but it is reasonably complete for a list endpoint.
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 descriptions for page and perPage already included. The description notes that parameters are top-level and accept camelCase/snake_case aliases, but this adds little value beyond the schema which already lists both perPage and per_page. Baseline 3 is appropriate.
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 'Get all notifications for the current user' with a specific verb and resource, and it identifies the underlying endpoint 'GET /notifications'. This distinguishes it from sibling tools like vk_get_tasks_* and vk_get_projects_*, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about what the tool does and its endpoint, but it does not explicitly mention alternative tools or when to use this one over others. Usage is implied by the resource ('notifications') but not explicitly differentiated from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, the endpoint usually needs no request body, parameters are top-level fields, and camelCase/snake_case aliases are accepted. It does not cover error behavior or response format, but the GET method implies a safe read operation.
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 front-loaded with purpose and each sentence contributes useful information. There is minor redundancy between 'Get one project view' and 'Returns a project view by its ID', but overall it is concise and logically structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and an output schema, the description is sufficient for a simple two-parameter GET: it specifies the endpoint, auth, parameter placement, aliases, and body expectation. It does not mention return envelope or errors, but those are less critical for this straightforward read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with full coverage. The description adds value beyond the schema by explaining that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which helps with actual invocation.
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 'Get one project view' and provides the exact REST route GET /projects/{project}/views/{id}, making the operation and resource unambiguous. It distinguishes from sibling tools by specifying 'project view' rather than general project operations, though it does not explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools. The description includes technical details like request body and aliases, but never says 'use this for a single project view' or points to alternatives like vikunja_get_project.
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?
It discloses authentication requirements, proxy nature, and parameter alias conventions, but incorrectly labels the body field as 'optional' when the schema marks it as required. This contradiction is misleading and undermines trust in the description, especially since no annotations are present to clarify the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the action, but the phrase 'Updates a project view' appears twice, introducing unnecessary repetition while remaining generally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers authentication, parameter mapping, and alias support, which is reasonable for a raw REST proxy. However, it omits any mention of return values or error behavior, and the 'optional' body misstatement is a notable gap given the schema requires 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?
The schema already covers all parameters with descriptions, so the baseline is 3. The description adds useful guidance on parameter placement and aliases, but the 'optional body' error reduces its reliability and the body structure remains vague.
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 'Updates a project view' and specifies the exact REST endpoint 'POST /projects/{project}/views/{id}', making the tool's purpose unambiguous and distinguishing it from siblings that target other resources or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides the full endpoint and notes that path/query parameters are top-level fields, giving solid context for invocation. However, it does not explicitly state when to use this over alternative tools or mention any 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 carries the full burden for behavioral disclosure. It does mention authentication, raw REST proxy behavior, top-level parameter placement, and alias handling, but it omits response format, error behavior, and side effects. It also states the body field is optional while the schema marks it as required, creating confusion.
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 compact and front-loaded with the purpose, but the first sentence is duplicated verbatim. The rest of the sentences provide valuable proxy details, but the redundancy prevents a higher score.
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 is a raw REST proxy with no output schema or annotations, so the description needs to be thorough. It covers authentication, aliases, and parameter placement, but it does not explain the response format, error cases, or the apparent contradiction between the 'optional' body and the schema's required body. The description is insufficient for a mutation-like proxy 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?
Schema coverage is 100%, so the baseline is 3. The description adds useful semantics beyond the schema: the body is a JSON payload, path parameters are top-level fields, and camelCase/snake_case aliases are accepted. This helps the agent construct the request correctly.
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 ('Update a team <-> project relation') and gives the exact REST endpoint (POST /projects/{projectID}/teams/{teamID}), which distinguishes it from other proxy tools. It also explains the primary use case ('update the permission that team has').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: updating a team's permission on a project. However, it does not explicitly mention alternatives or when not to use it, which is a minor gap given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that authentication is required, that it is a raw proxy, and what the tool does (disables TOTP). However, it does not describe reversibility, response format, or potential side effects, leaving a moderate gap.
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 reasonably sized but includes redundant phrasing ('Disable totp settings' / 'Disables any totp settings') and generic boilerplate about aliases and top-level fields that may not be relevant. It is not poorly structured but could be more streamlined.
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 tool with one parameter and no output schema, the description covers the core action, authentication, and payload passing. However, the optionality contradiction and lack of return-value/error info leave it incomplete. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the body parameter, so the baseline is 3. However, the description incorrectly calls the body field 'optional' while the schema marks it as required, which is a direct contradiction. The generic proxy notes about aliases and top-level fields add little value for this one-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Disable totp settings' and 'Disables any totp settings for the current user.' It also names the exact endpoint path, which distinguishes it from other user-related proxy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to disable TOTP for the current user. It mentions authentication requirements and how to pass the payload, but does not explicitly state when not to use it or name alternatives. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses the raw proxy nature, payload passing, alias behavior, and auth requirement. However, it does not state that confirming the deletion request will actually delete the user or describe the response/effects, which is a notable gap for a destructive action.
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 reasonably short but contains redundancy ('Confirm' and 'Confirms') and generic proxy boilerplate about path/query parameters that do not apply to this schema. Some sentences add little value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no annotations or output schema, the description covers purpose, endpoint, payload passing, and authentication. However, it omits the ultimate consequence (actual user deletion), provides no return-value information, and contains the 'optional body' inconsistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with body described as 'The token.' The description adds 'JSON request payload' but also calls the body field 'optional' while the schema marks it as required—a direct contradiction that could mislead invocation. The camelCase/snake_case alias note is irrelevant for a single 'body' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Confirm a user deletion request') and identifies the exact endpoint (POST /user/deletion/confirm). This is specific enough to distinguish it from the many sibling user-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: confirming a user deletion request sent via email. It also notes that authentication is not required. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the transparency burden. It discloses the HTTP method, endpoint, authentication requirement, and alias behaviors. However, it does not mention response behavior, token consumption, or possible errors beyond the reset action.
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 has some redundancy, like 'Resets a password' followed by 'Resets a user email with a previously reset token,' and includes generic proxy boilerplate. It is front-loaded but not as tight as it could be.
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 one-param tool with no output schema, the description covers the endpoint, auth requirements, and payload placement. However, it omits expected response behavior and contains the optional-body inconsistency, leaving it slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description calls the body field 'optional' while the schema marks it as required. This contradiction could mislead an agent. The alias note adds value, but the optionality error undermines parameter clarity.
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 tool's action ('Resets a password') and identifies the exact Vikunja endpoint (POST /user/password/reset). This distinguishes it from the many sibling tools that target other resources or user operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies the context: resetting a password using a previously reset token, and notes that authentication is not required. It does not explicitly mention when not to use it or name alternatives, but the usage context is clear enough.
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 carries full responsibility for behavioral disclosure. It mentions 'Authentication is required' and 'Raw Vikunja REST proxy,' but it also says 'optional body field' while the input schema marks 'body' as required—a direct contradiction that misleads the agent. It also fails to describe response behavior or error conditions. The inconsistency undermines trust.
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 brief (four sentences) and front-loads the core purpose. However, the third sentence ('Create a webhook target which receives...') is somewhat redundant with the first sentence ('Create a webhook target'), so it is not perfectly concise. Still, it avoids bloat and stays focused.
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?
This is a 2-parameter tool with no output schema, so completeness requirements are moderate. The description covers purpose, parameter passing, and authentication, but it omits critical details about the 'body' object's expected fields (e.g., event types, target URL) and does not clarify the contradiction between 'optional body field' and the schema's required marker. The provided context is enough for basic invocation but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some useful notes about parameter passing ('Path and query parameters are top-level fields' and alias support) but does not elaborate on the structure of the 'body' object beyond the schema's minimal description. The misleading 'optional body field' actually detracts from parameter clarity.
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 tool's purpose: 'Create a webhook target.' It also specifies the exact REST endpoint (PUT /projects/{id}/webhooks), which distinguishes it from other vk_put_projects_* siblings that likely target different project operations. The verb 'create' and resource 'webhook target' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Create a webhook target which receives POST requests about specified events from a project.' It also instructs how to pass parameters ('Pass the JSON request payload in the optional body field') and mentions parameter alias flexibility. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that authentication is required and that creating under a parent project requires write access. It does not describe the response format, whether the operation is idempotent, or that it is a raw REST proxy requiring a body parameter, which is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. However, the phrase 'Creates a new project' is repeated twice, wasting a sentence that could have been used for more useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the tool is a simple create proxy, and the description covers the core behavior, auth, and payload format. It lacks details on response bodies and specific parameters but is reasonably complete for a proxy 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?
Schema coverage is 100% with a single 'body' parameter described as 'The project you want to create.' The description adds that the body is a JSON request payload and that path/query parameters are top-level fields with aliases. That's useful beyond the schema, though it doesn't enumerate possible project fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new project and is a raw Vikunja REST proxy for PUT /projects. However, it does not differentiate among the many sibling vk_put_projects_* variants, which all appear to target the same endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says authentication is required and mentions write-access needs for parent projects, giving some usage context. However, it does not explain when to use this raw proxy versus the more semantic vikunja_create_project or vikunja_update_project siblings, nor does it mention alternatives.
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 merely restates the tool's name and provides no additional behavioral information such as pagination behavior, output format, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, earning its place.
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 list operation, the description covers the basic purpose but lacks details about return values and pagination behavior. Given no output schema and no annotations, it's adequate but not comprehensive.
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 100% coverage with descriptions for all four parameters. The description doesn't add any parameter semantics beyond what the schema states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('labels') with a clear scope ('attached to a task'), distinguishing it from sibling tools like vikunja_list_labels which lists all labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: retrieving labels for a specific task. It doesn't explicitly name alternatives or exclusions, but the task-scoped context is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, that no request body is usually needed, and that path/query parameters are top-level. However, it does not state that deletion is permanent or irreversible, nor does it describe the response. It adds some useful behavioral context but not rich detail.
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 front-loaded with the purpose, but it repeats 'Delete an attachment' twice, which is unnecessary. The rest is informative but could be tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the endpoint, auth, body, and aliases, which is sufficient for a simple delete operation. Missing are explicit requiredness and response expectations. Given no output schema, a brief note on return values would help, but it's not critically absent.
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 lists all parameter variants (id, attachmentID, attachmentId, attachment_id), so coverage is 100%. The description adds value by explaining that original parameter names accept camelCase and snake_case aliases, and that parameters are top-level fields. However, it does not clarify the required status of id and attachmentID, which the schema marks as optional despite the endpoint implying importance.
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 ('Delete an attachment') and identifies the exact REST endpoint (DELETE /tasks/{id}/attachments/{attachmentID}). This distinguishes it from sibling tools like vikunja_delete_task, which deletes tasks rather than attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('Raw Vikunja REST proxy', authentication required) but does not explicitly state when to use this tool instead of alternatives, nor does it mention when not to use it. The purpose is implied by the endpoint, but no explicit comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses authentication requirements, camelCase/snake_case alias handling, and its raw proxy nature. However, it inconsistently calls the body field 'optional' while the schema marks it required, and it omits side effects, response format, or error behavior. With no annotations, this leaves notable gaps.
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 repeats 'Update a user <-> project relation' verbatim, which is unnecessary. Otherwise, it is reasonably concise and front-loaded with the core purpose, but the duplication wastes a sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the endpoint, authentication, and parameter passing conventions, which is helpful for a proxy tool. However, it lacks details on body structure, expected response, and side effects, and the 'optional body' wording conflicts with the schema, leaving the invocation incomplete.
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?
It clarifies that path/query parameters are top-level fields and that aliases are accepted, which adds value over the schema. Yet the body's content is only described as 'the user you want to update' without specifying required fields, and the optional/required discrepancy undermines parameter clarity.
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 it updates a user-project relation, explicitly names the REST endpoint (POST /projects/{projectID}/users/{userID}), and gives the common use case (updating user permissions). This distinguishes it from sibling proxy/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the primary use case (updating permission a user has on a project) and signals it's a raw proxy for direct API calls. It doesn't explicitly name alternatives or when-not-to-use, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It effectively reveals a critical side effect: 'Every user not in the project will be unassigned from the task, pass an empty array to unassign everyone.' It also states authentication is required and that the doer must have edit rights. This goes beyond basic safety to disclose surprising behavior, though it doesn't detail response formats or idempotency.
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 functionally structured but contains redundancy: 'Add multiple new assignees to a task' appears verbatim twice. It is not overly long, but the duplication wastes words. The key behavioral warnings and parameter notes are present, though a tighter version would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description provides a robust set of context: purpose, prerequisites, side effects, parameter handling, and authentication. It is largely complete for a mutation proxy, but the optional/required body contradiction and lack of any return-value hints leave minor gaps. Overall, it covers the essential operational context well.
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 useful notes about parameter aliases and top-level fields, but it contradicts the schema by calling the body field 'optional' when the schema lists 'body' as required. This mismatch could mislead an agent about invocation requirements. The schema already documents 'body' as an array of assignees, so the added value is undermined by the inconsistency.
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 'Add multiple new assignees to a task' as the primary purpose, with a specific verb and resource. It also specifies the exact REST endpoint (POST /tasks/{taskID}/assignees/bulk), distinguishing it from generic task proxies. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (adding assignees) and notes prerequisites like project access and edit permissions. However, it does not explicitly mention alternatives or when not to use it, leaving usage guidance implied rather than explicit. There is no comparison to sibling tools like other vk_post_tasks_* endpoints.
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?
The description notes that authentication is not required and explains parameter alias handling, but it does not disclose side effects, error behavior, or whether the operation is idempotent. It also inconsistently calls the body field 'optional' while the schema marks it required, adding confusion.
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 somewhat repetitive ('Confirm the email of a new user' and 'Confirms the email of a newly registered user') and includes generic proxy boilerplate. It could be trimmed to the essential information without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, it covers the core action, authentication, and parameter passing. But it fails to mention the return value, potential errors, or the discrepancy between 'optional body' and the required schema, making it incomplete.
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 schema already describes the single 'body' parameter as 'The token.' The description enhances this by explaining how to pass the JSON payload, that path/query parameters are top-level fields, and that camelCase/snake_case aliases are accepted. However, it misleadingly labels the body as optional.
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 tool confirms a new user's email, specifying the verb (confirm) and resource (email of new user). It also identifies the underlying endpoint POST /user/confirm, distinguishing it from other user-related post tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for confirming the email of a newly registered user. It does not explicitly mention alternatives or when not to use it, but the use case is specific enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a raw REST proxy, that it aborts a pending deletion, and that no auth is needed. However, it does not describe success/error responses, side effects, or what happens if no deletion is in progress.
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 purpose is front-loaded, but the first and third sentences say essentially the same thing ('Abort a user deletion request' vs 'Aborts an in-progress user deletion'), which wastes a sentence. Overall length is acceptable, but not every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter proxy action, the description covers the key operational details: endpoint, body payload, authentication, and parameter naming conventions. It lacks explicit return-value expectations, but with no output schema and low complexity, it is reasonably complete for 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?
Schema coverage is 100% and the schema already defines body as 'The user password to confirm,' so the description adds little. It introduces generic alias/top-level-field conventions, but also calls the body 'optional' even though the schema marks it required, which is misleading and could cause incorrect invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Abort a user deletion request' and repeats 'Aborts an in-progress user deletion.' It also names the exact REST endpoint, making the purpose unmistakable and distinguishing it from sibling delete/cancel tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly instructs to pass the JSON request payload in the body field and states authentication is not required. This provides clear operational context, though it does not explicitly mention when not to use the tool or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication, creator requirement, and parameter aliasing. However, it states 'Pass the JSON request payload in the optional body field' while the schema lists 'body' as required, which creates confusion about the actual behavior. It also does not describe response format or error conditions.
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 front-loaded with the primary action 'Update a label' and is compact overall. However, there is redundancy: 'Update a label' and 'Update an existing label' convey the same idea, and the raw proxy explanation is repeated. Still, the key information is presented concisely enough for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation and the absence of an output schema, the description is reasonably adequate but has gaps. It does not mention what the response will contain (e.g., the updated label object) or possible error scenarios (e.g., 404 if not found). The misleading 'optional body' comment also leaves incomplete guidance for constructing a valid request.
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 schema covers 100% of parameters but with minimal detail (e.g., body just 'The label object'). The description adds value by explaining that 'Path and query parameters are top-level fields' and that parameter names accept camelCase and snake_case aliases. This clarifies how to invoke the proxy beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Update a label.' It also specifies it's a raw proxy for PUT /labels/{id}, which clarifies the resource and operation. However, it does not differentiate from sibling tool 'vk_put_labels_de9ad1e5fe26' which likely performs the same action, and the title is null, preventing further distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'The user needs to be the creator of the label to be able to do this' and 'Authentication is required.' This gives a strong condition for when the tool can be used. However, it does not explicitly mention alternatives (e.g., use vikunja_create_label for creating labels) or exclusions beyond the creator requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it creates a relation, requires authentication, and explains parameter alias handling and top-level path/query fields. With no annotations, it carries the full burden, but it omits response format, duplicate-relation behavior, and error scenarios. It also states 'optional body field' while the schema marks body as required, a contradiction that reduces transparency.
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 sentence 'Create a new relation between two tasks' appears verbatim twice, and the description has some redundancy. It is front-loaded with purpose and not excessively long, but the repetition is wasteful.
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?
Covers purpose, permissions, auth, payload location, and parameter aliases. But with no output schema or annotations, it does not explain return values, error handling, or body fields, and the optional-vs-required discrepancy weakens completeness. It is adequate for a raw proxy but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), and the description adds useful info about aliases and top-level fields. However, it calls the body 'optional' when the schema requires it, does not describe the relation object's structure beyond pointing to docs, and the taskID aliases are just restated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new relation between two tasks,' a specific verb+resource statement, and reinforces it with the exact endpoint 'PUT /tasks/{taskID}/relations'. This clearly distinguishes the tool from siblings, even among the many vk_put_tasks variants, because the operation is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states permission requirements ('update permissions on the base task and at least read permissions on the other task') and notes that tasks do not need to be on the same project. It does not explicitly name alternatives or exclusions, but this context is sufficient for deciding when this raw endpoint is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It correctly implies a read-only listing operation and adds the scope of visibility, but does not disclose return format, pagination behavior, or the meaning of 'visible' beyond user access.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the essential purpose without unnecessary words or repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with fully documented optional parameters, the description is adequate. It lacks explicit mention of pagination or return shape, but the schema covers the parameters, and the behavior is simple enough to infer. However, given no output schema and no annotation, a bit more detail would improve completeness.
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-specific context beyond the already detailed schema properties (page, search, per_page, is_archived, include_permissions).
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 verb ('List'), the resource ('projects'), and the scope ('visible to the authenticated Vikunja user'), distinguishing it from singular get_project and mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: use this to list projects for the current user. However, it does not explicitly mention when to prefer this over other list tools (e.g., vk_get_projects_* siblings) or exclude cases like needing a single project by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explicitly mentions authentication, write-access permission, the fact that a request body is usually not required, and parameter alias conventions. It omits response/error behavior but is otherwise transparent.
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 mostly compact and front-loaded, but the phrase 'Remove a link share.' appears twice, which is redundant. The rest is efficiently worded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete proxy with no output schema, the description covers purpose, permissions, authentication, body expectations, and parameter passing. It does not describe return values or errors, but the raw REST proxy framing supplies enough context for a straightforward DELETE 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining top-level fields and camelCase/snake_case aliases, but it does not clarify which parameter is a path vs query parameter or provide format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource and action: remove a link share via DELETE /projects/{project}/shares/{share}. This clearly distinguishes it from project-deletion siblings by specifying the share-link resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it (removing link shares) and states the write-access prerequisite, but it does not explicitly compare against alternatives or say when not to use it. Guidance is present but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that authentication is required, that no request body is usually needed, and that the action is a true deletion rather than a status change. It does not elaborate on permanence or side effects, but the core behavioral traits are well covered.
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 tight and front-loaded with the core purpose ('Delete a task'). Subsequent sentences add non-redundant details about the endpoint, body, aliases, and authentication. No filler or repetition, though the density is slightly high.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with no output schema and no annotations, the description covers the operation, auth, body expectation, and alias conventions. It stops short of describing return values or error handling, but those are minor for this proxy tool, and the description is sufficiently complete for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, so the baseline is 3. The description adds value by explaining that path and query parameters are top-level fields and that original parameter names also accept camelCase and snake_case aliases, which aids correct invocation beyond the schema's 'Task ID Required'.
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?
Description opens with 'Delete a task' and elaborates 'Deletes a task from a project', clearly specifying the verb and resource. It also distinguishes deletion from marking a task done. However, it doesn't differentiate among the many similarly named vk_delete_tasks_* siblings or vikunja_delete_task, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual details like 'Raw Vikunja REST proxy for DELETE /tasks/{id}' and clarifies that 'This does not mean mark it done'. It also explains that path/query parameters are top-level fields and aliases are accepted. However, there is no explicit guidance on when to choose this raw proxy over alternatives like vikunja_delete_task or other deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the conditional return format (buckets for kanban views, tasks otherwise), notes that no request body is usually required, mentions parameter aliases, and states authentication is required. This is substantive behavior disclosure beyond the minimal, though it omits error responses and rate limits.
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 concise and front-loaded, starting with the core action 'Get tasks in a project.' Each sentence adds relevant information: endpoint, return behavior, request body, parameter style, and authentication. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 16 parameters and no output schema, so the description needs to compensate for the missing response structure. It does explain the primary return types (buckets vs. tasks) but does not describe the shape of task objects, pagination details, or error scenarios. This leaves gaps for a raw proxy with this parameter count.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that path and query parameters are top-level fields and that camelCase/snake_case aliases are accepted, which clarifies how to pass parameters. This is useful meta-information beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get tasks in a project' and specifies the exact REST endpoint, making the verb and resource unambiguous. However, it does not explicitly distinguish itself from the many sibling tools that also fetch tasks (e.g., vikunja_list_tasks, vk_get_tasks_*), so it lacks direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Raw Vikunja REST proxy' and notes that authentication is required, which gives some context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or preferred scenarios compared to higher-level task-fetching siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses authentication requirements and that this is a GET without a usual request body, which is useful. However, it does not mention whether the operation is read-only, pagination behavior, or any side effects, falling short of full 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 fairly brief and front-loaded with the purpose. However, there is a minor grammatical run-on ('...for a given project This endpoint...') that slightly reduces clarity, but it remains compact and free of filler.
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 5 parameters, no output schema, and no annotations, the description covers the endpoint, authentication, and parameter aliases, but it does not provide details on link share response structure or clarify required parameters (schema marks project as 'Required' but no required list). It is adequate for invocation but leaves gaps for a fully self-sufficient agent.
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 already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful value by explaining that path/query parameters are top-level fields and that camelCase and snake_case aliases are accepted (e.g., perPage/per_page), which helps agents construct calls correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action 'Get all link shares for a project' and names the exact REST endpoint (GET /projects/{project}/shares), clearly distinguishing it from sibling tools like vikunja_get_project or other vk_get_projects_* proxies. This satisfies the verb+resource+scope criterion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context as a 'Raw Vikunja REST proxy' and notes that a request body is usually not required, but it does not explicitly state when to choose this tool over alternatives or list exclusions. It implies usage for fetching link shares, but there is no direct when-to-use guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it is a raw proxy, lists users without email addresses, supports aliases, and requires authentication, providing helpful 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 slightly rambling but each sentence adds useful information. It is concise enough and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool without output schema, the description covers the endpoint, purpose, search capability, authentication, and parameter handling, making it fairly complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that parameters are top-level fields and that camelCase/snake_case aliases are accepted, which is information not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets project users via GET /projects/{id}/projectusers, which is specific. It doesn't explicitly distinguish from siblings but the endpoint is unique and the resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (list all project users, optionally search) and notes that authentication is required and no request body is usually needed, but it does not mention alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and adds useful behavioral context: authentication is required, request body is usually not needed, parameters are top-level fields, and camelCase/snake_case aliases are accepted. This goes beyond what the schema discloses.
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 short and front-loaded with the primary purpose. However, the phrase 'Get all projects a user has access to' is repeated, which is slightly redundant but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 optional parameters, no output schema, and no annotations, the description covers key aspects: purpose, raw proxy nature, authentication, request body, and parameter handling. It does not describe return structure, but 'Returns all projects a user has access to' gives a high-level expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds meaning by explaining that path/query parameters are top-level fields and that parameter names accept both camelCase and snake_case aliases, which is not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Get all projects a user has access to,' and identifies the tool as a 'Raw Vikunja REST proxy for GET /projects,' providing a specific resource and scope. It does not explicitly differentiate from other vk_get_projects_* siblings, but the raw proxy context offers some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Raw Vikunja REST proxy' and mentions authentication and lack of request body, but it does not explicitly state when to use this tool over alternatives or provide exclusions. No sibling tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals authentication requirements, the HTTP method, the raw proxy nature, and parameter alias conventions, which are all useful operational details. It omits response specifics but still provides substantial 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 relatively concise at six sentences, and the primary purpose is front-loaded. Some boilerplate about path/query parameters may be irrelevant for this endpoint, slightly reducing structural efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, so the description covers the essential aspects: purpose, endpoint, body handling, and auth. However, it does not differentiate from the similarly named vk_post_notifica_c728b00fdf22 sibling nor describe the response format, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the single body parameter as an optional JSON payload. The description adds meaningful detail about top-level fields and camelCase/snake_case aliases, going beyond the schema's basic description and enriching parameter understanding.
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 tool marks all notifications of a user as read, using the specific endpoint POST /notifications. This makes the tool's function unambiguous and distinguishes it from sibling tools that perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It mentions it is a raw REST proxy, but provides no exclusion criteria or alternative tool names, leaving usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: authentication is required, the user needs write access, the payload goes in an optional body field, and parameters support camelCase/snake_case aliases. This is strong coverage for a raw proxy, though it omits return format or error handling.
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 mostly concise and front-loaded, but it repeats 'Update an existing task comment' twice. Minor redundancy, yet overall efficient and easy to scan.
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 raw proxy with no annotations or output schema, the description provides some essential context (auth, access level, parameter style), but it does not specify what fields the body payload should contain, what the response looks like, or error conditions. This leaves gaps for an agent needing to construct a valid update request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful usage context: 'Pass the JSON request payload in the optional body field' and 'Path and query parameters are top-level fields.' It also clarifies that aliases are accepted, which is not evident from the schema alone.
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 'Update an existing task comment' and identifies the exact REST endpoint POST /tasks/{taskID}/comments/{commentID}. This distinguishes it from sibling tools like vikunja_create_task_comment and vikunja_list_task_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions preconditions like write access and authentication, but does not contrast with create/list/delete comment tools or state when this tool is inappropriate.
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?
The description discloses that the operation changes settings and requires authentication, but it does not discuss side effects, reversibility, or specific permission needs. Additionally, it describes the body as 'optional' while the input schema marks it required, creating an inconsistency that undermines 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 concise at three sentences, with the main purpose front-loaded. However, the typo 'current user..' and the inaccurate 'optional body' wording detract slightly from quality.
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 there is no output schema and no annotations, the description provides reasonable context for a simple settings update operation. It lacks details on return values or failure modes, and the body optionality inconsistency creates a gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'body' parameter with 100% coverage, so the baseline is 3. The description adds value by specifying the body should contain the JSON request payload and mentions camelCase/snake_case aliases and top-level path/query parameters, which helps in constructing requests.
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 tool changes general user settings for the current user, using a specific verb and resource. It also identifies the underlying REST endpoint, which distinguishes it from other user-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear invocation context: it identifies as a raw Vikunja REST proxy for POST /user/settings/general, explains how to pass the JSON body, and notes authentication is required. However, it does not explicitly mention alternatives or exclusion criteria, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully notes that authentication is required and that the tool does nothing if the reaction already exists (idempotency). However, it does not mention response format, error behavior, or any side effects beyond the mutation. The claim that the body is 'optional' contradicts the schema requirement, which is a minor transparency issue.
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 repeats 'Add a reaction to an entity.' verbatim as the first and third sentences, which is redundant waste. The remaining information is useful but could be condensed into a tighter paragraph. Wasteful repetition prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple proxy tool with three parameters and no output schema, the description is fairly complete. It covers purpose, idempotency, authentication, and how to pass parameters. Minor gaps include absence of error scenarios and the optional-body inconsistency, but the core usage is well specified.
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%, so the schema already documents all three parameters. The description adds value by clarifying how to pass parameters (body payload, top-level fields, camelCase/snake_case aliases), but it incorrectly labels the body as optional when the schema marks it required. This mixed contribution keeps the score at baseline.
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 tool adds a reaction to an entity and provides the exact REST endpoint (PUT /{kind}/{id}/reactions). This is a specific verb+resource that distinguishes it from the many sibling tools, especially those with generic 'kind' names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it explains that the JSON request payload goes in the body field, path/query parameters are top-level, and parameter aliases are accepted. It does not explicitly mention alternatives, but the purpose is specific enough that 'when to use' is unambiguous. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions auth and permission constraints, which helps, but it also falsely claims the body field is optional while the schema marks it as required. This misleading statement could cause incorrect invocation. It also omits idempotency/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, but it repeats 'Adds a new assignee to a task' twice, which is redundant. Still, it is efficient overall and covers essential information without excessive length.
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 raw proxy with no output schema, the description covers key aspects (operation, prerequisites, auth, parameter handling). Gaps include the incorrect 'optional body' claim and no mention of error cases or return format, though the raw proxy nature implies the endpoint's response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by explaining that path/query parameters are top-level fields and that camelCase/snake_case aliases are accepted, which is beyond the schema. The 'optional body' error slightly detracts, but the additional guidance is meaningful.
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 (add a new assignee) and the specific resource (task) via both natural language and the explicit REST endpoint 'PUT /tasks/{taskID}/assignees'. This distinguishes it from sibling tools for other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for use: prerequisites (assignee needs project access, doer must be able to edit), required authentication, and parameter passing conventions. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description compensates by disclosing authentication requirements, write access needs, and parameter conventions (top-level fields, alias support). It does not cover return values or idempotency, but the provided behavioral details are substantial.
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 front-loads the purpose but repeats 'Create a new task comment' twice. It is relatively short, yet the redundancy is unnecessary and could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers essential context: endpoint, auth, permissions, parameter passing, and aliases. It lacks detail about the comment object structure and omits error/return information, but these are largely beyond the description's scope since schema does not provide them either.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful parameter handling details (camelCase/snake_case aliases and top-level fields) beyond the schema. However, it misleadingly calls the body field 'optional' when the input schema marks it required, creating confusion and undermining the added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new task comment' and specifies the exact endpoint 'PUT /tasks/{taskID}/comments'. This distinguishes it from other task-related tools and leaves no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the prerequisite of write access and identifies itself as a 'raw Vikunja REST proxy', implying use for direct REST calls. However, it does not explicitly compare with high-level alternatives like vikunja_create_task_comment, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions optional search, filtering, sorting, and expansions, but does not explain pagination behavior, the implications of expansions on response size, or explicitly state that this is a read-only operation. This is a minimal but acceptable disclosure for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and then lists optional capabilities. Every word earns its place, with no redundancy or filler.
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 no output schema, so the description should compensate by explaining return behavior. It does not mention pagination, response structure, or potential performance implications of expansions. However, the tool is a straightforward listing operation, and the optional parameters are well-documented in the schema, making the description adequate but not 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 provides 100% parameter description coverage, including details for each parameter. The description adds only a high-level mention of search, filtering, sorting, and expansions, which does not exceed the schema's own explanations. Thus, the baseline 3 is appropriate.
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 tool lists tasks across all accessible projects, distinguishing it from single-task tools like vikunja_get_task and other list tools like vikunja_list_projects. The verb 'list' and resource 'tasks' are specific, and the scope is explicitly broad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'across all accessible projects' gives clear context for when to use this tool—when you need a broad, cross-project task listing. However, it does not explicitly mention alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful details: authentication is required, the operation targets the current user, path/query parameters are top-level fields, camelCase and snake_case aliases are accepted, and no request body is usually needed. It stops short of disclosing response behavior or idempotency, but the disclosed traits go well beyond a bare statement like 'Deletes a subscription'.
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 compact but contains redundancy: 'Unsubscribe the current user from an entity.' and 'Unsubscribes the current user to an entity.' convey the same idea, with the second having a grammatical error. The remaining sentences are useful and front-loaded, but the duplicate sentence prevents a higher score.
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 deletion-style operation, the description covers key operational aspects: endpoint, authentication, parameter mapping, and body expectations. However, it does not explain what the response will be (no output schema exists), and the phrase 'does not usually require a request body' leaves ambiguity. It also doesn't address the fact that schema properties are described as required while the schema itself lists zero required parameters, which could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that parameters are top-level path/query fields and that both camelCase and snake_case aliases for the same original parameter are accepted, which clarifies the schema's three separate properties for 'entityID', 'entityId', and 'entity_id'. It also notes that no request body is usually required, which informs how parameters should be supplied.
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 tool unsubscribes the current user from an entity, and explicitly maps to the DELETE /subscriptions/{entity}/{entityID} endpoint. This distinguishes it from sibling delete tools like vk_delete_projects or vk_delete_tasks, which target different resources. The verb 'unsubscribe' is specific and accurate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case (unsubscribing from an entity) and notes that the endpoint does not usually require a request body, which is a helpful usage nuance. However, it does not explicitly state when to prefer this over alternatives, nor does it mention when not to use it (e.g., if the user is not subscribed). The 'Raw REST proxy' line gives context but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full transparency burden. It discloses authentication, the absence of a typical request body, and parameter alias conventions. However, it does not state the irreversible nature of the deletion or what happens on success/failure, leaving room for uncertainty.
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 four sentences, front-loaded with the core purpose, and every sentence provides useful operational detail (endpoint, body, params, auth). It is slightly wordy but each clause earns its place, earning a score above average but not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter delete endpoint, the description covers purpose, endpoint, request body, parameter handling, and authentication. It lacks return value/error info, but given there is no output schema and complexity is low, the description is nearly complete. A 4 reflects that it could mention deletion effects but is otherwise solid.
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 documents the single 'id' parameter with 100% coverage. The description adds that path/query parameters are top-level and that camelCase/snake_case aliases are accepted, which is helpful but not essential. It does not significantly enhance the meaning of the id itself beyond the schema's 'Token ID Required'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete a caldav token by id,' which is a specific verb-resource pair. It further identifies the exact REST endpoint (DELETE /user/settings/token/caldav/{id}), making it unambiguous and distinct from the many sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: as a raw REST proxy for deleting a caldav token. It notes that no request body is usually needed and mentions auth requirements, but does not explicitly name alternative tools or exclusions. That fits 'clear context, no exclusions' (score 4).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses important behaviors: the thumbnail is cropped to max 200px width, errors return JSON, authentication is required, and parameter aliases (camelCase/snake_case) are accepted. Missing details about success response format but still strong coverage.
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 mostly concise but repeats 'Get an unsplash thumbnail image' verbatim at the beginning and later. This redundancy could be trimmed without losing information. The structure is otherwise front-loaded with purpose and then details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the endpoint, cropping behavior, error format, and auth. However, it does not describe what a successful response contains (e.g., image binary content type), and the schema marks the parameter as not required while its property description says 'Required', which is inconsistent and could confuse the agent.
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 schema already describes the 'image' parameter as 'Unsplash Image ID Required' (100% coverage). The description adds extra semantic value by explaining that path/query parameters are top-level and that camelCase/snake_case aliases are accepted, which is beyond the schema. It doesn't clarify the boolean/number types in the schema, but the core meaning is well covered.
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 'Get an unsplash thumbnail image' and specifies the exact REST endpoint ('GET /backgrounds/unsplash/image/{image}/thumb'), which distinguishes it from sibling background tools. The verb 'Get' and resource 'unsplash thumbnail image' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context such as 'Raw Vikunja REST proxy' and notes that 'This endpoint does not usually require a request body'. However, it does not explicitly mention when to use this tool versus alternatives like other background getters, nor does it state exclusions or prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It covers authentication requirements, the usual lack of a request body, and parameter alias conventions. However, it does not mention response format, error behavior, or side effects; these omissions are partially mitigated because this is a simple GET status endpoint.
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 composed of several short, information-dense sentences, with the core action front-loaded. Some boilerplate about parameter aliases adds length but still conveys useful proxy-specific behavior; there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET status check, the description adequately covers purpose, exact endpoint, authentication, and request-body expectations. Since no output schema exists, some return-format detail is missing, but the simple nature of the operation makes this level of completeness acceptable.
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 zero properties, so the baseline is 4. The description adds relevant context beyond the empty schema by explaining that path/query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Get CSV migration status' and identifies the exact endpoint 'GET /migration/csv/status' plus return semantics. This clearly distinguishes it from the many vk_get_migratio_* sibling tools by specifying 'CSV' and the exact resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—call when needing to know if the current user has completed CSV migration—but it provides no explicit comparison to sibling migration tools or when-not-to-use guidance. The context is clear but not accompanied by exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, that a request body is usually not needed, and that parameters accept aliases. However, it doesn't explicitly state that the tool is read-only (though the GET method implies it) or describe error handling or return format details, leaving some gaps.
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 compact and front-loaded, with the core purpose in the first sentence. There is minor redundancy between 'Gets one project' and 'Returns a project by its ID,' but overall every sentence contributes useful information. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is fairly complete. It covers purpose, HTTP method, authentication, parameter handling, and return value. It does not mention alternatives or error responses, but for a straightforward GET proxy, the provided details are sufficient for an agent to invoke it 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 already fully documents the single 'id' parameter with a description, so as per the rubric, the baseline is 3. The description adds notes about top-level parameters and camelCase/snake_case aliases, which provides some extra context but doesn't significantly deepen the understanding of the 'id' parameter itself.
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 tool's function with a specific verb and resource: 'Gets one project.' It also names the exact REST endpoint 'GET /projects/{id}', which distinguishes it from list, create, delete, and update project tools. This provides unambiguous purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool: to fetch a single project by its ID. It also notes that authentication is required and explains parameter naming conventions. It does not explicitly name alternatives or exclusions, but the 'one project' scope effectively differentiates it from list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses authentication requirements, the 'no request body' expectation, and parameter naming conventions, but it does not describe the return format, error behavior, or whether the operation is safe/read-only beyond the implied 'Get'.
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 compact and front-loaded with the primary action. Each sentence adds meaningful information—endpoint, behavior, parameter style, aliases, and authentication—without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple proxy tool but has gaps: no output schema or annotations are present, and the description does not explain the response structure, pagination behavior, or potential error cases. It covers the essentials but lacks deeper context.
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?
Input schema covers all 5 parameters with descriptions, so the baseline is 3. The description adds valuable meaning by explaining that parameters are top-level fields and that original names accept camelCase and snake_case aliases, which supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get teams on a project' and specifies the exact REST endpoint 'GET /projects/{id}/teams'. This clearly identifies the operation as retrieving team access for a given project, distinguishing it from other project-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context about being a raw REST proxy and that authentication is required, but it does not explicitly state when to prefer this tool over alternatives like other project getters. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions authentication is required, that a request body is usually not needed, and that parameters are top-level with alias support. However, it does not explicitly confirm the read-only nature, response format, pagination behavior, or error handling, leaving notable gaps.
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 compact and front-loaded, starting with the core purpose and then adding relevant specifics about request body, parameter formats, aliases, and authentication. There is slight redundancy between 'Get tasks' and 'Raw Vikunja REST proxy for GET /tasks,' but overall it is efficient and every sentence adds useful information.
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 14 parameters, no output schema, and no annotations, the description should explain the return shape, pagination behavior, and potential errors. It omits all of these, instead focusing on request mechanics. This makes the description incomplete for the tool's complexity and leaves the agent without guidance on interpreting the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a strong baseline. The description adds important semantic value by clarifying that path and query parameters are top-level fields and that original names accept camelCase and snake_case aliases, which goes beyond the schema's individual parameter descriptions and helps the agent construct valid requests.
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 'Get tasks' and identifies itself as a raw proxy for the Vikunja GET /tasks endpoint, with the additional scope 'Returns all tasks on any project the user has access to.' This gives a specific verb, resource, and scope, distinguishing it from single-task or project-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: it is a raw REST proxy that returns all tasks across any accessible project, implying a comprehensive, cross-project listing scenario. It does not explicitly name alternatives or state exclusions, but the raw-proxy designation and scope give strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it is a raw proxy, requires authentication, usually does not require a request body, and that parameters are top-level fields accepting camelCase/snake_case aliases. This is solid coverage, though it omits pagination behavior specifics (which are in 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 concise and front-loaded with 'Get teams.' It provides four sentences, each adding specific information without redundancy. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET operation with all optional parameters documented in the schema and no output schema, the description is nearly complete. It covers purpose, scope, auth, and parameter behavior. It could mention the response format explicitly, but 'Returns all teams' implies it adequately.
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 schema covers 100% of parameter descriptions, so the baseline is 3. The description adds meaningful guidance on how parameters should be passed (top-level fields) and the alias convention (camelCase and snake_case), which is valuable beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool gets teams and returns all teams the current user is a member of, with the specific resource 'GET /teams'. However, there is another vk_get_teams tool in the sibling list, and this description does not differentiate between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching teams as a raw REST proxy, but provides no explicit guidance on when to prefer this over alternatives. It does not mention when not to use it or how it relates to other team-fetching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does carry the burden and does disclose useful behavior: raw proxy pass-through, auth required, no request body usually, top-level path/query params with camelCase/snake_case aliases. However, it omits return format (binary/image vs JSON), exact semantics of 'usually', and any side-effect/error behavior, so transparency is only partially met.
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?
Description is front-loaded with the endpoint and purpose, using four short sentences. The 'path and query parameters' and alias sentences are generic boilerplate that could be trimmed for a zero-parameter tool, but overall it is compact and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, parameterless GET proxy, the description covers endpoint, purpose, auth, and body expectations. No output schema exists, so the agent still lacks a precise return format specification, but the description gives enough operational context for a simple QR-code retrieval.
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 schema has zero parameters and 100% coverage, so the baseline is 4. The description's generic note about top-level fields and aliases adds little specific meaning but does not conflict with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Totp QR Code' and explicitly maps to 'GET /user/settings/totp/qrcode', stating it 'Returns a qr code for easier setup at end user's devices.' This is a specific verb+resource+scope that clearly separates it from the many sibling vk_get_user_* and other Vikunja endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied context ('for easier setup at end user's devices') and operational notes (auth required, no request body usually), but it never explicitly says when to choose this tool over an alternative or explains differences among sibling user endpoints. No exclusions or alternative tool names are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses the raw proxy nature and authentication requirement, but does not explain side effects like whether existing data is overwritten, response format, or idempotence. It is adequate but somewhat limited for a mutation/import operation.
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 starts with a clear purpose and is reasonably detailed, but it contains redundancy by repeating the import concept in the first two sentences and a typo ('Vikunjda'). It could be tightened without losing information.
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 one-parameter import proxy with no output schema, the description covers the endpoint, authentication, and form structure well. However, it omits return/result behavior and potential error cases, making it adequate but not fully 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?
Schema coverage is 100%, so the baseline is 3. The description adds valuable semantics beyond the schema: the file object shape (filename, contentBase64, contentType), multi-file arrays, camelCase/snake_case aliases, and path/query parameter handling, which help the agent construct correct input.
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 tool's purpose with a specific action and resource: "Import all projects, tasks etc. from a Vikunja data export" and gives the exact endpoint (/migration/vikunja-file/migrate). This distinguishes it from other CRUD and migration sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: importing a Vikunja data export via multipart form data, and explicitly notes that authentication is required. However, it does not mention alternative migration endpoints or when not to use this tool, leaving exclusions unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses atomicity, the writable constraint, authentication needs, and parameter passing conventions (body, path/query, aliases). It does not mention return values or error behavior, but the added context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. There is slight redundancy ('Update multiple tasks' appears twice conceptually), but each sentence adds useful detail. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers request construction, authentication, atomicity, and permission requirements, which is good for a low-level proxy. However, with no output schema, it omits return-value semantics and does not explain the structure of the bulk payload beyond 'JSON request payload'. These gaps prevent full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one 'body' property with a vague description, and the description attempts to add meaning by explaining body, path/query parameters, and aliases. However, it contradicts the schema by calling body 'optional' while schema requires it, and suggests top-level fields that additionalProperties=false disallows. This is confusing and harms usability.
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 'Update multiple tasks' and identifies the exact REST endpoint 'POST /tasks/bulk', making the tool's purpose unmistakable. This differentiates it from sibling tools like vikunja_update_task (single task) and other vk_post_tasks_* that create tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use for multiple tasks atomically, requires user-writable tasks, and authentication is required. It implies 'when you need to update more than one task' but does not explicitly mention alternatives or when not to use, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that authentication is required, that it is a raw proxy, and mentions alias handling. It does not detail side effects or response format, but the action and auth requirement are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose, but it contains slight redundancy between 'Update email address' and 'Lets the current user change their email address,' plus generic proxy boilerplate that adds length without much unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, it covers purpose, auth, and body passing, but the misleading 'optional' and phantom path/query parameters create a completeness gap. With no output schema, return-value details are not required, but accurate invocation guidance is essential and partially flawed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'body' parameter at 100% coverage, but the description actively misleads by calling the body field 'optional' when it is required, and by referencing path/query parameters that do not exist in the schema. This could cause incorrect invocation, outweighing any value from alias notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Update email address') and elaborates with 'Lets the current user change their email address.' This clearly distinguishes it from the many sibling user-related tools by focusing on the email-specific operation and the exact REST endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use: when the current user needs to change their email address. However, it does not explicitly mention alternatives or exclusion cases, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does mention authentication, raw proxy behavior, and parameter placement, which is helpful. However, it does not disclose effects like whether existing events are replaced or merged, nor does it mention response format or error behavior.
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 clear but somewhat repetitive, with 'Update a user-level webhook target' stated twice. It contains several useful details, but could be tightened by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple proxy tool with two parameters and no output schema, the description covers purpose, auth, body handling, and parameter placement. However, it does not specify the structure of the JSON body for updating events, and it omits any indication of what the response will contain, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the description adds value by explaining how to pass the JSON body ('Pass the JSON request payload in the optional body field'), that path/query parameters are top-level, and that aliases for camelCase and snake_case are accepted. This goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update a user-level webhook target' and 'Update the events for a user-level webhook target'. The verb is specific, the resource is identified, and it is distinct from sibling tools that list webhooks or operate on other Vikunja resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is a raw Vikunja REST proxy for a specific endpoint, and it indicates authentication is required. However, it does not explicitly state when NOT to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that it creates an initial DB setup, requires authentication, and is a raw proxy. However, it does not state idempotency, whether existing TOTP settings are overwritten, or what the response looks like. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences and front-loads the main purpose. Each sentence provides useful context: proxy endpoint, DB setup, next step, body field, aliases, auth. It is slightly wordy but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter proxy without output schema or annotations, the description is reasonably complete. It explains the two-step TOTP flow, clarifies the body field, and notes authentication. The confusing path/query statement and lack of response details prevent a perfect score, but it is sufficient for an agent to invoke 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 coverage is 100% (only optional 'body' property). The description repeats that the body is an optional JSON payload, which is already in the schema. It also mentions path/query parameter aliases, but no such parameters exist in the schema, so this adds confusion rather than clarity. No additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: 'Enroll a user into totp.' It specifies the exact endpoint (POST /user/settings/totp/enroll) and distinguishes this step from the subsequent 'enable totp' endpoint, making it unambiguous among the many vk_post_user_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear usage sequence: enroll first, then verify via the 'enable totp' endpoint. This implicitly tells the agent when to use this tool. It does not explicitly mention alternatives or exclusions, but the step-by-step context is strong enough for a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses authentication requirements, the return content (detected columns, delimiter, etc.), and behavioral conventions like parameter aliases and top-level path/query fields. This is more transparent than many raw proxies, though it does not explicitly state non-mutating behavior or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, leading with a concise purpose statement followed by technical usage details. Some redundancy exists ('Detect CSV structure' and 'Analyzes a CSV file...' overlap), and the 'Form fields: import' line repeats schema info, but overall every sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains what the tool returns (auto-detected columns, delimiter, quote character, date format). It gives sufficient input context with the multipart form details and auth note. For a one-parameter tool with nested objects, this is nearly complete, though exact response structure or common error cases are not mentioned.
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 covers the single 'form' parameter with 100% description coverage, including the required 'import' file and its object shape. The description adds little new parameter meaning beyond repeating the required field, though it does contextualize the general proxy parameter rules. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Detect CSV structure' and specifies the exact endpoint 'PUT /migration/csv/detect'. It clearly states the tool's function: analyzing a CSV file to return auto-detected columns, delimiter, quote character, and date format. This distinguishes it from sibling migration tools by naming the specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when CSV structure detection is needed) but does not explicitly contrast it with alternatives among the many sibling tools. It provides invocation details (multipart form data, required import field) but lacks explicit 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It discloses that authentication is required and describes multipart form data handling, but it does not mention response format, idempotency, or side effects like overwriting an existing background. This is moderate transparency but not comprehensive.
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 short and front-loaded, but it redundantly repeats 'Upload a project background' twice at the beginning. This unnecessary repetition makes it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values and side effects. It adequately covers input details and authentication, but omits what the response looks like, whether it overwrites existing backgrounds, and prerequisites like project existence. This leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining aliases (camelCase/snake_case), top-level path/query parameters, and multi-file arrays—details not fully present in the schema. However, it repeats some schema info about file object shape, so not a 5.
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 'Upload a project background' and explicitly names the REST endpoint PUT /projects/{id}/backgrounds/upload, which distinguishes it from sibling vk_put_projects_* tools. The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: it is for uploading a project background via multipart form data. It also explains parameter handling (aliases, top-level fields) but does not explicitly mention alternatives or when not to use, so it misses the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a side effect: 'This will also set the user's avatar provider to upload', and states authentication is required. It also explains the multipart form input format and alias conventions. However, it omits response behavior and error cases, which would be helpful but are not strictly required for a raw proxy.
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 information-dense but contains redundancy, repeating 'Upload a user avatar' twice. It also has a run-on sentence with missing punctuation: 'This will also set the user's avatar provider to "upload" Pass multipart form data in the form field.' While not overly long, it could be more concise and better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description thoroughly covers input format, side effects, and authentication, but does not mention the response format or failure behavior. For a raw proxy, 'Raw Vikunja REST proxy' may imply a raw response, but this is not explicit. It is adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter 'form' with a detailed description. The tool description adds extra meaning by noting that 'Path and query parameters are top-level fields' and 'Original parameter names also accept camelCase and snake_case aliases', which are not in the schema. This goes beyond the baseline of 3 provided by 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 opens with 'Upload a user avatar' and explicitly identifies the raw REST proxy endpoint 'PUT /user/settings/avatar/upload'. This gives a specific verb and resource, and the mention of the endpoint clearly distinguishes this tool from sibling vk_put_user_* tools that target other endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the endpoint and purpose, but it does not explicitly mention alternatives or when not to use this tool. For example, it lacks a note like 'Use this instead of updating the avatar URL' or any comparison with sibling user tools. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' implies a read-only operation, and 'authenticated' indicates the need for valid credentials. However, it does not disclose additional behavioral traits such as error conditions, response shape, or authentication specifics beyond what the name implies.
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, well-formed sentence with no unnecessary words. It front-loads the action ('Get') and includes relevant context ('authenticated', 'configured credentials') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently states what it does. However, it could be more specific about the exact fields or settings included in the returned object, though this is minor for a zero-parameter getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds no parameter-specific meaning because there are none to describe. It does hint at the output (profile and settings), but the schema is empty, so this dimension is not a concern.
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 tool retrieves the authenticated user's profile and settings, which is a specific verb+resource pairing. The name 'current_user' and the qualifier 'for the configured credentials' distinguish it from other user-related endpoints in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the current authenticated user, but it does not explicitly state when to avoid alternative user-listing tools or provide exclusions. Without explicit alternatives, the guidance remains implicit rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'get' indicates a read-only operation, and there are no obvious side effects. However, the description does not address behaviors like error handling, permissions, or response format. For a simple retrieval, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence ('Get a single project by ID.') that is front-loaded and contains no wasted words. It perfectly balances brevity and informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one parameter and no output schema. The description sufficiently explains what the tool does and how to invoke it (pass a project ID). While it omits details like return structure or not-found behavior, these are not critical for selection and invocation given the simplicity of the 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 already describes `project_id` as 'Vikunja project ID.' with type and constraints, achieving 100% coverage. The description merely says 'by ID,' adding no additional meaning beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single project by ID' uses a specific verb ('get'), a clear resource ('project'), and a scoping condition ('by ID'). This precisely distinguishes it from siblings like vikunja_list_projects, which retrieves multiple projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: when you need exactly one project and have its ID. It does not explicitly mention alternatives or exclusions, but the tool name and the presence of vikunja_list_projects make the context obvious. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behaviors: it requires authentication, usually has no request body, and parameters are top-level fields with camelCase/snake_case aliases. However, it does not mention permanence of deletion, potential side effects, or response format, leaving some behavioral gaps 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but contains redundancy: 'Delete a project view' appears twice. It is front-loaded with the key action, and the rest is information-dense, but the repetition is unnecessary and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool with no output schema, the description covers the endpoint, authentication, request body, and parameter handling. It lacks return-value details, but that is not critical for a delete operation. Overall, it provides sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes 'id' and 'project' with 'Required', the description adds semantic value by explaining parameter placement (top-level fields) and alias support (camelCase/snake_case), which are not evident from the schema. This helps the agent understand how to properly pass parameters.
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 'Delete a project view' with a specific verb and resource, and explicitly distinguishes from generic project deletion by specifying the endpoint 'DELETE /projects/{project}/views/{id}'. It clarifies the tool's scope as a raw proxy for this exact operation, separating it from sibling delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating the exact REST endpoint and the fact that this is a raw proxy, making the intended use obvious. It does not explicitly name alternatives or exclusions, but the endpoint specificity implies when to use this tool, especially among many similar proxy variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important side effects (revokes access via that team), a constraint (self-removal only if not the last user), that the endpoint usually needs no request body, and that authentication is required. It could mention admin permissions for removing others, but the provided behavioral context is substantive.
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 front-loads the purpose clearly, but repeats 'Remove a user from a team.' verbatim, adding unnecessary length. The rest of the sentences are useful, but the duplication is wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete operation with no output schema, the description covers purpose, side effects, parameter aliases, request body expectations, and auth. It leaves minor gaps (e.g., response format, permission to remove other users) but is generally 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?
Schema coverage is 100%, so baseline is 3, but the description adds value by noting that path and query parameters are top-level fields and that camelCase/snake_case aliases are accepted, which helps the agent construct calls correctly.
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 ('Remove a user from a team') and identifies the exact REST endpoint (DELETE /teams/{id}/members/{username}), making it distinct from sibling tools like vk_delete_teams_0bdccd633612 (deleting a team) and vk_delete_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use, and the description includes a self-removal condition ('if they are not the last user'), but it does not explicitly compare against alternatives or state when not to use. No explicit exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It adds useful behavioral details: authentication required, no request body typically needed, path/query parameters as top-level fields, and camelCase/snake_case aliases. However, it omits error handling, response format, or behavior for missing/invalid IDs, which limits completeness.
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 four sentences, front-loaded with the core purpose, and every sentence adds value—REST endpoint, return, request body, parameter style, and auth. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects, no output schema), the description covers the key operational aspects: what it does, how parameters are passed, auth requirement, and naming aliases. It could add error behavior or return value detail, but for a simple GET proxy, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'id' as 'Label ID Required' with 100% coverage, so the baseline is 3. The description adds meaning beyond the schema by clarifying parameter passing conventions (top-level fields, camelCase/snake_case aliases) and that no request body is usually required, which helps the agent invoke the tool correctly.
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 tool 'Gets one label' and specifies the raw Vikunja REST proxy for GET /labels/{id}, distinguishing it from list operations by emphasizing retrieval by ID. This is a specific verb+resource pair that leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a single label ID is known ('Returns one label by its ID') but does not explicitly contrast with alternatives like the sibling 'vikunja_list_labels' for fetching all labels. It provides no when-not-to-use or alternative guidance, only implicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that authentication is required, the endpoint does not usually require a request body, and the parameter alias behavior. These are useful behavioral details beyond the schema, though response format and error handling are not covered.
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 front-loaded with a clear first sentence, but the same sentence is repeated verbatim ('Get all api webhook targets for the specified project.'), which is redundant and costs conciseness. The rest is efficient, but the duplication prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET endpoint with four parameters and no output schema, the description covers most necessary context: purpose, auth requirement, body expectations, and parameter handling. It does not describe return shape, but the outcome (webhook targets) is implied, making it adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds valuable context by noting that path and query parameters are top-level fields and that camelCase and snake_case aliases are accepted, which is not evident from the schema alone.
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 'Get all api webhook targets for the specified project' with a specific verb and resource, and differentiates from sibling project tools by specifying webhooks. The explicit mapping to GET /projects/{id}/webhooks further removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when webhook targets are needed and gives helpful instructions on parameter placement and aliases, but it does not explicitly compare to alternatives or state when not to use this tool. The usage context is clear but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose several behavioral aspects: authentication is required, the endpoint usually does not require a body, path/query parameters are top-level fields, and name aliases are accepted. However, it does not mention error handling, response format, or pagination, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly front-loaded with the purpose, but it contains redundancy: 'Get all project views for a project' is repeated in 'Returns all project views for a sepcific project.' It also includes a typo. The extra details are useful but could be tightened to remove repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool with one parameter and no output schema, the description covers the core aspects: purpose, endpoint, authentication, body requirement, and parameter behavior. It is sufficiently complete for an agent to invoke it correctly, though the lack of an output schema means return details are only partially explained.
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 schema already describes the 'project' parameter as 'Project ID Required.' (100% coverage), so the baseline is 3. The description adds value by explaining that path and query parameters are top-level fields and that camelCase/snake_case aliases are accepted, providing extra semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all project views for a project', using a specific verb and resource, and explicitly identifies the REST endpoint. This distinguishes it from sibling tools like vikunja_get_project and other vk_get_projects_* variants that target different project operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is a raw proxy for GET /projects/{project}/views, indicating when to use it (when project views are needed). It also notes that a request body is usually not required, but does not explicitly mention alternatives or exclusions, so it lacks the full 'when-not' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions authentication is required, that path/query parameters are top-level fields, accepts camelCase/snake_case aliases, and does not usually require a request body. This provides meaningful operational context beyond a simple GET, though it omits details about response format or error handling.
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 four sentences, front-loaded with the core purpose ('Gets one team'), and every sentence adds useful context: the REST endpoint, the ID-based retrieval, body requirement, parameter naming aliases, and authentication. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter GET with no output schema, the description is largely complete. It covers the operation, auth requirement, parameter style, and body expectations. It stops short of detailing response structure or failure modes, but given the tool's simplicity and the absence of an output schema, this is a minor gap.
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 describes the 'id' parameter as 'Team ID Required.' with 100% coverage. The description reinforces that the tool returns a team by ID but adds little new semantic meaning. It does mention aliases for parameter names, which is a minor addition, but the core parameter meaning is already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Gets one team' and 'Returns a team by its ID', specifying the verb and resource. It also identifies the underlying REST endpoint (GET /teams/{id}), making the tool's purpose unambiguous and distinct from list/delete/create operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when retrieving a single team by ID) but does not explicitly compare it to sibling tools or state exclusions. It adds a few usage notes like 'This endpoint does not usually require a request body' and mentions authentication, but lacks clear alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It does state that authentication is required, that a request body is not usually needed, and that parameter names accept camelCase/snake_case aliases. However, it does not explicitly mention that the operation is read-only (though GET implies it) or describe response structure/pagination, which are notable gaps given the lack of annotations.
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 four sentences and front-loaded with the primary purpose. It includes relevant technical details about request body and parameter aliases. There is some redundancy between the first and third sentences ('Get all api tokens' vs 'Returns all api tokens'), but overall it is concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more detail about the response and behavior. It states that all tokens are returned but does not describe the token object shape, pagination details, or error conditions. It is adequate for a simple list operation but lacks the completeness needed for a fully self-contained tool description.
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 provides descriptions for all parameters (100% coverage), giving a baseline of 3. The description adds valuable context by explaining that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which is not visible in the schema. This enhances the agent's ability to construct valid calls.
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 verb ('get') and resource ('all api tokens of the current user'), and explicitly identifies it as a raw proxy for GET /tokens. This distinguishes it from siblings like vk_delete_tokens and vk_put_tokens, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (to retrieve the current user's API tokens) and provides essential usage context such as authentication requirements and the absence of a typical request body. However, it does not explicitly name alternatives or provide exclusion criteria, though the GET semantics are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that authentication is required, notes the body is usually unnecessary, and describes the return fields (IDs and created dates). It doesn't explicitly call out read-only safety or rate limits, but the GET method and return description give reasonable transparency.
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 front-loaded with the main purpose, but it is wordy and repetitive: 'Returns the caldav tokens' and 'Return the IDs and created dates of all caldav tokens' convey the same information. It could be condensed to two clear sentences without losing any key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET tool, the description adequately covers the endpoint, return content, authentication requirement, and parameter style. It lacks a concrete response shape or error behavior, but the tool is simple enough that the description is nearly 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 has zero parameters, so the baseline is 4. However, the description includes generic boilerplate about path/query parameters and camelCase/snake_case aliases, which is misleading given the schema has no properties and additionalProperties is false. This generic guidance adds no real value and could confuse the agent.
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 it returns caldav tokens for the current user and specifies the exact REST endpoint (GET /user/settings/token/caldav). This distinguishes it from sibling user-related tools like vikunja_get_current_user by naming the precise resource and returned data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: it is a raw Vikunja REST proxy, usually requires no request body, path/query parameters are top-level fields, and authentication is required. It does not explicitly name alternatives or exclusions, but the context is sufficient for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that authentication is required, that this is a raw proxy, and that parameter names accept aliases. It also lists valid types. It could mention side effects or reversibility, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with several sentences, each providing useful information (valid types, proxy details, aliases, auth). There is minor redundancy in stating 'Set the user's avatar' and 'Changes the user avatar', but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and no output schema, so the description should explain how to construct the body. It lists valid types but not the expected key/structure within the body. The optional/required contradiction further reduces completeness. It does cover auth and aliases, so it is not severely incomplete.
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 has 100% coverage with a minimal body description, so the baseline is 3. The description adds meaning by stating the body is a JSON payload and enumerating valid types. However, it contradicts the schema by calling the body 'optional' when the schema marks it required, confusing the parameter's necessity.
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 tool 'sets the user's avatar' and identifies the exact raw endpoint POST /user/settings/avatar. It lists valid avatar types, making the purpose specific and distinguishing it from other user-related proxy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance: pass JSON in the body field, use camelCase/snake_case aliases, and authentication is required. It also explains the raw proxy nature. However, it does not explicitly name alternatives or when not to use this tool, but the endpoint-specific context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, explains parameter aliasing, and notes the payload is passed via body. However, it does not describe the response format or potential side effects like invalidating sessions, which would be useful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It explains the purpose, endpoint, payload usage, aliasing, and auth in four tight sentences. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no nested objects, so the description is nearly complete. It covers the proxy nature, authentication, aliases, and payload handling. The only missing piece is explicit details on the expected body fields or error responses, but given the simplicity, the description is strong.
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 has one required 'body' parameter with description 'The current and new password.' The description adds that the body should contain the JSON request payload but does not specify the exact structure (e.g., keys for current/new password). Since schema description coverage is 100%, the baseline of 3 is appropriate.
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 starts with 'Change password' and specifically identifies the endpoint POST /user/password, distinguishing it from sibling tools. It clearly states the tool lets the current user change their password, providing a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool (for the current user to change their password) and how to pass the payload (in the optional body field). However, it does not explicitly discuss alternatives or when not to use this tool, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully notes that authentication is required and explains parameter aliases and multipart formatting. However, it does not disclose important behavioral traits such as whether the import overwrites existing data, what happens on failure, or the response format.
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 front-loaded with the primary purpose and contains mostly relevant details. There is minor redundancy between the opening summary and the detailed import list, but overall every sentence earns its place and the structure is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a multipart upload with file objects and no output schema, the description covers request semantics well, including authentication and required fields. However, it omits any mention of the response or error behavior, and lacks guidance on distinguishing this from other migration endpoints, leaving some uncertainty for an agent.
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 schema already provides 100% coverage of the single 'form' parameter, so the baseline is 3. The description adds value by explaining file object shape (filename, contentBase64, contentType), multi-file arrays, camelCase/snake_case aliases, and that path/query parameters are top-level fields, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports WeKan board exports into Vikunja, enumerating specific content types (projects, tasks, labels, checklists, comments, attachments). It also names the exact REST endpoint (PUT /migration/wekan/migrate), distinguishing it from sibling migration and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is for WeKan board imports via a specific proxy endpoint, providing context on when to use it. However, it does not explicitly mention alternative migration tools or when not to use this one, stopping short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that no request body is usually required, that path/query parameters are top-level, that camelCase/snake_case aliases are accepted, and that authentication is required. This goes beyond the schema, though it stops short of describing response/error behavior.
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 front-loaded but contains redundancy: 'Removes a saved filter' is repeated as 'Removes a saved filter by its ID.' The raw proxy note and parameter details are useful, but the repetition makes it less concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description covers purpose, auth, and parameter mechanics. However, it lacks information about expected response/status codes and error behavior, which would be helpful given there is no output schema.
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?
While schema coverage is 100%, the description adds meaningful details about the id parameter: it is used in the path/query (not body), aliases are supported, and the endpoint usually expects no request body. This helps the agent correctly structure the call.
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 verb 'Removes' and the resource 'saved filter', and specifies deletion by ID. This distinguishes it from other vk_delete_* sibling tools and from filter get/post/put tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to delete a saved filter) and notes authentication requirements. It doesn't explicitly mention alternatives, but no alternative delete-filter tool exists among siblings, so exclusions are not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It includes important operational details: 'Authentication is required,' 'does not usually require a request body,' and the alias handling for parameter names. It does not describe the response format or error behavior, but covers the key invocation-relevant traits sufficiently.
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 compact and front-loaded with the core action, then follows with endpoint, usage notes, and authentication. Minor redundancy exists between 'Deletes an existing webhook target' and 'Delete any of the project's webhook targets,' but overall it is efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the essential points for invocation: what is deleted, the endpoint, that no request body is usually needed, top-level parameter placement, aliases, and authentication. It does not mention return values or post-deletion effects, but these are less critical for a simple delete operation. The description is sufficiently complete for an agent to select and 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 input schema already names all parameters (id, webhookID, webhookId, webhook_id) and marks required fields, so schema coverage is 100%. The description adds useful context about camelCase and snake_case aliases, but does not add per-parameter semantic detail beyond what the schema provides. This 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 tool deletes an existing webhook target, not a project, despite the misleading tool name. It specifies the exact REST endpoint (DELETE /projects/{id}/webhooks/{webhookID}), making the resource and action unambiguous. This differentiates it from sibling tools like vk_delete_projects_* that delete projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to delete any webhook target belonging to a project, and it explicitly notes this is a raw REST proxy. It does not explicitly name alternatives or exclusion cases, but the endpoint and resource scope make the intended usage obvious. This is strong but falls short of a full when-to-use/when-not-to-use guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that auth is not required, the endpoint returns specific fields, and parameter handling conventions. It does not mention error handling or rate limits, but for a simple GET /info endpoint this is sufficient.
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 mostly concise and front-loaded with purpose. However, it includes extraneous boilerplate about parameter aliases and has a minor grammar issue ('Vikunja This endpoint'). Still, it earns its place with useful details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (zero params, no annotations, no output schema), the description adequately covers what is returned and the call constraints. The phrase 'various settings' is vague, but it names key fields and specifies no auth, making it sufficiently complete for this endpoint.
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?
Input schema has zero parameters, so baseline is 4. The description mentions 'Path and query parameters are top-level fields' and naming aliases, which adds context but may be boilerplate since no parameters actually exist. It does not need to explain individual parameters.
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 explicitly states it is a 'Raw Vikunja REST proxy for GET /info' and lists what it returns (version, frontendurl, motd, settings). This clearly distinguishes it from higher-level sibling tools like vikunja_get_server_info by highlighting the raw proxy nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides invocation details (no request body, parameter aliases, no auth) but lacks explicit guidance on when to use this tool versus alternatives. It implies usage via 'Raw Vikunja REST proxy' but does not state exclusions or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return semantics (whether migration was done), that a request body is usually not required, and that authentication is necessary. It does not mention response format, error conditions, or explicitly state read-only behavior, but for a simple status GET this is reasonably transparent.
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 five sentences covering purpose, endpoint, use case, request body, alias conventions, and auth. Each sentence adds value, though the alias sentence may be unnecessary given no parameters. It is efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter status check with no output schema, the description is fairly complete: it explains purpose, behavior, use case, request body expectation, and authentication. It stops short of explicitly stating the return type (e.g., boolean), but the phrase 'returns if...' implies it. It is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters (empty input schema), so the description cannot add much parameter-specific meaning. It does mention that path/query parameters are top-level and accept camelCase/snake_case aliases, but this is a generic note irrelevant to the current schema. Per the rubric, 0 parameters earns a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'gets migration status' and specifies the exact REST endpoint (GET /migration/wekan/status). It explains what it returns (whether the current user already performed the migration), which distinguishes it from migration mutation tools in the sibling list. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case: showing a confirmation message when a user tries to repeat the same migration. It also notes authentication is required. However, it does not explicitly name alternative tools or say when not to use this tool, so it falls slightly short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description compensates well by disclosing authentication needs, that a request body is usually unnecessary, that parameters are top-level, and that aliases are accepted. It also conveys read-only GET semantics but does not describe error handling or detailed response structure.
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 compact and front-loaded with the primary purpose. However, it has minor redundancy ('Get one task' vs 'Returns one task by its ID') and a missing period between sentences, which slightly detracts from polish.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-task GET proxy with no output schema, the description covers the endpoint, auth, body expectations, and parameter conventions. The only ambiguity is the schema suggesting 'id' is required while the formal required list is empty, but the description itself does not add confusion.
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 already describes both parameters (id and expand) thoroughly, so the baseline is 3. The description adds valuable beyond-schema context about top-level parameter placement and camelCase/snake_case aliases, which aids invocation, though it does not explicitly map which parameter is path vs query.
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 'Get one task' and identifies the exact REST endpoint 'GET /tasks/{id}'. This specific verb+resource combination distinguishes it from list/project tools and makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful invocation context (top-level fields, camelCase/snake_case aliases, no body required, auth required), but it does not explicitly state when to use this raw proxy versus higher-level sibling tools like vikunja_get_task. Usage is implied rather than directly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and adds meaningful behavioral details: 'Returns json on error', 'does not usually require a request body', parameter aliases, and authentication requirement. It does not detail the success response format (binary file), but 'for download' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about five short sentences) and front-loads the primary purpose. Minor redundancy exists ('Get one attachment' repeated) and a typo ('..'), but overall it is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET proxy with no output schema, the description covers the endpoint, error behavior, body/request details, parameter aliasing, and auth. It could explicitly state the success response is the file content, but 'for download' sufficiently implies it. Overall sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents each parameter with descriptions (100% coverage). The description adds valuable semantic context: parameters are top-level fields and accept camelCase/snake_case aliases, which clarifies the duplicate parameter entries in the schema. However, it adds no new information about individual parameter meanings beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get one attachment for download' and specifies the exact endpoint 'GET /tasks/{id}/attachments/{attachmentID}'. Despite the tool name suggesting tasks, it unambiguously identifies the resource as attachments, distinguishing it from sibling task tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for downloading a specific attachment via the endpoint path, but does not explicitly state when to prefer this over alternatives or exclude other tools. It provides context ('for download') but lacks overt comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses several behaviors: returns an error if TOTP is not enabled, request body is usually unnecessary, parameter naming conventions (camelCase/snake_case aliases), and authentication requirement. This goes beyond a simple 'get' statement, though it omits response structure.
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?
Written in four sentences, each providing distinct information: purpose, endpoint proxy, return behavior, and request/auth notes. It is compact and logically ordered, though the opening fragment could be integrated but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the essential aspects: what it returns, error case, authentication, and parameter conventions. It could mention response format, but for a simple GET proxy it is sufficiently 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, so the schema covers everything. The description adds generic info about path/query parameter handling and aliases, which is not needed here but harmless. Baseline for 0 params is 4, and no parameter-specific gaps exist.
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?
Clearly states the tool retrieves the current user's TOTP setting, explicitly naming the endpoint (GET /user/settings/totp) and distinguishing it from sibling user-related tools. The verb 'get' and resource 'totp setting' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is to fetch TOTP settings, but no explicit when-to-use vs alternatives or exclusions. Mentions authentication is required and that no request body is usually needed, giving context, but does not name alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions prerequisites, authentication, and parameter aliases, which is useful. However, it does not explicitly state that existing data in the table will be overwritten or destroyed, and it omits details about error behavior or response format. The phrase 'Reset the db' implies destructiveness but stays vague.
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 moderately sized but every sentence contributes: purpose, endpoint mapping, prerequisites, auth, payload instructions, and aliases. It is front-loaded with the core action and ends with 'Authentication is required,' which is slightly redundant but not wasteful. No fluff or filler beyond the 'See docs' note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a proxy tool with 2 parameters and no output schema, the description covers the essential behavioral aspects: what it does, prerequisites, auth, and parameter passing. It doesn't explain return values (no output schema) or what happens to existing data, but 'Reset the db' partially covers that. Given the low complexity and sibling context, it is sufficiently 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?
Schema coverage is 100%, and the schema already describes both parameters. The description adds practical meaning by explaining how to pass the body (optional JSON payload), that path/query parameters are top-level fields, and that camelCase/snake_case aliases are accepted. This aids correct invocation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reset the db to a defined state. Fills the specified table with the content provided in the payload.' It also identifies the exact endpoint (PATCH /test/{table}) and differentiates it from sibling tools like vk_delete_test_bfe51f44bd2a (which likely performs DELETE). The verb+resource+scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: it explains the prerequisite of enabling the testing endpoint, the need for an Authorization token, and how to pass the payload. It does not explicitly contrast with alternatives, but the endpoint identification and the unique 'PATCH /test' target make the usage scenario clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the exchange mechanism, the optional body, and the authentication requirement, which are meaningful behavioral insights. It doesn't cover failure modes or side effects on existing tokens, but the core semantics are clear.
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 front-loaded with the primary purpose and is compact, with most sentences adding value. However, the sentence about path/query parameters being top-level fields is confusing and not clearly aligned with the schema, which slightly undermines the structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple token refresh proxy with one optional parameter and no output schema, the description covers the purpose, authentication, and invocation details adequately. It doesn't explain the response format, but that is not critical for this tool's simplicity and the available schema/annotations.
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 does add useful info about camelCase/snake_case aliases and the optional body, but the claim that 'Path and query parameters are top-level fields' is contradicted by the schema's additionalProperties: false, creating ambiguity for the single allowed field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Refresh user token', a specific verb+resource combination. It further distinguishes itself by identifying the exact Vikunja endpoint (POST /user/token/refresh) and explaining the exchange of refresh token cookie for a JWT, which is unique among the many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is a token refresh operation, authentication is required, and the request payload is optional. However, it does not explicitly mention when not to use it or compare it to alternative auth tools like login, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses authentication requirements, raw proxy behavior, multipart form encoding, file object format, alias conventions, and required fields. It does not cover side effects like whether the import replaces existing tasks or error behavior, but content is substantial.
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?
Description is front-loaded with the core action and then provides necessary encoding details; every sentence adds technical value. There is slight redundancy in restating required fields, but overall it is tight and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-upload import tool with no annotations or output schema, the description covers transport format, required fields, authentication, and parameter aliases. It omits return format and specific config contents, but the description is sufficient for basic invocation.
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 schema already covers the form object and import/config fields; the description adds multi-file array handling, camelCase/snake_case alias support, and clarifies file object semantics. The generic claim about top-level path/query parameters slightly conflicts with the schema's additionalProperties:false, but the form-field guidance keeps it usable.
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?
Description opens with 'Import CSV file' and identifies the exact endpoint 'PUT /migration/csv/migrate', giving a specific verb and resource. This clearly distinguishes it from sibling migration tools and states the operation: imports tasks from a CSV file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use it to import CSV tasks. However, the description provides no explicit guidance on when to choose this tool over sibling migration endpoints, no exclusions, and no mention of alternatives. It does state required fields and authentication, offering operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses technical details: multipart form data, file object shape with filename/contentBase64/contentType, array support, field aliases, and required authentication. However, it does not disclose behavioral consequences such as whether the import overwrites existing data, is idempotent, or returns a status; with no annotations, this is a moderate 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 front-loaded with purpose and contains many useful details, but the first and third sentences redundantly restate the import scope ('Import all projects, tasks etc.' vs 'Imports all projects, tasks, notes...'). Overall it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema. The description covers input construction and auth, but does not explain return values, whether the migration is asynchronous, or potential side effects like duplicates. For a one-parameter but complex multipart import, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a 'form' object with a brief description. The description adds substantial meaning: multipart form data structure, file object schema, multi-file arrays, top-level path/query handling, and camelCase/snake_case aliases, plus the required 'import' field.
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 it imports all projects, tasks, notes, reminders, subtasks and files from a TickTick backup export into Vikunja, and names the exact REST endpoint PUT /migration/ticktick/migrate. This is a specific verb+resource+scope and distinguishes from sibling migration tools by explicitly identifying TickTick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to pass multipart form data with an 'import' field, and notes that authentication is required. This gives clear context for when to invoke (when a TickTick backup is available) but does not explicitly contrast with alternative migration tools or mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It transparently lists what is copied (tasks, files, kanban data, assignees, comments, attachments, labels, relations, backgrounds, permissions, link shares), states that authentication is required, and specifies permission needs. It does not explicitly state that the original project is left unchanged, but this is strongly implied by 'copying' to a new project.
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 information-dense but well-structured: it starts with the core action, then details the REST endpoint, the copied elements, permissions, and invocation details. Every sentence adds value, though the list of copied items is a bit long. It is appropriately sized for a complex operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the essential operational context: what it does, what it copies, required permissions, authentication, and how to supply parameters. The only notable gap is the body optionality contradiction, which prevents a perfect score. Return value is not described, but this is less critical as no output schema exists and the action is a duplicate 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?
Schema descriptions are present for all parameters, but they are terse ('The target parent project...' and 'The project ID to duplicate Required.'). The description adds useful context about accepting camelCase and snake_case aliases and that payload goes in the body. However, it calls the body 'optional' while the schema lists it as required, creating a direct contradiction that undermines parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Duplicate an existing project,' which is a specific verb+resource pair that clearly states the tool's function. It further specifies the exact REST endpoint (PUT /projects/{projectID}/duplicate) and enumerates what gets copied, distinguishing it from generic project creation/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for duplicating a project, and it provides essential prerequisite guidance (read access in the source project, write access in the parent of the new project). It does not explicitly mention alternatives or exclusions, but the duplication focus is unambiguous and the permission requirements help the agent decide when it can be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state that authentication is required and explains the multipart/file object mechanics. However, it omits side effects (e.g., whether existing attachments are replaced), response behavior, and error handling. This is a mutation tool, so such details matter; the description covers only part of the behavioral profile.
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 mostly concise and front-loaded with the core purpose. However, 'Upload a task attachment.' appears twice, which is redundant and wastes words. The rest of the sentences are purposeful, explaining file encoding, aliases, and requirements, so it remains efficient overall despite the duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw proxy with no output schema, the description covers the key input mechanics: required fields, file format, multipart handling, and authentication. It does not describe the return value or error scenarios, which would be expected for a complete tool description, especially given the lack of an output schema. This prevents a 5 but the overall coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining file object structure ({filename, contentBase64, contentType?}), multi-file array support, and that camelCase/snake_case aliases are accepted. This helps the agent construct parameters correctly, going beyond what the schema's 'description' field already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Upload a task attachment,' a specific verb and resource that clearly distinguishes this tool from the many vk_put_tasks variants in the sibling list, none of which mention attachments. The endpoint PUT /tasks/{id}/attachments is explicitly stated, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: multiple files can be passed, multipart form data is required, and aliases are supported. It does not explicitly mention when to use this tool over alternatives, but the raw proxy framing and attachment-specific purpose implicitly guide the agent. There are no exclusions or alternatives mentioned, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the effect ('The team won't have access to the project anymore'), notes that no request body is usually required, explains parameter naming conventions (camelCase/snake_case aliases), and states authentication is required. This is solid behavioral context, though it omits details like idempotency or error responses.
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 mostly efficient but includes redundancy: 'Delete a team from a project.' appears twice (once with a typo 'Delets'). This repetition wastes words, though the rest is structured logically. A more concise version would remove the duplicate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description explains the action, effect, required auth, request body absence, and parameter aliases. This covers the essential context for invocation, though it doesn't mention what happens if the team or project doesn't exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which helps agents construct requests correctly without relying solely on the schema's enumerations.
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 explicitly states 'Delete a team from a project.' and specifies the exact REST endpoint (DELETE /projects/{projectID}/teams/{teamID}). This clearly identifies the action and resources, distinguishing it from sibling tools that delete entire projects or teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by naming the REST proxy path, which implies when to use it—for removing a team's access from a project. It does not explicitly list exclusions or alternatives, but the endpoint semantics make the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses authentication, write-access permissions, the fact that no request body is typically needed, and parameter aliasing/casing rules. It does not describe response/error behavior, but for a simple delete proxy this is reasonable.
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 first sentence 'Remove a label from a task' is repeated verbatim, which wastes space. The rest is compact and includes only necessary details, but the redundancy prevents a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no nested objects, no output schema), the description covers the essential operational details: permissions, authentication, parameter handling, and the raw proxy nature. It lacks side-effect/response details, but these are less critical for a straightforward delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with 100% coverage, but the description adds valuable semantics: parameters are top-level fields, original names accept camelCase and snake_case aliases, and the endpoint maps directly to path parameters. This goes beyond the minimal schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a label from a task' and provides the exact REST endpoint DELETE /tasks/{task}/labels/{label}. This distinguishes it from generic task deletion tools and other siblings by specifying the exact resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides practical context: requires write-access to the project, authentication is required, and the endpoint usually does not require a request body. However, it does not explicitly mention alternative tools for the same operation (e.g., vikunja_remove_label_from_task), so it slightly misses the 'alternatives' requirement for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that no request body is usually needed, path/query parameters are top-level, camelCase/snake_case aliases are accepted, and authentication is required. It does not mention response format or error cases, but for a simple delete this is sufficient.
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 short but contains duplication: 'Delete a user-level webhook target.' appears twice, wasting a sentence. The first sentence and the third sentence are identical, so it could be more concise while still retaining the HTTP endpoint details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete operation with no output schema and no annotations, the description covers purpose, auth, parameter handling, and the no-body requirement. It does not describe return values or error conditions, but the simplicity of the operation makes the description reasonably 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?
Schema coverage is 100% and the parameter 'id' is already described as 'Webhook ID Required.' The description adds practical value by noting that parameters are top-level fields and accept aliases, which helps agents correctly format the request.
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: 'Delete a user-level webhook target.' It includes the HTTP endpoint 'DELETE /user/settings/webhooks/{id}', making the resource and scope specific. The mention of 'user-level' differentiates it from project-level or other deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool deletes a user-level webhook and requires authentication. It does not explicitly mention alternatives or exclusions (e.g., project-level webhooks), but the resource specificity gives a solid usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that no request body is usually required, path/query parameters are top-level, camelCase/snake_case aliases are accepted, and authentication is required. This adds meaningful behavioral context, but it does not explicitly state that it is read-only or describe pagination.
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 relatively concise but contains redundancy: 'Get all reactions for an entity' is repeated almost verbatim as 'Returns all reactions for an entity'. There is also a missing period after 'entity' before 'This'. The redundancy wastes a sentence that could be removed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema and no annotations, the description covers the essential aspects: purpose, endpoint, parameter handling, aliases, and authentication. It misses minor details like potential pagination or the exact response structure, but it is largely 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?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that parameters are top-level and accept aliases, which is crucial for correct invocation. The schema already provides the allowed values for 'kind'.
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 'Get all reactions for an entity' and specifies the exact REST endpoint 'GET /{kind}/{id}/reactions'. This is a specific verb+resource that distinguishes it from sibling tools like vk_get_tasks or vk_post_kind.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it is a raw proxy for fetching reactions, and it explains how parameters are passed (top-level) and that authentication is required. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the endpoint usually requires no request body, that path/query parameters are top-level, that camelCase/snake_case aliases are accepted, and that authentication is required. It does not describe error behavior or return format in detail, but the provided details are valuable.
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 four sentences, each adding essential information: purpose, endpoint, request body note, parameter behavior, and auth. It is front-loaded with the primary action and avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the core purpose, endpoint behavior, parameter handling, and authentication. It could detail pagination or response shape, but for a simple GET users proxy, it is reasonably 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that parameters are top-level and that both camelCase and snake_case aliases work, which helps agents understand how to pass id, s, page, and perPage correctly. This goes beyond the schema descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get users on a project.' It clearly states the endpoint (GET /projects/{id}/users) and distinguishes this from sibling tools like vikunja_get_project, which fetch project details rather than user lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about being a raw Vikunja REST proxy and the endpoint, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It states authentication is required, read access to the task is necessary, no request body is typically needed, and parameter aliases are accepted. It does not describe return format or error handling, but for a simple GET this is reasonable.
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 somewhat redundant, repeating 'Get a task comment' twice, and includes a minor grammatical error ('need to have' instead of 'needs to have'). It is not excessively long, but the redundancy reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only GET with no output schema and no annotations, the description covers the essential context: purpose, endpoint, permissions, auth, and parameter style. It does not explain return values, but that is often inferred, and lack of alternative tool references slightly limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already documents all six parameter variants with descriptions, the description adds value by explaining that parameters are top-level fields and that camelCase/snake_case aliases are accepted, clarifying how to structure the invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a task comment' and provides the exact REST endpoint, making the tool's function unambiguous. It distinguishes itself from sibling tools like vikunja_list_task_comments by specifying it retrieves a single comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, including the need for read access to the task and authentication. However, it does not mention alternatives or explicitly state when not to use this tool, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behaviors: request body is usually not required, path/query parameters are top-level fields, camelCase/snake_case aliases are accepted, and authentication is required. It does not describe the response format, but that is partially mitigated by the lack of an output 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 concise at four sentences, front-loads the purpose, and each sentence adds distinct value (purpose, proxy nature, request body, parameter conventions, auth). No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, no output schema), and the description covers purpose, auth, and request body expectations. It lacks details on the response structure, but that may be expected from a raw proxy and is not critical given the simplicity. Overall, it is adequately complete for the complexity level.
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 zero parameters, and schema coverage is high. The description adds context about parameter conventions (top-level fields, aliases), which is useful for understanding the proxy pattern, though it is generic given there are no actual parameters. Baseline for 0 params is 4, and the description does not reduce quality.
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 tool fetches the current user data export via GET /user/export. The verb 'Get' and resource 'user data export' are specific, and 'Raw Vikunja REST proxy' distinguishes it from higher-level user endpoints like vikunja_get_current_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when you need the user data export, and the 'raw proxy' note suggests it is for lower-level access. However, it does not explicitly compare with sibling tools or state when to use this versus alternatives like vikunja_get_current_user, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently mentions that the endpoint does not usually require a request body, explains parameter alias conventions, and notes that authentication is required. This gives the agent necessary operational context beyond the bare action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loads the primary purpose. There is slight redundancy between 'Return user avatar setting' and 'Returns the current user's avatar setting', but overall each sentence adds relevant operational detail without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only endpoint with no parameters and no output schema, the description covers purpose, authentication, parameter handling, and the raw proxy nature. It does not describe the exact response format, but the resource name and endpoint make this less critical. The information provided is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds value by explaining how path and query parameters should be supplied and that aliases are accepted, which is useful for agents that might expect parameters. This exceeds the baseline.
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 'Return user avatar setting' and identifies the exact REST endpoint (GET /user/settings/avatar). This specifies a unique verb+resource+scope, distinguishing it from sibling user-related tools by focusing specifically on the avatar setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by noting this is a raw Vikunja REST proxy and that path/query parameters are top-level fields, but it does not explicitly state when to use this tool versus alternatives like vikunja_get_current_user or other vk_get_user_* tools. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that authentication is required, that a request body is not usually needed, and explains that path/query parameters are top-level fields with camelCase/snake_case aliases. This covers the key operational constraints, though it omits error behavior or exact response format.
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 five sentences but repeats 'Get all possible webhook events' twice. The generic note about alias conventions and body behavior could be trimmed without losing value. Still, it is not overly long and front-loads the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter GET with no output schema, the description provides enough context: purpose, use case, authentication requirement, and body behavior. The agent can confidently invoke it, though a brief note on the return format (e.g., a list of event name strings) would make it fully 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 schema has zero parameters and 100% coverage, so the baseline is 4. The description reinforces that no request body is needed and mentions top-level parameter conventions, which, while generic, are consistent with the schema. It doesn't need to do more since there are no actual parameters.
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 'Get all possible webhook events' and identifies it as a proxy to GET /webhooks/events, distinguishing it from other vk_get tools. It also specifies the use case ('when creating or updating a webhook target'), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when this tool should be used: to fetch webhook event options for creating or updating a webhook target. It doesn't explicitly list alternatives, but for this simple retrieval there are no close sibling tools, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a raw REST proxy, that auth is not required, and that it yields a JWT token. However, it says the body field is 'optional' while the schema requires it, which is misleading. It also does not mention error behavior or response structure beyond the token.
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 concise, front-loaded with the primary purpose, and each sentence adds useful context: the flow, parameter passing conventions, and auth requirement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple auth callback with no output schema and no annotations, the description covers the key aspects: purpose, trigger condition, parameter handling, and auth requirement. It falls short on response details and error handling, but the core usage is well-specified. The optional/required body mismatch is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying path/query parameters are top-level fields and that camelCase/snake_case aliases are accepted. It also indicates the body field carries the JSON payload, though it incorrectly calls it optional.
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 tool authenticates a user via OpenID Connect and obtains a JWT token, distinguishing it from sibling login/register/social auth tools. It uses specific verbs ('Authenticate', 'obtain') and names the resource (OpenID Connect callback).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: after a redirect from the OpenID Connect provider with an authentication code. It explains the flow and that authentication is not required, but does not explicitly exclude alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that authentication is required, explains the raw proxy nature, body field usage, and parameter alias conventions. It doesn't describe return values or error behavior, but the core side effect (changing events) is clearly stated.
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 contains redundant phrasing—'Change a webhook target's events' appears twice, and there's a typo with double periods. Though short, this repetition could have been edited down, making it less polished than a concise description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, endpoint, authentication, parameter passing style, and the constraint on changing only events. It lacks explicit return-value information, but for a raw proxy with no output schema, this is a minor gap. Overall, it provides sufficient context for an agent to invoke the 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?
Schema coverage is 100%, so the parameters already have descriptions. The description adds value by explaining that body is optional and holds the JSON payload, that path and query parameters are top-level fields, and that camelCase/snake_case aliases are accepted—context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool changes a webhook target's events, and the endpoint template specifies the resource. It distinguishes itself from other vk_post_projects tools by emphasizing the webhook-specific scope and the limitation that only events can be changed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it's a raw proxy for a specific Vikunja endpoint, and it explicitly states that other webhook values cannot be changed. It doesn't name alternative tools, but the exclusion is clear enough for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: authentication is not required, token is sent via email, and it is a raw REST proxy with alias handling. It does not mention error scenarios or side effects beyond the email, but for a simple endpoint it is reasonably transparent.
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 concise—five sentences—with the purpose front-loaded in the first sentence. Each sentence adds value: endpoint, behavior, email delivery, parameter format, and authentication status. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects for a simple one-parameter tool: purpose, endpoint, auth requirement, and token delivery. It does not explain the output or response format (no output schema exists), but the description is sufficient for the tool's low complexity. The 'optional' vs required body discrepancy is a gap.
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 the body parameter described as the username, but the description calls the body 'optional' while the schema marks it required, creating a contradiction. It adds useful context about top-level fields and camelCase/snake_case aliases, but the inconsistency reduces reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Request password reset token') and explicitly states the REST endpoint (POST /user/password/token). It clearly distinguishes this tool from other vk_post_user_* siblings by its unique purpose and resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context, including that authentication is not required, and describes the request flow. However, it does not explicitly mention when to prefer this over alternatives or any exclusions, so it lacks the 'when-not-to-use' guidance for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, and it does add key context: authentication is required, the body is a JSON payload, and parameters accept camelCase/snake_case aliases. However, it does not describe side effects beyond 'creates', nor error behavior or return format. These gaps keep it at a standard, minimally-viable level.
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 five sentences, with the purpose front-loaded and each sentence adding necessary detail: the endpoint, the action, the body, parameter conventions, and authentication. There is no redundant or filler content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw REST proxy with three parameters and no output schema, the description covers the endpoint, required authentication, how to pass parameters (including aliases), and the nature of the operation. It does not explicitly state the return value or clarify the schema inconsistency where id/view are marked 'Required' in descriptions but omitted from the required array, but the REST path implies their necessity. Overall, it is fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the body parameter is a JSON request payload and that path/query parameters are top-level fields with alias handling. This goes beyond the simple schema descriptions, which only label id/view as 'Required' and body as 'The bucket object'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new bucket' and reiterates 'Creates a new kanban bucket on a project.' This gives a specific verb and resource, and the REST endpoint clarifies the exact action. It distinguishes itself from sibling proxy tools by focusing on bucket creation on a project view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is for creating a bucket on a project view, which implies when it should be used. It does not explicitly exclude alternatives or name other tools, but the endpoint and purpose are unambiguous. Given the long sibling list, a more explicit distinction would help, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does well by disclosing that copying includes labels, assignees, attachments, and reminders, that it creates a 'copied from' relation, and that authentication is required. It also explains the body parameter behavior and parameter aliases, providing meaningful non-obvious details.
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 compact and front-loaded, with every sentence serving a purpose: purpose, endpoint, behavior, relation, parameter handling, aliases, and auth. No redundant or filler content is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw proxy tool with no output schema and no annotations, the description covers the essential context: what the tool does, what parameters to pass, how they should be structured, and that authentication is required. It omits return-value details, but that is not critical given the proxy nature and absence of an output schema.
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?
Although the schema already describes taskID and body, the description adds clarity by stating the body is optional and that path/query parameters are top-level fields. It also explicitly mentions camelCase and snake_case aliases, which is not evident from the schema alone, improving the agent's ability to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Duplicate a task.' It then specifies the raw Vikunja endpoint, what gets copied, and the created relation, making the tool's function unambiguous and distinct from sibling task operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case via the duplicate endpoint, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The 'Raw Vikunja REST proxy' context hints at low-level usage, but no direct comparison to sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a raw proxy, requires authentication, and creates a webhook target. However, it does not explain side effects (e.g., overwriting existing webhooks), idempotency, or error behaviors, leaving some behavioral aspects unclear.
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 concise and front-loaded with the core purpose. It covers the proxy nature, parameter handling, and authentication in a few sentences without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple proxy with one parameter, the description covers purpose, scope, parameter usage, and authentication. The absence of return-value or error details is a slight gap, but the tool is straightforward and the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one body parameter with a vague description ('The webhook target'). The description adds meaning by stating that the body is a JSON request payload and that path/query parameters are top-level fields with camelCase and snake_case aliases, significantly enhancing schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a user-level webhook target via a raw REST proxy for PUT /user/settings/webhooks. The specific verb+resource combination distinguishes it from other tools, such as generic user update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it creates a webhook target for the current user that receives events across all projects. It does not explicitly mention when not to use it or name alternatives, but the context is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses permission requirements ('user needs to be the creator'), body behavior ('does not usually require a request body'), parameter passing style ('top-level fields'), and alias conventions. It lacks idempotency or response details, but the key side effects and constraints are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the core purpose and then adding necessary details. It is slightly redundant: 'Delete a label' and 'Delete an existing label' repeat the same idea. Otherwise, each sentence contributes useful information about endpoint, permissions, body, and parameter conventions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description covers the endpoint, authentication, creator permission, body expectations, and parameter conventions. It does not specify the response format, but for a delete endpoint without an output schema, that is a minor gap. Overall, it is sufficiently complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (id described as 'Label ID Required'), so the baseline is 3. The description adds valuable context about parameter passing: 'Path and query parameters are top-level fields' and 'accept camelCase and snake_case aliases.' This clarifies how to provide the id beyond the schema's type definition, enriching the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a label' and identifies the exact endpoint 'DELETE /labels/{id}', making both the action and resource unambiguous. It distinguishes from sibling tools by focusing on the label resource, which is unique among the many vk_delete_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear preconditions: the user must be the creator of the label and authentication is required. It implies usage by specifying this is for deleting labels, not for removing a label from a task (which is handled by vikunja_remove_label_from_task). It does not explicitly mention alternatives, but the context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does well by noting authentication is required, the endpoint usually requires no request body, and path/query parameters are top-level fields. It also explains alias conventions, adding meaningful context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and provides useful details in a compact form. However, 'Delets a user from a project' is redundant with the first sentence and contains a typo, preventing a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple DELETE operation with no output schema, the description covers the essential context: purpose, endpoint, effect, authentication, request body expectations, and parameter aliases. It does not mention error cases or return values, but these are less critical for this simple operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which helps the agent understand how to provide the IDs correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete a user from a project.' It also names the exact REST endpoint DELETE /projects/{projectID}/users/{userID}, which clearly distinguishes it from sibling tools that delete full projects or other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to remove a user's access to a project, stating 'The user won't have access to the project anymore.' It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses permission requirements, authentication, body expectations, and parameter alias conventions. It stops short of describing response/error behavior, but covers the essential operational traits for a delete proxy.
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 front-loaded with the primary action and includes useful operational details in a logical order. Minor redundancy exists—'Remove a task comment' appears twice—preventing a perfect structure score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description provides sufficient information for safe invocation: authentication, permission requirement, body expectations, and parameter conventions. It doesn't mention return values, but that is less critical for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes each parameter as 'Required', and the description adds that parameters are top-level path/query fields and accept camelCase and snake_case aliases. This enriches the sparse schema descriptions and helps agents understand how to pass each ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Remove a task comment' and specifies the exact REST endpoint DELETE /tasks/{taskID}/comments/{commentID}. This clearly identifies the tool's action and resource, and differentiates it from sibling delete-task tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for use: useful for deleting a task comment, requires write access to the task, and notes that a request body is usually not needed. It doesn't explicitly exclude alternatives, but the endpoint and comment focus make the appropriate use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It clearly states the destructive impact ('Truncate all tables', 'Removes all data from every Vikunja table') and authentication requirements. It could explicitly mention irreversibility, but the current language is unambiguous.
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 repetitive and includes boilerplate that does not earn its place. 'Truncate all tables' and 'Removes all data from every Vikunja table' say the same thing, and authentication is mentioned twice. The path/query and alias sentences are irrelevant given the empty schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless test-only reset tool, the description covers purpose, use case, authentication, and request body expectation. No output schema exists, but the return value is not critical for this destructive operation; the description is sufficient for safe invocation.
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 zero properties, so there are no parameters to document. The description adds a generic note about path/query parameters and camelCase/snake_case aliases, which is somewhat extraneous for a parameterless schema but not misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Truncate all tables' and specifies the raw endpoint 'DELETE /test/all', then reinforces it with 'Removes all data from every Vikunja table.' This clearly identifies the verb, resource, and scope, and it distinguishes this tool from sibling per-project or per-task delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the intended context: 'Used by e2e tests to ensure clean state before each test.' It also lists the prerequisite 'Requires the testing token' and mentions that authentication is required, giving clear when-to-use and precondition guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it reveals the raw proxy nature, HTTP method/endpoint, return value, request body expectation, parameter conventions (top-level fields, aliases), and authentication requirement. It does not cover error handling or rate limits, but for a simple GET proxy this is solid.
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 composed of several sentences, but each one adds distinct information: what it does, the raw endpoint, the return value, the use case, request body note, parameter conventions, and auth. It could be tightened (e.g., first sentence repeats the name), but the structure is logical and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema GET proxy, the description covers the purpose, usage scenario, authentication, and parameter conventions. The only gap is a lack of detail about the exact response format, but the key return semantic ('whether the migration was done') is stated. Overall, it is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the schema, and the description still adds value by explaining that path/query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases. This helps the agent understand how to pass parameters if any appear, even though none are currently defined.
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 'Get migration status' and names the exact endpoint (GET /migration/vikunja-file/status), specifying the resource and distinguishing it from sibling migration tools. It also explains the return value ('Returns if the current user already did the migration or not').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('useful to show a confirmation message in the frontend if the user is trying to do the same migration again') and notes that this endpoint usually does not require a request body. However, it does not explicitly mention when to avoid using this tool or point to alternative migration status endpoints, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the raw proxy nature, that no request body is usually required, that path/query parameters are top-level fields, and that aliases are accepted. It also mentions authentication requirements. It does not cover failure modes or rate limits, but for a simple GET endpoint, the details provided are valuable and non-redundant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. Each sentence adds useful information, though the boilerplate about parameter aliases could be considered somewhat extraneous for a zero-parameter endpoint. Overall, it is well-structured and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET endpoint with no input parameters and no output schema, the description is quite complete. It states the return value (the auth URL), the purpose of that URL, authentication requirements, and the REST endpoint. It could mention error scenarios or the exact format of the URL, but these are not critical for the caller to know how to invoke the 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 zero parameters, so the baseline is 4. The description adds generic notes about parameter handling (top-level fields, aliases) but since no parameters exist, these notes are not specifically needed. However, the description does not need to explain parameters as there are none.
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 tool's purpose: 'Get the auth url from Microsoft Todo.' It specifies the exact REST endpoint (GET /migration/microsoft-todo/auth) and distinguishes it from sibling migration tools by naming the specific integration (Microsoft Todo).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the user needs to retrieve the Microsoft Todo auth URL and obtain an auth code for migration. It does not explicitly exclude alternatives, but the specificity to Microsoft Todo differentiates it from other sibling migration tools. It also notes authentication is required, which is a usage prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses key behaviors: returns buckets belonging to the project, buckets are sorted by `position` ascending, the endpoint usually needs no request body, and authentication is required. It does not describe the response format or error behavior, but for a read-only GET this is solid coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and every sentence conveys useful information, but at nine sentences it is somewhat longer than necessary. It efficiently covers purpose, REST endpoint, return behavior, sorting, alternative usage, request body, parameter aliases, and authentication without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters, 100% schema coverage, and no output schema, the description is highly complete. It explains the resource, the endpoint, sorting behavior, the alternative endpoint for tasks, parameter aliases, request body expectations, and authentication. It could mention pagination or response shape, but these are not critical for a simple list endpoint.
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 schema already provides 100% coverage with descriptions for `id` and `view`. The description adds valuable semantics beyond the schema by explaining that 'Path and query parameters are top-level fields' and that 'Original parameter names also accept camelCase and snake_case aliases.' This clarifies how to pass parameters, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get all kanban buckets of a project.' It further distinguishes itself from sibling tools by naming the exact REST endpoint (GET /projects/{id}/views/{view}/buckets) and providing an alternative for a related use case ('To get all buckets with their tasks, use the tasks endpoint with a kanban view').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool does and gives an explicit alternative for retrieving tasks within buckets. It also notes that the endpoint 'does not usually require a request body' and that 'Authentication is required,' but it does not explicitly enumerate when not to use this tool beyond the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that authentication is required, that a request body is typically unnecessary, and that parameter names accept camelCase and snake_case aliases. These details add valuable context beyond the mere fact of being a GET request, though it does not describe the response structure or pagination.
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 four sentences, each adding meaningful information. It front-loads the purpose and then provides operational details. It is slightly verbose in explaining parameter conventions for a zero-parameter endpoint, but overall it is well-structured and not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless GET endpoint, the description covers the purpose, usage, and safety-related details such as authentication. It does not explicitly state return format, but the phrase 'Get all webhook events' implies a list. Given the absence of an output schema and the simplicity of the tool, this is sufficiently 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 input schema has zero parameters, so there is little to document. The description adds context about how parameters would be handled (top-level fields, case aliases) which is useful for an agent, even though no parameters are currently defined. This goes beyond the empty schema, earning a strong score.
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 tool's function with a specific verb and resource: 'Get available user-directed webhook events.' It further clarifies by specifying 'Get all webhook events that can be used with user-level webhook targets' and names the exact REST endpoint (GET /user/settings/webhooks/events). This distinguishes it from sibling tools like vk_get_webhooks by focusing on user-directed events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context, noting that the endpoint 'does not usually require a request body' and that 'Path and query parameters are top-level fields.' It also mentions authentication requirements. However, it does not explicitly state when to use this tool versus alternatives (e.g., vk_get_webhooks), so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It discloses that the endpoint usually requires no request body, path/query params are top-level fields, aliases are accepted, and authentication is not required. This is substantive, though it omits error handling or rate limits.
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 slightly longer than strictly necessary but every sentence adds value: endpoint identification, output type, body requirement, parameter conventions, and auth. It is front-loaded with the core purpose 'User Avatar'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool with two parameters and no output schema, the description covers purpose, parameters, authentication, and response format. It lacks explicit error behavior but is otherwise sufficient given the low complexity.
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 schema already provides 100% coverage of parameter descriptions (size and username). The description adds useful information about parameter placement and camelCase/snake_case aliases, which goes beyond the schema and helps the agent construct valid calls.
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 tool's purpose: 'Returns the user avatar as image' and identifies the exact endpoint 'GET /{username}/avatar'. It distinguishes from sibling user tools by specifying the avatar image resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for retrieving an avatar image and notes that authentication is not required. However, it does not explicitly mention alternatives or when not to use this tool compared to other user-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this is a raw proxy requiring authentication, that body is optional, and that path/query parameters are top-level fields with camelCase/snake_case aliases. This gives agents useful operational context beyond the schema, though it does not discuss error behavior or idempotency.
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 front-loaded with the primary purpose and then provides supporting operational details. It is somewhat repetitive ('Mark a task as read' appears twice), but each sentence contributes useful information and the overall length is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is reasonably complete for this simple read-marking operation. It covers purpose, endpoint, parameter passing conventions, authentication, and the optional body. It does not specify return values or error cases, but those are not essential given the tool's simplicity and the raw-proxy nature disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both body and projecttask have descriptions), so the baseline is 3. The description adds value by explaining that projecttask is a top-level field representing the path parameter, that body is optional, and that parameter names accept camelCase/snake_case aliases. This meaningfully supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear imperative 'Mark a task as read' and then specifies the exact REST endpoint POST /tasks/{projecttask}/read, distinguishing it from sibling task operations. The behavior is further clarified by 'removing the unread status entry', which is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when a task should be marked as read for the current user. However, it does not explicitly discuss alternatives or exclusions, even though sibling tools like vikunja_update_task or other task mutations exist. It provides clear context but no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description correctly carries the behavioral burden. It discloses that the call requires no authentication and that the data is 'public information', which is valuable for an agent deciding whether to invoke it. It also hints at the response content ('version and enabled settings'), though it doesn't describe the full response shape.
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, well-structured sentence that leads with the main purpose and then adds the key auth detail. Every word earns its place; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-auth info endpoint, the description is largely complete: it states what the tool does, the nature of the data, and the auth requirement. It lacks a detailed return format, but the mention of 'version and enabled settings' gives a reasonable expectation of the response content.
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 is empty, making parameter semantics a non-issue. Per baseline for zero-parameter tools, the description adds no unnecessary parameter detail, and the 'no auth token required' note further clarifies the only possible implicit input concern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get public information about the configured Vikunja instance', and clarifies scope with 'including version and enabled settings'. This cleanly distinguishes it from sibling tools that retrieve user, project, or task data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need public server info. It also adds a key usage condition ('No auth token is required') that helps an agent know it can be called without credentials. It does not explicitly name alternative tools or exclusion scenarios, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: provider-agnostic removal, no error on missing background, optional request body, top-level parameter convention, camelCase/snake_case aliases, and authentication. It stops short of stating response codes or impact beyond background removal, but the disclosed details are substantial.
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 compact and front-loaded. The first sentence states the core action, followed by four short sentences that each add useful context about edge cases, request body, parameter conventions, and auth. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter endpoint with no output schema or annotations, the description covers the operation thoroughly: what it does, its edge case, request body, parameter style, and auth. It could mention expected response status or irreversibility, but given the tool's narrow scope and the proxy framing, the existing context is largely sufficient.
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 describes the parameter as 'Project ID Required' but lacks detail on how it should be passed. The description adds that path/query parameters are top-level fields and that original parameter names accept camelCase/snake_case aliases, clarifying invocation format. Given schema coverage is 100%, the description provides incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Remove a project background.' It explicitly identifies the REST proxy target 'DELETE /projects/{id}/background', distinguishing it from other project deletion variants. This unambiguously conveys the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use this tool: whenever a project background needs removal. It adds context about idempotent behavior ('does not throw an error if the project does not have a background') and authentication requirements. However, it does not explicitly discuss alternative tools for other delete operations or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the transparency burden. It discloses that the endpoint usually requires no request body, that path/query parameters are top-level, that camelCase and snake_case aliases are accepted, and that authentication is required. It does not detail permissions or error behavior, but provides meaningful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose. Every sentence provides useful information: the action, the endpoint mapping, and key behavioral conventions. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-assignee operation, the description covers the essential context: what it does, the endpoint, parameter handling, body expectations, and authentication. It does not explicitly state that taskID and userID are both required (schema marks 0 required despite property descriptions), and it omits response/error behavior, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions provide basic 'Required' labels with 100% coverage, so the baseline is 3. The description adds value by explaining that parameters can be top-level path/query fields and that both camelCase and snake_case aliases are accepted, which helps the agent understand how to supply the parameters correctly.
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 'Delete an assignee' and 'Un-assign a user from a task', which specifies the exact action and resource. It distinguishes itself from task deletion tools by explicitly mentioning the DELETE /tasks/{taskID}/assignees/{userID} endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: un-assigning a user from a task. It does not explicitly name alternatives, but the endpoint path and phrasing make it obvious when this tool is appropriate versus deleting a whole task. Context is clear, though exclusions are not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses multiple behavioral traits: it's a raw REST proxy, path/query parameters are top-level fields, camelCase and snake_case aliases are accepted, authentication is required, and a request body is typically unnecessary. These details go beyond the schema and add real value.
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 four short sentences, with the core purpose front-loaded. Each subsequent sentence adds operational detail (proxy nature, aliases, auth, body expectations) without any fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple delete action with one logical parameter and no output schema, the description sufficiently covers usage. It states ownership scope, authentication, body expectations, and parameter naming rules. It doesn't mention irreversibility, but that is inherent in delete operations and largely obvious.
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?
Although schema coverage is 100%, the three properties are essentially redundant aliases for the same tokenID. The description clarifies that original parameter names accept camelCase and snake_case aliases, and that these are top-level path/query fields. This adds meaning beyond the repeated 'Token ID Required' schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Deletes an existing api token' — a specific verb and resource. It further identifies itself as the raw REST proxy for DELETE /tokens/{tokenID}, distinguishing it from sibling tools that delete projects, tasks, or teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context: it deletes API tokens owned by the user and notes that the endpoint normally does not require a request body. It does not explicitly name alternatives like vk_get_tokens or vk_put_tokens, but the sibling list and the phrase 'Delete any of the user's api tokens' make it clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that 'Authentication is required', the endpoint 'does not usually require a request body', and that 'Path and query parameters are top-level fields' with camelCase/snake_case aliases. This is valuable behavioral context, though it omits details like error handling or return structure.
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 four sentences, each earning its place: purpose, REST proxy reference, body requirement, and parameter/alias behavior. It is front-loaded with the core purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter GET with no output schema, the description adequately covers purpose, authentication, parameter passing, and body expectations. However, it does not describe the return format or error scenarios, which would be needed for a 5. Given the simplicity, it remains reasonably 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 schema already covers the 'id' parameter with a description, providing 100% coverage. The description adds meaning by explaining that parameters are top-level fields and that camelCase/snake_case aliases are accepted, which helps the agent understand how to pass the id. This goes beyond the schema, meriting a 4 rather than the baseline 3.
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 'Gets one saved filter' and 'Returns a saved filter by its ID', specifying the exact resource and action. It distinguishes from sibling tools like vk_get_projects by focusing on filters, and the HTTP method (GET) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: to retrieve a saved filter by ID. It also notes this is a 'Raw Vikunja REST proxy' which implies it should be used when direct REST-like access is desired. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses authentication requirements, the GET-only nature, that a request body is usually not required, and parameter alias conventions. It stops short of describing the exact response format, but for a simple status check the essential traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: it starts with a concise purpose, then provides the exact endpoint, return semantics, use case, request-body note, parameter conventions, and authentication in a compact, information-dense way. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema status endpoint, the description adequately covers the endpoint path, use case, authentication, and behavioral details. It could be slightly more explicit about the response payload structure, but 'Returns if... or not' gives enough semantic clarity for a simple status check.
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 zero parameters, so the baseline is 4. The description still adds useful context about how path/query parameters are top-level fields and accept camelCase and snake_case aliases, even though no specific parameters exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get migration status' and pinpoints the exact REST endpoint 'GET /migration/ticktick/status'. It additionally explains that it returns whether the current user already performed the migration, which distinguishes it from the many similarly named vk_get_migratio_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'useful to show a confirmation message in the frontend if the user is trying to do the same migration again.' It does not explicitly mention when not to use the tool or suggest alternatives, but the specific endpoint and purpose make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions authentication is required, that the endpoint usually does not require a request body, and explains parameter aliases. These go beyond a bare description, though it does not discuss error handling or exact response structure. For a simple GET status endpoint, this is sufficient.
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 front-loaded with the purpose and includes relevant endpoint and usage context. It contains some boilerplate about parameter handling that is not strictly necessary for a no-parameter tool, but it remains concise and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema status endpoint, the description covers purpose, specific endpoint, return semantics, use case, and authentication. It is complete and leaves no critical gap for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds context about 'path and query parameters are top-level fields' and camelCase/snake_case aliases, which is helpful even though no parameters are currently defined. Schema coverage is 100%, so nothing is missing.
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 'Get migration status' and precisely identifies the endpoint as 'GET /migration/trello/status'. It explains what the tool returns ('if the current user already did the migation or not'), which distinguishes it from the many sibling migration tools that likely target different endpoints or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'useful to show a confirmation message in the frontend if the user is trying to do the same migration again.' However, it does not explicitly state when not to use this tool or how it compares to the various other migration-related sibling tools, so it lacks explicit exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does well: it discloses the index reassignment caveat, that authentication is required, that a request body is not usually needed, and that parameters are top-level with camelCase/snake_case aliases. It doesn't explicitly state read-only, but 'GET' implies it, and the behavioral caveat about index reassignment is valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the core purpose, and every sentence earns its place: purpose, raw proxy reference, use case, index reassignment warning, and parameter/authentication notes. There is no fluff or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-task GET proxy with no output schema and no annotations, this description is quite complete: it explains the unique indexing mechanism, the reference use case, the caveat about reassignment, authentication, and parameter style. It doesn't cover error responses or edge cases, but for a simple retrieval tool, it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that path/query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which directly aids invocation. It also notes the request body is not usually required, adding practical context not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get one task by its per-project index', a specific verb+resource+scope that clearly distinguishes it from sibling tools like vikunja_get_task (likely by ID) and list tasks. It also provides the exact REST endpoint, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is 'Useful when resolving human-readable references like "PROJ-42" to a canonical task object', giving a clear when-to-use scenario. It also warns that long-lived references should use the returned task id instead, implying a when-not-to-use, though it does not explicitly name alternatives like vikunja_get_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds valuable behavioral details: authentication requirement, that no request body is usually needed, that parameters are top-level fields, and that camelCase/snake_case aliases are accepted. It does not describe error behavior or return shape, but for a simple GET this is reasonably transparent.
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 compact and information-dense. It front-loads the core action, then provides endpoint details, body expectations, parameter formatting, and authentication in a logical sequence with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET proxy with two parameters and no output schema, the description covers the essential aspects: purpose, endpoint, return value, parameter top-level behavior, aliases, and authentication. It is slightly incomplete in not mentioning potential error cases or the structure of the returned link share, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have descriptions ('Share ID Required', 'Project ID Required'). The description adds extra invocation semantics: 'Path and query parameters are top-level fields' and that original names accept camelCase and snake_case aliases, which helps an agent call the tool correctly.
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 ('Get one link shares for a project') and identifies the exact REST endpoint (GET /projects/{project}/shares/{share}). It explicitly returns 'one link share by its ID', which distinguishes it from other project-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: to fetch a single link share by ID. It provides clear endpoint context and the scope ('one link share'), but does not explicitly mention when not to use it or name alternative tools, though the sibling list contains many similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that authentication is required, that the request body is usually unnecessary, and that path/query parameters are top-level fields with camelCase/snake_case aliases. It also labels itself as a 'Raw Vikunja REST proxy,' implying the response is the raw API result. This is useful but does not cover error behavior or return format in detail.
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 structured in clear, functional sentences. However, there is slight redundancy: 'Get all user-level webhook targets' and 'Get all webhook targets configured for the current user' convey the same idea. Otherwise, each sentence adds new information, and the length is acceptable for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless GET tool with no output schema, the description is remarkably complete. It covers the exact endpoint, scope (user-level vs project-specific), authentication, request body expectation, and parameter naming conventions. An agent can invoke this tool without ambiguity regarding its purpose or required inputs.
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 is empty with zero parameters, so the baseline is 4. The description adds context about how parameters would be handled (top-level fields, aliases), but since no parameters exist, this is not essential. It does not need to explain individual parameter semantics because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get all user-level webhook targets.' It also clarifies scope by contrasting with 'not project-specific,' which distinguishes it from sibling tools like vk_get_webhooks_7a215dc6e786. The explicit REST endpoint (GET /user/settings/webhooks) further anchors its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating this targets the current user's webhooks and is not project-specific, which implies when to use it. It also notes that a request body is usually not required and that authentication is needed. However, it does not explicitly name alternative tools for project webhooks or list exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses authentication requirement, that a request body is usually not needed, parameter top-level field behavior, camelCase/snake_case aliases, and privacy-dependent search conditions. Missing return format or behavior when 's' is omitted, but still substantial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose. Each sentence adds distinct value: what it does, how search works, and parameter/auth behaviors. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, search semantics, auth, and parameter handling. The only notable gap is the unspecified behavior when the optional parameter is omitted (e.g., returns all users?), but overall it is adequately 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?
Schema has one param 's' with a minimal description. The description adds meaning by explaining what kinds of searches are supported (username, name, email) and clarifies parameter naming conventions. This goes beyond the schema's 'The search criteria. Optional.'
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 'Get users' and specifically 'Raw Vikunja REST proxy for GET /users', then explains search by username, name, or email. This is a specific verb+resource+scope statement that distinguishes it from sibling user tools (e.g., vikunja_get_current_user or vk_get_user_*).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use (search for users) and explains search constraints, but does not explicitly name alternatives or state when not to use. The privacy caveat for name/email search adds useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses authentication requirements, ownership restrictions, and how to pass the request body. It doesn't mention response format or error behavior, but for a simple proxy tool this is acceptable.
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 three sentences, front-loaded with the primary action, followed by endpoint and constraints. Every sentence adds value with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema), the description covers essential aspects: auth, ownership, body handling, and parameter aliases. It does not describe return values, but that is not critical for this proxy operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (id and body). The description adds the alias convention (camelCase and snake_case) and clarifies the body field's purpose as JSON payload, which goes beyond the schema. This enhances semantic understanding.
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 ('Mark a notification as (un-)read') and specifies the exact endpoint (POST /notifications/{id}), distinguishing it from sibling tools like vk_get_notifica_4bf31ea26a70. The verb 'mark' and resource 'notification' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use to mark a notification as read/unread, with the restriction that a user can only mark their own notifications. It also notes authentication is required. However, it does not explicitly name alternative tools or state when to prefer a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the raw proxy behavior, input handling (body vs. top-level fields), aliases, and authentication requirement. It does not cover error cases or rate limits, but for a simple token renewal tool, the essential behavior is well explained.
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 compact and front-loaded with the core purpose. Each sentence adds unique value—purpose, endpoint, constraint, input format, aliases, and auth—without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides enough context for a simple single-param tool: what it does, when it works, how to pass inputs, and auth requirements. It could mention response details beyond the token itself, but the return value is adequately stated.
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 schema only has one generic 'body' field, but the description adds significant meaning by explaining the JSON payload, the existence of top-level path/query parameters (despite additionalProperties false), and camelCase/snake_case aliases. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renews a link share token, specifies the raw Vikunja REST proxy endpoint (POST /user/token), and differentiates from countless siblings by limiting to link share tokens. The verb 'renew' and resource 'link share token' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes 'Only works for link share tokens,' providing a clear when/when-not boundary, and states authentication is required. It does not name alternative tools for non-link-share tokens, but the exclusion is strong enough to guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the destructive behavior: it destroys the current session and clears the refresh token cookie. It also states that authentication is required and explains the parameter alias conventions. This goes beyond a simple 'Logout' and gives the agent awareness of side effects, though it omits details like response format or irreversibility beyond the destructive effect.
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 compact and front-loaded with 'Logout.' Each sentence contributes necessary information: the endpoint, side effects, parameter handling note, alias conventions, and authentication requirement. There is no redundant or fluff content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the essential aspects: what it does, side effects, authentication, and parameter conventions. However, it does not mention response/error codes and leaves a minor ambiguity about path/query parameters relative to the schema. Overall, it is complete enough for a logout operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one optional 'body' parameter with a description, giving 100% coverage. The description reinforces that the JSON payload goes in the body field and adds useful context about path/query parameters being top-level fields and accepting camelCase/snake_case aliases. This adds value beyond the schema, though the claim about top-level path/query parameters slightly conflicts with the schema's additionalProperties=false.
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 immediately states 'Logout' and specifies the exact REST endpoint 'POST /user/logout', making the tool's purpose unambiguous. It also mentions the concrete effects of destroying the session and clearing the refresh token cookie, clearly distinguishing this from other user-related POST endpoints among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: whenever a logout operation is needed. It provides context such as authentication being required and the raw proxy nature, but it does not explicitly name alternatives or state when not to use this tool. Still, the purpose is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the behavioral disclosure burden. It explicitly warns that the token cannot be seen again after generation, which is a critical irreversible side effect. It also mentions that authentication is required. It does not detail response format or behavior when a token already exists, but the disclosed traits are significant for an agent.
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 four sentences, each purposeful: action, endpoint mapping, irreversible behavior, parameter guidance, and authentication requirement. It is front-loaded with the core purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers purpose, behavior, parameter routing, and authentication. It may lack explicit return value details, but the irreversible token generation is noted. Overall, it is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes a generic 'body' field. The description adds crucial semantics: how to pass the JSON payload, that path/query parameters are top-level fields, and that camelCase/snake_case aliases are accepted. This goes beyond the schema's minimal coverage and helps the agent construct parameters correctly.
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 ('Generate a caldav token') and resource ('caldav token'). It also identifies the raw REST proxy endpoint, distinguishing it from other Vikunja operations. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when a caldav token is needed for the caldav API. It does not explicitly compare with alternatives or state exclusions, but the clear single-purpose nature and endpoint reference provide sufficient guidance for an agent to decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does a solid job: it discloses authentication requirements, the fact that a request body is usually not required, parameter naming conventions (camelCase and snake_case aliases), and the top-level parameter convention. It does not detail error behavior or exact response structure, but it clearly indicates this is a read-only status check.
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 compact but information-dense, front-loading the core purpose immediately. Every sentence contributes useful operational details (endpoint, response meaning, use case, body requirements, parameter aliasing, authentication), with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status endpoint with no output schema, this description is remarkably complete: it states what the endpoint does, which specific migration it applies to, how results should be interpreted, when to use it, authentication requirements, and body conventions. An agent can correctly select and invoke this tool without additional documentation.
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 zero parameters, so the schema itself covers all parameter documentation. The description adds useful context about path/query parameters being top-level fields and the acceptance of camelCase and snake_case aliases, which explains the tool's overall invocation behavior beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get migration status' and names the exact endpoint 'GET /migration/todoist/status'. It also explains the return semantics ('Returns if the current user already did the migation or not'), and the explicit Todoist endpoint distinguishes it from the many sibling migration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'This is useful to show a confirmation message in the frontend if the user is trying to do the same migration again.' It also notes authentication is required and that a request body is usually not needed. However, it does not explicitly mention when not to use this tool or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that authentication is required, that the endpoint usually does not require a request body, and that path/query parameters are top-level with camelCase and snake_case aliases. It lacks details on error responses or the exact response format, but these are reasonable gaps for a simple GET proxy.
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 compact and front-loaded with the core action ('Get the auth url from trello'). Each sentence adds necessary information regarding endpoint, usage flow, and request details, with no verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers all essential aspects: purpose, endpoint, return value, authentication, and request body expectations. It is sufficiently complete for an agent to correctly invoke the tool without additional context.
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 zero parameters, so the baseline is 4. The description mentions generic parameter conventions (top-level fields, case aliases) but no specific parameter semantics are needed. The description does not need to compensate for missing schema detail.
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 'Get the auth url from trello' and specifies the exact REST endpoint 'GET /migration/trello/auth'. This distinguishes it from sibling migration tools and other resource types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: the auth URL is needed to obtain an auth code for migrating from Trello to Vikunja. This implies when to use the tool, though it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses authentication requirements, that a request body is usually not needed, and the parameter naming conventions. It doesn't document response format or pagination, but that is acceptable for a simple GET list.
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?
Four compact sentences each carry distinct, useful information: purpose, endpoint, scope, request-body expectations, parameter handling, and authentication. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET operation with no output schema, the description is complete: it covers purpose, endpoint, token scope, authentication, request body, and parameter conventions. No critical operational detail appears missing.
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?
Input schema has zero properties, so the baseline is 4. The description adds value by explaining top-level parameter conventions and camelCase/snake_case aliases, which is more than the empty schema provides.
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?
Description uses a specific verb 'Get' with a clear resource 'all token api routes' and explicitly maps to the REST endpoint 'GET /routes'. It distinguishes itself from siblings by narrowing to token-based API routes, explicitly noting 'not a user login'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: it lists routes available with an API token, excludes user login usage, and notes that authentication is required. It doesn't name alternative tools, but the resource and auth scope make intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explicitly mentions authentication requirement, the absence of a typical request body, and parameter aliasing behavior. While it doesn't describe output format or error handling, it covers the most critical operational traits for a simple GET.
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 four concise sentences with no filler. Each sentence provides distinct value: resource identification, raw endpoint mapping, body expectation, and parameter naming conventions. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET with no output schema, the description covers all essential context: what it returns, the endpoint, authentication, and request body behavior. It is complete for an agent to invoke correctly without additional assumptions.
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 schema has zero parameters, so the baseline is 4. The description adds useful but generic notes about top-level path/query parameters and camelCase/snake_case aliases, which would apply if parameters existed. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets user information and specifically returns the current user object with settings, using the concrete verb-resource pairing 'Get user information' and the raw endpoint GET /user. This distinguishes it from other vk_get_user_* tools that might target different user resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is a raw REST proxy for GET /user, does not usually require a request body, and requires authentication. It does not explicitly name alternative tools or exclusion criteria, but the context is sufficient for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it returns an unsorted collection of timezones, requires authentication, does not usually need a request body, and clarifies parameter aliases. This goes beyond the minimum and sets correct expectations for the raw proxy nature.
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 consists of four sentences that each provide useful information: purpose, endpoint, behavior (unsorted), request body, parameter naming, and authentication. It is slightly verbose but well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET endpoint with no parameters and no output schema, the description covers key aspects: what it returns, sorting caveat, authentication, and request body expectations. It does not specify the exact response format (e.g., list of strings vs objects) but this is not critical for a timezone list.
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 is empty and there are zero parameters. The description adds generic parameter naming conventions (camelCase/snake_case aliases, top-level fields) which are not strictly necessary but do not hurt. Since there are no specific parameters to explain, the baseline of 4 is appropriate.
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 tool's function: 'Get all available time zones on this vikunja instance.' It also identifies the exact REST endpoint (GET /user/timezones), which distinguishes it from other user-related tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (when you need time zones for the Vikunja instance) and even explains that availability depends on the system. However, it does not explicitly mention alternatives or when not to use it, though the special nature of timezones makes usage fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that authentication is not required, explains parameter passing (path/query params as top-level fields), and mentions camelCase/snake_case aliases. These are useful details beyond the schema, though it does not describe all possible side effects or response details.
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 concise and front-loaded with the main purpose. Each sentence adds new information: the purpose, the REST endpoint, the request payload, parameter conventions, and authentication requirement. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple proxy tool with two parameters and no output schema, the description covers purpose, input handling, authentication requirement, and naming conventions. It is sufficiently complete for an agent to invoke the tool correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the body field as the JSON request payload, clarifying that path and query parameters are top-level, and noting aliases. This goes beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get an auth token for a share' and 'Get a jwt auth token for a shared project from a share hash.' It is specific about the verb, resource, and purpose, and the reference to the REST endpoint distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (given a share hash) and notes that authentication is not required. It does not explicitly name alternative tools or conditions when not to use, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the toggle behavior, the raw proxy nature, the optional body parameter, top-level parameter passing, alias acceptance, and authentication requirement. This is rich behavioral context beyond any structured data.
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 front-loaded with the purpose and contains seven sentences, each providing a distinct piece of information. It is not overly verbose, though some redundancy exists between the toggle statement and the endpoint mapping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters, no annotations, and no output schema, the description covers purpose, behavior, endpoint, body usage, parameter aliases, and authentication. It does not mention response details or permission requirements, but it is still fairly complete for a raw proxy 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?
Schema coverage is 100%, so baseline is 3. The description adds extra meaning by explaining that path/query parameters are top-level fields, that aliases are accepted, and that the body is optional and may carry payloads even when schema omits them. This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Toggle a team member's admin status,' which uses a specific verb and resource. It also names the exact REST endpoint, clearly distinguishing this tool from the many other vk_post_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (to toggle admin status) and explains the toggle behavior. It does not explicitly list alternatives or exclusions, but the raw proxy nature and specific endpoint make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that authentication is required, the endpoint usually does not require a request body, and that path/query parameters are top-level fields. It also clarifies the return semantics. It does not mention error behavior or exact response shape, but it's adequate for a simple GET.
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 concise and front-loaded with the core purpose. Every sentence adds value: endpoint, return value, use case, body requirement, parameter conventions, and authentication. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description covers all essential aspects: what it does, what it returns, when to use it, authentication requirements, and parameter handling. It is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds valuable extra context by explaining that path and query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases. This goes beyond the empty schema and prepares the agent for potential parameter usage.
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 tool's action ('Get migration status') and specifies the exact raw endpoint (GET /migration/microsoft-todo/status), distinguishing it from the many sibling migration tools. It also explains the return value ('Returns if the current user already did the migation or not').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('useful to show a confirmation message in the frontend if the user is trying to do the same migration again') and notes that authentication is required. However, it does not explicitly mention alternatives or when not to use this tool, though the Microsoft Todo specificity implies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excels by disclosing that no request body is typical, parameters are top-level fields with camelCase/snake_case aliases, and authentication is required. This goes beyond the schema and annotations (which are absent), providing valuable 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 reasonably concise at five sentences, with the main purpose front-loaded. There is mild redundancy between the first two sentences ('Get the auth url' and 'Raw Vikunja REST proxy for...'), but it is not distracting and the overall structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter GET endpoint with no output schema and no annotations, the description is remarkably complete. It covers purpose, usage flow, parameter conventions, authentication, and the next step (using the auth code). This is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the baseline is 4. The description adds useful parameter conventions (top-level, aliases) even though no parameters exist for this endpoint, which helps understand similar tools. It does not add semantics for specific parameters because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Get the auth url from todoist' and identifies the exact endpoint 'GET /migration/todoist/auth'. This is a specific verb and resource, and the purpose is unambiguous even among sibling migration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this returns the auth URL for Todoist migration, and the resulting code is used to migrate data. It does not explicitly mention alternatives or when-not-to-use, but the usage scenario is evident. The lack of exclusions prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states authentication is required, explains the raw proxy nature, notes that no request body is usually needed, and clarifies that both camelCase and snake_case parameter names are accepted. This gives the agent a solid mental model of how the tool behaves 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 six sentences long, front-loaded with the primary purpose, and every sentence adds unique information. There is no fluff or repetition. The structure flows from purpose to endpoint to return type to operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, endpoint, return type, authentication, request body expectations, and parameter naming conventions. It does not explicitly explain pagination behavior or error cases, but the schema documents pagination parameters and the description says it returns an array. Given no output schema or annotations, this is reasonably complete for an API proxy 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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by specifying that path and query parameters are top-level fields and that camelCase/snake_case aliases are supported. This clarifies how to pass parameters, which is not evident from the schema alone. It does not redundantly re-explain each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get all assignees for a task.' It identifies the exact REST endpoint and return type, clearly distinguishing it from sibling tools like vikunja_get_task or vikunja_list_tasks. The purpose is unambiguous and directly tied to the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you call this when you need the list of assignees for a task. It does not explicitly name alternatives or state when not to use it, but the context is clear enough. However, it lacks direct comparison to sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: unpassed labels are deleted, new labels are added, existing labels are untouched. It also states 'Authentication is required' and explains parameter handling, providing a complete safety and behavior profile.
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 moderately sized and front-loaded with purpose. Each sentence adds value (behavior, payload, aliases, auth). Minor typo 'task..' but overall concise and structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers purpose, exact behavioral semantics, payload format, parameter aliases, and authentication. It is sufficient for an agent to select and correctly invoke the 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?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema: 'Pass the JSON request payload in the optional body field' and clarifies that path/query parameters are top-level fields with camelCase/snake_case aliases, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update all labels on a task' and explains the exact replace behavior, distinguishing it from individual add/remove label operations. It is specific about the resource (task labels) and the action (bulk update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: it replaces the entire label set, deleting unpassed labels and adding new ones. However, it does not explicitly name alternative tools (e.g., vikunja_add_label_to_task) or state when not to use it, leaving the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: it discloses the read-then-merge implementation, the default partial-update behavior, and the full-replacement behavior when _replace is true. This goes far beyond the schema by explaining what happens to unspecified fields and how the server processes the request.
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 three sentences long, front-loaded with the core action, and every sentence earns its place. It introduces the default behavior, then the escape hatch, without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters and no output schema, the description adequately addresses the key complexity: partial updates vs full replacement. It covers the essential behavioral context needed for correct invocation, and the schema covers individual parameter details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic meaning of the parameters collectively: without _replace, unspecified fields keep their current values; with _replace, they reset to defaults. This is not evident from the schema alone and clarifies how all optional parameters behave.
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 starts with 'Update an existing task with PATCH-style semantics,' which clearly states the verb (update), the resource (existing task), and the crucial behavioral nuance (PATCH-style). It distinguishes itself from create/delete siblings by focusing on modifying an existing task, and the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for updating existing tasks and explains the default partial-update behavior versus the _replace opt-out. It does not explicitly name alternatives or when-not-to-use, but the context of updating an existing task is implicit and the _replace guidance provides practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses that tasks are dissociated but not deleted, the last-bucket restriction, that the endpoint usually requires no request body, parameter alias behavior, and that authentication is required. These are meaningful behavioral traits beyond simply stating the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence states the action, followed by specific details on side effects, constraints, parameter handling, and auth. Every sentence contributes essential information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation with no output schema, the description is complete. It covers the action, side effects, preconditions (last bucket), parameter specifics, and authentication. It gives the agent enough context to invoke the tool safely and understand what will happen.
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 schema already covers parameter names and descriptions, so baseline is 3. The description adds significant value by explaining that path/query parameters are top-level fields and that original parameter names accept camelCase and snake_case aliases, which helps the agent construct valid calls with the correct aliases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Deletes an existing bucket' and further clarifies 'Deletes an existing kanban bucket', giving a specific verb and resource. It explicitly distinguishes this from deleting tasks or projects, and the REST path leaves no ambiguity. Despite the tool name suggesting projects, the description's clarity earns full marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for deleting a kanban bucket, not tasks or projects, and states 'You cannot delete the last bucket on a project' as an explicit exclusion. It does not name alternative tools, but the scope and constraints are sufficiently clear for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so thoroughly: it discloses the preview scope (first 5 tasks), multipart form data requirements, file object structure, multi-file arrays, parameter aliases, path/query field mapping, and authentication needs. This is comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Preview CSV import'), then delivers dense, useful details in six sentences. Every sentence contributes actionable information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (raw proxy, nested multipart object, no output schema), the description covers input encoding, required fields, aliases, auth, and preview behavior. The only minor gap is the format of the `config` string, but that is likely domain-specific and not essential for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the `form` parameter in detail, and the description goes further by explaining aliases, top-level field mapping for path/query parameters, multi-file array handling, and required subfields (import, config). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states 'Preview CSV import' and gives the exact endpoint (PUT /migration/csv/preview), then clarifies it generates a preview of the first 5 tasks. This clearly differentiates it from other migration operations (import, list) and makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear the tool is for previewing CSV imports and notes that authentication is required. It implies it should be used before an actual import, but it does not explicitly name alternative tools (e.g., the import endpoint) or state when not to use it, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![vikunja-mcp MCP server](https://glama.ai/mcp/servers/shichao402/vikunja-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shichao402/vikunja-mcp)

Score Badge

Copy to your README.md:

[![vikunja-mcp MCP server](https://glama.ai/mcp/servers/shichao402/vikunja-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shichao402/vikunja-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shichao402/vikunja-mcp'

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