Provides tools to interact with a Redmine instance, including managing projects, issues, users, time entries, groups, memberships, versions, issue categories, issue relations, wiki pages, news, attachments, files, search, enumerations, catalogs, roles, journals, and Agile Sprints (via the RedmineUP Agile plugin).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Redmine MCP Server list my open issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP (Model Context Protocol) server for Redmine, built with TypeScript.
Node.js 18+
A Redmine instance with REST API enabled
Redmine API Key
Related MCP server: Redmineflux MCP Server
npm install
npm run buildEnvironment variables:
Variable | Description | Required |
| Redmine base URL (e.g. | Yes |
| Redmine API Key | Yes |
Add to your MCP configuration file:
{
"mcpServers": {
"redmine": {
"command": "npx",
"args": ["-y", "redmine-server-mcp@latest"]
"env": {
"REDMINE_URL": "https://redmine.example.com",
"REDMINE_API_KEY": "your-api-key"
}
}
}
}list_projects — List projects
get_project — Project details
create_project — Create project
update_project — Update project
archive_project — Archive project
unarchive_project — Unarchive project
delete_project — Delete project
list_issues — List issues with filters
get_issue — Issue details
create_issue — Create issue
update_issue — Update issue
delete_issue — Delete issue
add_watcher — Add watcher
remove_watcher — Remove watcher
list_users — List users
get_user — User details
create_user — Create user
update_user — Update user
delete_user — Delete user
get_current_user — Current user
get_my_account — My account
update_my_account — Update my account
list_time_entries — List time entries
get_time_entry — Details
create_time_entry — Create
update_time_entry — Update
delete_time_entry — Delete
list_groups, get_group, create_group, update_group, delete_group
add_user_to_group, remove_user_from_group
list_project_memberships, get_membership, create_project_membership, update_membership, delete_membership
list_project_versions, get_version, create_version, update_version, delete_version
list_issue_categories, get_issue_category, create_issue_category, update_issue_category, delete_issue_category
list_issue_relations, get_issue_relation, create_issue_relation, delete_issue_relation
list_wiki_pages, get_wiki_page, get_wiki_page_version, create_or_update_wiki_page, delete_wiki_page
list_all_news, list_project_news, get_news, create_news, update_news
get_attachment, update_attachment, delete_attachment, upload_file
list_project_files, create_project_file
search, search_in_project
list_issue_priorities, list_time_entry_activities, list_document_categories
list_trackers, list_issue_statuses, list_custom_fields, list_queries
list_roles, get_role
update_journal
Requires the RedmineUP Agile plugin installed in your Redmine instance.
list_agile_sprints — List sprints of a project
get_agile_sprint — Sprint details
create_agile_sprint — Create sprint
update_agile_sprint — Update sprint
delete_agile_sprint — Delete sprint
get_issue_agile_data — Get sprint, story points and position of an issue
assign_issue_to_sprint — Assign (or remove) an issue to a sprint
npm run dev # Run in development mode
npm test # Run tests
npm run build # Production buildThe project follows Clean Architecture:
src/
├── domain/ # Types, interfaces, errors
├── application/ # Services (interfaces) and use cases
└── infrastructure/ # Controllers (HTTP), MCP server, utilsMIT
Adds a user to a group.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Numeric group ID | |
| user_id | Yes | Numeric user ID to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only indicates a mutation ('adds'). No disclosure of side effects, permissions, or behavior if the user is already in the group. No annotations to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence), but at the expense of missing important usage details. Acceptable for a simple tool but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and annotations. Does not describe success/failure behavior, idempotency, or error conditions. Incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds no additional semantic value beyond restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('adds') and resource ('user to a group'), distinguishing it from siblings like 'create_group' and 'remove_user_from_group'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'add_watcher' or 'create_group_membership'). Missing prerequisites like whether the user or group must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a user as watcher/observer to an issue.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID | |
| user_id | Yes | User ID to add as watcher |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as overwrite behavior, permission requirements, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient, and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations; description lacks success/error conditions and reversibility information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions; description adds no extra meaning beyond schema, so baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'adds' and resource 'user as watcher/observer to an issue', distinguishing it from sibling 'remove_watcher'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'add_user_to_group' or 'assign_issue_to_sprint'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Archives a project, making it read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses the read-only effect but omits details like reversibility, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that front-loads the key action and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-param tool, but could be improved by mentioning the counterpart 'unarchive_project' or required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond the schema for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'archive' and resource 'project', and distinguishes from siblings like 'unarchive_project' and 'update_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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; lacks context on prerequisites 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.
Assigns an issue to a sprint (or removes it by passing null). Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID | |
| agile_sprint_id | Yes | Sprint ID to assign, or null to remove from sprint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior of removing from sprint when null is passed, but lacks details on permissions, side effects (e.g., overwriting current assignments), or error conditions. Without annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no unnecessary words, and front-loads the core action. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention what the tool returns on success/failure or require specific permissions. It is adequate for a simple assignment but lacks completeness on error handling and prerequisites beyond the plugin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by clarifying that passing null removes the issue from the sprint, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'assign an issue to a sprint' and includes the ability to remove by passing null. It distinguishes from sibling tools like 'create_agile_sprint' and 'list_agile_sprints' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (RedmineUP Agile plugin) but does not provide guidance on when to use this tool versus alternatives or when not to use it. No explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new sprint in a project. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| name | Yes | Sprint name | |
| start_date | No | Sprint start date (DD.MM.YYYY) | |
| end_date | No | Sprint end date (DD.MM.YYYY) | |
| status | No | Sprint status (e.g. open, closed) | |
| sharing | No | Sprint sharing setting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It correctly implies mutation but does not disclose any side effects, permissions, or irreversible actions. The single sentence is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that efficiently conveys the core purpose and a key requirement. It is concise without being too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters (2 required) and no output schema, the description should provide more context, such as return value or relationship to other sprint tools. The current description is too brief for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no extra meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Creates' and the resource 'a new sprint in a project', distinguishing it from other creation tools and the update variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only notes the plugin requirement but provides no guidance on when to use this tool versus alternatives, such as prerequisites (e.g., project must exist) or when to choose update_agile_sprint instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new group in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name (required) | |
| user_ids | No | Array of user IDs to add to the group |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a mutation occurs without disclosing side effects, permission requirements, rate limits, or what happens on input errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description fails to provide sufficient context about return values, error handling, or behavioral nuances, leaving gaps for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 not add any additional meaning beyond the schema for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates' and the resource 'new group' in the context of Redmine, distinguishing it from sibling tools like delete_group or update_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or prerequisites. The description does not indicate when not to use it or mention any conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new issue in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ID of the project to create the issue in (required) | |
| subject | Yes | Issue subject / title (required) | |
| tracker_id | No | Tracker ID (Bug, Feature, etc.) | |
| status_id | No | Status ID | |
| priority_id | No | Priority ID | |
| description | No | Issue description (supports Textile/Markdown) | |
| category_id | No | Issue category ID | |
| fixed_version_id | No | Target version ID | |
| assigned_to_id | No | Assignee user ID | |
| parent_issue_id | No | Parent issue ID (for subtasks) | |
| custom_fields | No | Custom field values | |
| watcher_user_ids | No | User IDs to add as watchers | |
| is_private | No | Whether the issue is private | |
| estimated_hours | No | Estimated hours | |
| done_ratio | No | Percentage done (0-100) | |
| start_date | No | Start date (YYYY-MM-DD) | |
| due_date | No | Due date (YYYY-MM-DD) | |
| uploads | No | Attachments (requires prior upload to get tokens) |
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 behavioral traits. It only states that it 'creates' an issue, but does not mention that it is a write operation, potential side effects (e.g., sending notifications), permission requirements, or return behavior. This is insufficient for safe agentic use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence. While it avoids unnecessary words, it may be too sparse for a complex tool with 18 parameters. It is front-loaded with the core action but lacks structure (e.g., no bullet points or sections).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the high parameter count, the description should provide additional context about return values, error handling, or link to documentation. It does not explain how the tool fits into the broader workflow of issue management (e.g., that it creates and returns the issue ID). The high schema coverage partially compensates, but the description remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all 18 parameters are documented within the schema itself. The description adds no additional meaning beyond the schema, meeting the baseline expectation. However, it does not summarize key parameters or clarify relationships between them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and the object ('a new issue in Redmine'). It is specific enough to convey the tool's primary function. However, it does not distinguish this tool from sibling tools like 'create_issue_relation' or 'create_issue_category', which could cause confusion for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'update_issue' or 'list_issues'. The description lacks any context about prerequisites, conditions, or scenarios where this tool is appropriate, forcing the agent to infer usage 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.
Creates a new issue category in a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required | |
| name | Yes | Category name (required) | |
| assigned_to_id | No | Numeric user ID to auto-assign issues in this category |
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 states the creation action, with no details on side effects, permission requirements, uniqueness constraints, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no fluff. It is appropriately concise, though it could be slightly expanded to include key context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 3 parameters and no output schema, the description is incomplete. It does not explain what is returned, whether the category name must be unique per project, or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and descriptions. The description does not add any additional meaning beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates'), the resource ('new issue category'), and the scope ('in a project'). It distinguishes from sibling tools like list, get, delete, and update issue categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., update_issue_category). Usage is implied by 'creates', but no context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a relation between two issues.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric source issue ID (required) | |
| issue_to_id | Yes | Numeric target issue ID (required) | |
| relation_type | Yes | Relation type: relates, duplicates, duplicated, blocks, blocked, precedes, follows, copied_to, copied_from (required) | |
| delay | No | Delay in days (only for precedes/follows relation types) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether the operation is destructive, idempotent, requires permissions, or what happens on conflict (e.g., if relation already exists). This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without wasted words. However, it may be too minimal given the tool's complexity (4 parameters, no output schema). It is adequately sized but lacks necessary detail for a complete understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the return value or side effects of creating a relation. Since there is no output schema, the agent needs to know what to expect. Additionally, no information about error conditions or constraints is provided, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all parameters. The description adds no additional meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('creates a relation') and the resource ('between two issues'). It is specific and unambiguous, but does not differentiate from sibling tools like delete_issue_relation or get_issue_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when to use a different relation type or when to avoid creating duplicates. The description only identifies the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a news item in a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| title | Yes | News title (required) | |
| description | Yes | News body/content (required) | |
| summary | No | Short summary of the news |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose important traits such as idempotency, side effects, or permission requirements for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence conveys the core function with no wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and description omits return values or success indicators. For a creation tool with 4 parameters, more context on response structure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well documented. Description adds no extra meaning beyond the verb, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it creates a news item in a project, clearly identifying the action and resource. It distinguishes from update/list siblings implicitly, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like update_news or list_project_news. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or updates a wiki page. Uses PUT (idempotent by title). If the page exists it updates it, otherwise creates it.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| title | Yes | Wiki page title (used as slug). For new pages this becomes the page name | |
| text | Yes | Page content in Textile format (Redmine default) or Markdown if configured | |
| comments | No | Version comment describing the change | |
| parent_title | No | Title of the parent wiki page (for hierarchy) | |
| version | No | Current version number for optimistic locking. If provided and conflicts, update will fail |
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 mentions idempotency via PUT and upsert logic, which are key behaviors. However, it omits important details like optimistic locking (version parameter), content format constraints, and what happens on failure, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. Every sentence adds value, achieving high conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description does not fully cover behavior like error responses, version conflict handling, or what the return value is. While the schema explains parameters well, the description alone leaves some contextual gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 idempotency by title and upsert logic, which provides context beyond the raw parameter descriptions. It does not repeat schema details, making it additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or updates a wiki page. It specifies the HTTP method (PUT) and idempotency by title, distinguishing it from read-only wiki tools like get_wiki_page and list_wiki_pages among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating or updating wiki pages but does not explicitly state when to use it versus alternatives. Since there are no separate create or update tools for wiki pages, the guidance is adequate but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new project in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project display name | |
| identifier | Yes | Unique identifier (lowercase, hyphens, 1-100 chars). Cannot be changed after creation | |
| description | No | Project description | |
| homepage | No | Project homepage URL | |
| is_public | No | Whether the project is public (default true) | |
| parent_id | No | ID of the parent project (for subprojects) | |
| inherit_members | No | Inherit members from parent project (only for subprojects) | |
| default_assigned_to_id | No | Default assignee ID for new issues | |
| default_version_id | No | Default target version ID for new issues | |
| default_issue_query_id | No | Default saved query ID for issue list | |
| tracker_ids | No | IDs of trackers available in this project | |
| enabled_module_names | No | Module names: issue_tracking, time_tracking, news, documents, files, wiki, repository, boards, calendar, gantt | |
| issue_custom_field_ids | No | IDs of issue custom fields enabled for this project | |
| custom_fields | No | Custom field values for the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states that the tool creates a project, but omits key behaviors such as requiring admin privileges, that the identifier cannot be changed after creation (though noted in schema), or any side effects like member inheritance or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, but lacks structure. While it is front-loaded, it is too brief and does not earn its place by adding value beyond the name. A slightly longer description with important flags would be more helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters) and no output schema or annotations, the description is severely incomplete. It does not mention the return value (likely the created project object), error conditions, or any constraints beyond what the schema provides. 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.
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 additional meaning beyond what is already in the input schema parameter descriptions. It does not clarify any parameter constraints or provide usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource ('Creates a new project in Redmine'). However, it does not distinguish this tool from sibling tools like update_project or archive_project, which are also project-related. The verb+resource is specific enough for a basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 update_project or archive_project. The description lacks any context about prerequisites, when creation is appropriate, or what to do if a project already exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a previously uploaded file to a project. Requires a token obtained from upload_file.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| token | Yes | Upload token returned by upload_file | |
| filename | Yes | Filename for the project file | |
| description | No | Optional description for the file | |
| version_id | No | Optional version ID to associate the file with a project version |
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 dependency on a token, implying mutation by 'adds', but lacks details on idempotency, error conditions, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema, the description is minimal. It covers the core purpose and a prerequisite but omits success behavior, return values, and error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no new meaning beyond the schema; it merely reemphasizes the token requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Adds a previously uploaded file to a project', specifying the verb ('adds') and resource ('file to a project'). It distinguishes from sibling tools like 'upload_file' by requiring a token from that step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Requires a token obtained from upload_file', indicating a prerequisite and sequential usage. However, it does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Adds a user or group to a project with the specified roles.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required | |
| user_id | No | Numeric user ID to add. Provide either user_id or group_id | |
| group_id | No | Numeric group ID to add. Provide either user_id or group_id | |
| role_ids | Yes | Array of role IDs to assign (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'adds', but omits critical behavior: what happens if membership already exists? (error or update?), whether roles replace or append, required permissions, or response details. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description should mention return value or success indicator. It does not. Also lacks error conditions or idempotency. Slightly incomplete but not severely lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no extra meaning beyond the schema, but does confirm the mutually exclusive nature of user_id and group_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('adds') and the resource ('user or group to a project with specified roles'). It effectively distinguishes from sibling tools like list_project_memberships, update_membership, and delete_membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., update_membership for modifying roles, or delete_membership). No prerequisites mentioned (e.g., user/group and project must exist). Agents need more context to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new time entry. Requires either issue_id or project_id, and hours.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | No | Issue ID to log time against. Either issue_id or project_id is required | |
| project_id | No | Project ID or identifier to log time against. Either issue_id or project_id is required | |
| hours | Yes | Number of hours spent (required) | |
| activity_id | No | Time activity ID (e.g., Development, Design) | |
| comments | No | Description of the work done | |
| spent_on | No | Date the time was spent (YYYY-MM-DD). Defaults to today | |
| user_id | No | User ID to log time for (requires admin privileges). Defaults to current user | |
| custom_fields | No | Custom field values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'Creates a new time entry' without disclosing side effects, permissions, rate limits, or expected behavior on success/failure. For a mutation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that are concise and front-loaded with purpose. Could add more detail without harming conciseness, but currently efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 8 parameters and no output schema, the description is incomplete. It does not explain return values, validation errors, or how to handle optional parameters like activity_id, comments, etc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds minimal value ('requires either issue_id or project_id, and hours') which is already in schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a time entry and specifies required parameters (issue_id/project_id and hours). Distinguishes from similar tools by the specific resource type. However, does not explicitly differentiate from other creation tools like create_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic usage requirement ('Requires either issue_id or project_id, and hours') but lacks guidance on when not to use or alternatives. No mention of when to use update_time_entry or delete_time_entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new user in Redmine. Requires admin privileges.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | User login name (required, unique) | |
| firstname | Yes | First name (required) | |
| lastname | Yes | Last name (required) | |
| Yes | Email address (required) | ||
| password | No | Password. Ignored if auth_source_id is set or generate_password is true | |
| auth_source_id | No | External authentication source ID (e.g., LDAP). Set to null for local auth | |
| mail_notification | No | Email notification preference: all, selected, only_my_events, only_assigned, only_owner, none | |
| must_change_passwd | No | Force the user to change password at next login | |
| generate_password | No | Generate a random password automatically | |
| status | No | User status: 1=active, 2=registered, 3=locked | |
| admin | No | Whether the user has admin privileges | |
| language | No | User language preference (e.g., en, es, fr) | |
| custom_fields | No | Custom field values | |
| send_information | No | Send account information email to the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the admin privilege requirement. It does not mention side effects (e.g., email sending), success/error behavior, or default values for parameters like status or password generation. Significant gaps exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the core purpose and a key requirement. It is front-loaded and efficient, though it could be slightly expanded to cover more behavioral context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, no output schema, no annotations), the description is insufficient. It fails to explain return values, default behaviors, error conditions, or the role of optional parameters like status or send_information. The agent would lack critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning or context beyond the tool purpose, thus providing no extra value for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and the resource ('a new user in Redmine'), which distinguishes it from sibling tools like update_user or delete_user. However, it does not explicitly differentiate from other creation tools (e.g., create_project), but the resource is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires admin privileges,' which is a prerequisite, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., update_user). The context of sibling names implies differentiation, but no 'when-to-use' or 'when-not-to-use' is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new version (milestone) in a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required | |
| name | Yes | Version name (required) | |
| status | No | Version status: open, locked, or closed (default: open) | |
| sharing | No | Sharing scope: none, descendants, hierarchy, tree, or system (default: none) | |
| due_date | No | Due date in YYYY-MM-DD format | |
| description | No | Version description | |
| wiki_page_title | No | Associated wiki page title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the creation action without disclosing behavioral traits like idempotency, prerequisites (e.g., project existence), or side effects. The mention of 'milestone' adds a synonym but little behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, and no fluff. However, it is very short and could include more useful context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no explanation of return values or typical behavior. With 7 parameters and many sibling tools, the description lacks completeness for an agent to fully understand invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 7 parameters. The tool description adds no additional meaning beyond what the schema provides, scoring baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Creates a new version (milestone) in a project', specifying the verb and resource. It distinguishes from sibling tools like delete_version, update_version, get_version, and list_project_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., update_version). The description does not mention any context, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a sprint from a project. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| sprint_id | Yes | Numeric sprint ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. States 'deletes' (destructive) but does not disclose effects like cascade, reversibility, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence. Front-loaded. However, it omits crucial behavioral details, so not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, description should at least mention what the tool returns (status) or error conditions. It does not, leaving agents guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Deletes a sprint from a project.' This is a specific verb-resource combination. While there are sibling sprint tools, the verb 'delete' distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions plugin requirement ('Requires the RedmineUP Agile plugin'). No guidance on when to use vs. alternatives (e.g., updating or archiving a sprint).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an attachment by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric attachment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive operation but does not disclose additional behavioral traits like reversibility, permissions required, or cascading effects. With no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is mostly complete. Could mention irreversibility, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no new meaning beyond 'by its ID'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('deletes'), resource ('attachment'), and identifier ('by its ID'). It distinguishes from sibling tools like 'update_attachment' and other delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as updating or listing attachments. No prerequisites or when-not-to-use conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a group permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric group ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'permanently' to indicate irreversibility, but does not disclose effects on group members, associated data, or required authorization, leaving important 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but could be slightly expanded for completeness without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 lacks context about side effects (e.g., user membership, cascade deletion) and return behavior. Adequate for the simple parameter set but incomplete for safe agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with a clear description for 'id'. The tool description adds no additional meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies 'Deletes a group permanently' using a clear verb and resource, distinguishing it from sibling tools like create_group and update_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as checking if the group is in use or if deletion requires certain permissions. No explicit context for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an issue permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions 'permanently' implying irreversibility, but lacks details on permissions, side effects, or consequences of deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with no annotations and a simple schema, the description only states permanence. It lacks context about confirmations, dependencies, or what happens after deletion, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single required parameter 'id' with a description. The tool description adds no extra semantic value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'deletes' and the resource 'issue', and adds 'permanently' for emphasis. However, it does not differentiate from sibling deletion tools like delete_project or delete_wiki_page beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no preconditions, exclusions, or context for usage beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an issue category. Optionally reassigns its issues to another category.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue category ID to delete (required) | |
| reassign_to_id | No | Numeric category ID to reassign issues to before deletion |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavioral traits. It mentions deletion and optional reassignment but omits critical details like error handling, permission requirements, or consequences of deleting a category with unmoved issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two clear, front-loaded sentences with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers its core purpose and optional behavior. However, it lacks information on error cases and specific behavior when reassign_to_id is omitted, but overall it's near complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 explains both parameters. The description adds minimal extra meaning beyond restating the option to reassign issues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes an issue category' with a specific verb and resource. It also mentions optional reassignment, which differentiates it from siblings like create_issue_category or update_issue_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for deleting categories but provides no explicit guidance on when to use it vs alternatives (e.g., updating a category instead). It also doesn't advise when to use the reassignto_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes an issue relation.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric relation ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that it deletes a relation. It does not disclose whether the operation is idempotent, if it errors on nonexistent relations, or any side effects. With no annotations, the description carries the full burden but fails to provide sufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, grammatically correct sentence with no redundant words. However, it may be too brief for a delete operation, lacking important details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no output schema, no annotations), the description is minimally adequate but does not cover safety or existence checks. It is incomplete in terms of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter 'id' as 'Numeric relation ID to delete' (100% coverage). The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes an issue relation' clearly states the verb (deletes) and the resource (issue relation). The tool name also matches, and it distinguishes itself from sibling delete tools by specifying the object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like deleting an issue or a relation type. There is no mention of prerequisites or scenarios where this action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes a membership (user/group) from a project.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric membership ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only states action without disclosing side effects (e.g., irreversibility), required permissions, or impact on related entities. With no annotations, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no extraneous words. Efficiently conveys core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple deletion tool with one parameter and no output schema. Could mention that deletion is permanent or requires specific permissions, but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds no extra meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Removes' and specific resource 'membership (user/group) from a project'. Distinguishes from sibling tools like add_user_to_group and update_membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as remove_user_from_group. Lacks any context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a project and all its related data (issues, wiki, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses cascading deletion of related data, which is helpful. However, it omits critical behavioral traits such as irreversibility, required permissions, or potential restrictions on deleting projects with active dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates core purpose, though adding a note on irreversibility would not significantly reduce conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers the main effect and cascading impact, but lacks mention of irreversibility and potential authorization requirements. Given the presence of a related sibling (archive_project), more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description does not add any additional meaning to the 'id' parameter beyond what is already in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Deletes' and the specific resource 'project', and differentiates by mentioning deletion of related data (issues, wiki). This distinguishes it from sibling tools like archive_project or other delete tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when wanting to remove a project permanently, but it does not provide explicit guidance on when to use versus alternatives (e.g., archive_project), nor does it mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a time entry permanently.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric time entry ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'permanently' discloses irreversibility, which is a key behavioral trait given no annotations. However, it does not mention other behavioral details such as permission requirements, side effects on related data (e.g., time entries linked to issues), or error states. With no annotations, the description bears full burden and is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no unnecessary words. The verb and action are front-loaded, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. The description omits return values (e.g., success indication, error messages) and does not address potential constraints like whether deletion is allowed if time entries are linked to issues. For a simple delete operation, the description 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema (100% coverage) already defines the single parameter 'id' with a clear description. The tool description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Deletes' and the resource 'time entry', with 'permanently' specifying irreversibility. It is distinct from sibling delete tools (e.g., delete_issue, delete_project) by naming the specific resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., different deletion contexts, prerequisites like existence of entry, or constraints). The description solely states what it does, not when 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.
Deletes a user permanently. Requires admin privileges.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric user ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that deletion is permanent and requires admin privileges, but it does not cover other behavioral aspects such as reversibility, cascading effects on associated data, or error conditions. With no annotations, the description carries the full burden, and while it addresses key points, it lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that immediately convey the tool's purpose and a critical requirement. Every sentence adds value with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 provides the essential information: deletion is permanent and requires admin privileges. However, it does not elaborate on implications like data loss or irreversible effects, which would be helpful for an agent to fully understand the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' is described in the input schema as 'Numeric user ID to delete'. The tool description does not add any additional meaning beyond what the schema already provides, so it adds no extra value. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool deletes a user permanently, which directly matches the tool name and distinguishes it from other deletion tools. It also specifies a key requirement (admin privileges).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that admin privileges are required, which provides some usage guidance, but it does not offer explicit when-to-use or when-not-to-use instructions, nor does it compare to alternative actions like deactivation 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.
Deletes a version.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric version ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Deletes a version.' without explaining what happens on deletion, authorization needs, or whether it cascades to related entities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise, the description is under-specified. It lacks critical details needed for an agent to use the tool safely, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should still explain the operation's impact. It fails to provide enough context about what a 'version' is or what happens after deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter as 'Numeric version ID to delete.' The description adds no additional meaning, context, or constraints beyond the schema, so it provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Deletes a version.' merely restates the tool name without specifying what kind of version (e.g., project version, software version) or providing any differentiation from other delete tools like delete_agile_sprint or delete_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites, side effects, or conditions for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a wiki page from a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| title | Yes | Wiki page title to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose whether deletion is permanent, if it requires specific permissions, or if there are cascading effects (e.g., on page versions). As a destructive action, more context is needed, especially given the absence 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but somewhat under-specified for a deletion tool. It is front-loaded but lacks necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and no output schema, the description fails to specify return behavior, success indicators, or operational constraints. The context is insufficient for an AI agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage for both parameters. Description adds no additional meaning beyond the schema, so it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (deletes), the resource (wiki page), and the scope (from a project). It effectively distinguishes from sibling delete tools like delete_issue or delete_project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as archiving or soft deletion. No mention of prerequisites or conditions for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a specific sprint. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| sprint_id | Yes | Numeric sprint ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the plugin requirement and that the tool 'gets details', but does not disclose any behavioral traits such as error handling, authentication needs, or side effects. For a read-only tool the disclosure 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (get by two IDs) and no output schema exists. The description covers the core action and a prerequisite, but does not hint at the structure of the returned details or behavior if the sprint is not found. This is adequate but could be improved to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters documented). The description does not add any additional parameter semantics beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Gets' and resource 'details of a specific sprint', differentiating it from sibling tools like list_agile_sprints (which lists) and assign_issue_to_sprint (which assigns). Also mentions the required plugin as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (need sprint details) but does not explicitly state when not to use or mention alternatives. The plugin requirement is a usage condition, but no guidance on choosing between this and list_agile_sprints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets metadata of an attachment by its ID (filename, filesize, content_type, content_url, author, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric attachment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It correctly identifies the operation as a read (gets metadata), but fails to mention error handling, permissions, or that it does not download the attachment file. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently communicates the core action and sample output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter retrieval tool without an output schema, the description is nearly complete. It specifies the input and lists example return fields. Minor omission: does not clarify that it only returns metadata, not the file content, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'id' described as 'Numeric attachment ID'). The description adds 'by its ID', which is redundant. No new semantic information beyond schema is provided for the parameter, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving metadata for a specific attachment by ID. It lists example metadata fields (filename, filesize, etc.), which distinguishes it from other get_* tools that retrieve different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool over siblings like get_issue or list_* tools, nor does it mention prerequisites or scenarios where it is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the details of the currently authenticated user (the API key owner).
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Comma-separated: memberships, groups, auth_source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses a read-only operation ('gets'), which is transparent. No additional behavioral traits are needed for this simple retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description is sufficient. It could optionally mention the return format, but the core purpose is well covered given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter 'include', which the schema already documents. The description adds no further semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'gets' and the resource 'details of the currently authenticated user', with the parenthetical specifying 'API key owner'. It implicitly distinguishes from the sibling 'get_user' which likely retrieves a different user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this tool is for the current user's details. While it doesn't explicitly say when not to use or mention the sibling 'get_user', the context is clear enough for an agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a group by its numeric ID. Can include users and memberships.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric group ID | |
| include | No | Include associated data: users, memberships |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic operation. It does not disclose read-only nature, authentication requirements, error handling, or any side effects. For a read operation, behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence (14 words), front-loaded with key information. Every word is purposeful with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description covers the core purpose but leaves out details about response structure or error cases. It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully describes parameters. The description adds minimal value by restating 'numeric ID' and the includes options. No additional meaning or constraints are provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Gets), resource (group), method (by numeric ID), and optional includes (users, memberships). It effectively distinguishes from sibling tools like create_group, delete_group, and list_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching a single group's details but provides no explicit guidance on when to use this tool versus alternatives like list_groups or other retrieval tools. No exclusions or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets full details of a single issue by its numeric ID, optionally including related data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue ID | |
| include | No | Comma-separated: attachments, relations, changesets, journals, watchers, allowed_statuses, children |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'full details' but does not disclose what fields are returned, permission requirements, rate limits, or potential side effects. The description is insufficient for an agent to understand the tool's behavior beyond a basic 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key functionality without extraneous words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the return structure or error behavior, which is important given the lack of an output schema. It hints at 'full details' but is vague. For a simple get operation, the context is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the input schema. The description adds minimal value by mentioning 'optionally including related data,' which corresponds to the include parameter, but does not elaborate on the specifics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'full details of a single issue by its numeric ID', which distinguishes it from sibling tools like list_issues or search that return multiple issues. The optional inclusion of related data is also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that the tool gets a single issue with optional related data, but it does not explicitly contrast with sibling tools like list_issues, search, or get_issue_agile_data. No guidance is given on when to use this versus 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.
Gets the agile fields (sprint, story points, position) of an issue. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID |
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 mentions the plugin requirement but does not explicitly state read-only status, authentication needs, or behavior when plugin is missing. 'Gets' implies read but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two front-loaded sentences, each adding value: the first states what the tool does, the second states a prerequisite. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the return format. It lists the fields but not structure, pagination, or error scenarios. Incomplete for a tool with a single parameter and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameter 'issue_id' is already described. The tool description adds no extra meaning beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets agile fields (sprint, story points, position) of an issue, specifying the resource and specific fields. It distinguishes from sibling get_issue by focusing on agile data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required plugin but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_issue. Usage is implied but not structured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a single issue category by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue category ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, required permissions, error behavior for missing ID, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 hint at return value structure (e.g., fields included). It only says 'details', which is vague. Error cases not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds no additional meaning beyond the schema's 'Numeric issue category ID'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets details' and the resource 'issue category'. It distinguishes itself from sibling tools like list_issue_categories (which lists all categories) and create/delete/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 list_issue_categories. The agent must infer usage 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.
Gets details of a single issue relation by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric relation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states 'gets details' without revealing idempotency, side effects, or other behavioral traits. Minimal disclosure for a 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers the basic purpose but lacks output details. Given no output schema, knowledge of return fields would be helpful. Adequate for simple retrieval but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already fully describes parameter 'id' as 'Numeric relation ID'. Description adds no extra meaning beyond 'by its ID'. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Gets details of a single issue relation by its ID' with specific verb and resource. Distinct from sibling tools like list_issue_relations (list all) and create/delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implied that it's for retrieving a single relation by ID, but no contrast with list_issue_relations or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a single project membership by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric membership ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action without disclosing behavioral traits such as error conditions, required permissions, or data scope. For a read operation, it lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description covers the essential purpose. It does not elaborate on return format or edge cases, but the tool's simplicity makes it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'id' as 'Numeric membership ID' with 100% coverage. The description adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets'), the resource ('details of a single project membership'), and the identifier ('by its ID'). It distinguishes from sibling tools like list_project_memberships and delete_membership.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single membership but provides no explicit guidance on when to use this tool versus listing memberships or other alternatives. No when-not or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the account details of the currently authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not state that the operation is read-only, nor does it describe what 'account details' includes or whether authentication is required (though implied). Important behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, brief sentence that conveys the essential information without any redundant words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description provides basic functionality. However, it lacks detail on the expected output format or differences from similar tools like 'get_current_user', making it adequate but not fully complete for an agent to use correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema coverage is 100%. The description adds no further parameter information, but with zero parameters the baseline of 4 is justified. No additional explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (gets), resource (account details), and scope (currently authenticated user). It distinguishes itself from siblings like 'get_current_user' by indicating it returns account details rather than just basic user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool over alternatives such as 'get_current_user' or 'update_my_account'. The description does not mention prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a single news item by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric news ID | |
| include | No | Include additional data: comments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'gets details' but does not specify what details are returned, whether the operation is read-only, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, effectively conveying the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not explain return values or any side effects. Given no output schema, it lacks completeness but is adequate for a simple get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters are described in the schema. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details of a single news item by ID, distinguishing it from sibling tools like list_all_news that return multiple items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as list_all_news or list_project_news. The description does not mention when not to use it or provide any context about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a project by its numeric ID or string identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID (numeric) or identifier (string) | |
| include | No | Comma-separated: trackers, issue_categories, time_entry_activities, enabled_modules, issue_custom_fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only fetch operation but does not disclose rate limits, authentication needs, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words or information. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 indicate the return format (e.g., project object). It only states 'Gets details', which is vague. For a simple tool with 2 params, it's minimally adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond what the schema already provides (e.g., id type, include options). No extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Gets' and the resource 'details of a project', specifying two types of identifiers (numeric ID or string identifier). It distinguishes from sibling tools like list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_projects, other get_* tools). The context is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a role by its ID, including its list of permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric role ID |
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 the tool is a read operation ('Gets') and specifies the return includes details and permissions, providing adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 12 words, front-loading the purpose with no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no annotations), the description completely covers what the tool does and what it returns, without needing additional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter, with a clear description 'Numeric role ID'. The description adds 'including its list of permissions,' which relates to the output, not the parameter, so minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Gets details of a role by its ID, including its list of permissions.' It uses a specific verb and resource, and distinguishes itself from sibling tools like list_roles by explicitly referencing the ID parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a role ID is available, but it does not explicitly mention when not to use it or suggest alternatives like list_roles for listing all roles without an ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a single time entry by its numeric ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric time entry ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read operation but does not specify behavior on missing ID, required permissions, or any side effects. This is a gap for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no extraneous words. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no nested objects), the description adequately covers the core purpose. However, it could mention expected return behavior or error handling for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter (id). The description adds no additional meaning beyond what the schema already provides ('Numeric time entry ID'), so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Gets details') and the resource ('single time entry'), along with the key identifier ('numeric ID'). This distinguishes it from sibling tools like list_time_entries (list) and create_time_entry (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single time entry by ID but provides no explicit guidance on when to use or avoid this tool versus alternatives. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a user by their numeric ID. Can include memberships and groups.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric user ID | |
| include | No | Comma-separated: memberships, groups, auth_source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'Gets details', implying a read operation, but offers no information on error conditions, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 14 words is front-loaded and to the point. No redundancy, but could be slightly more structured by separating the include info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with 2 parameters and no output schema, the description covers the core purpose and optional includes. Missing details on return value structure and error handling, but adequate given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. The description echoes the include parameter by listing options, but adds no new meaning beyond what the schema provides. Baseline is 3 because schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Gets', resource 'user', and scope 'by their numeric ID'. It also mentions optional inclusion of memberships/groups, distinguishing it from sibling tools like list_users or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for fetching a specific user's details, but does not exclude cases like listing all users or updating users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a single version by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric version ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'gets details' without disclosing behavioral traits such as read-only nature, required permissions, rate limits, or side effects. Minimal insight into what the tool does beyond its 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Ultra-concise single sentence with no fluff. Every word is necessary and informative. Structure is optimal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. Description does not specify what 'details' are returned, which data fields to expect, or pagination/extensibility. For a simple get-by-ID tool, it lacks context about response shape and completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with a single parameter 'id' described as 'Numeric version ID'. Description adds no extra meaning beyond schema, but schema coverage is high, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Gets details') and the resource ('version'), and includes the scope ('by its ID'). It effectively distinguishes from sibling tools like list_project_versions (which retrieves all) and create_version (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_issue or get_project. No context about prerequisites, constraints, or when not to use it. The description merely states function without usage strategy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the content of a wiki page by its title. Returns the page text in Textile/Markdown format.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| title | Yes | Wiki page title (used as slug in the URL) | |
| include | No | Include additional data: attachments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the return format detail but does not disclose authentication requirements, error handling, or limitations. The read-only nature is implied but not stated explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information. The action is front-loaded: 'Gets the content of a wiki page by its title.'
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description covers the return format and uses the title for lookup. It misses mentioning the optional 'include' parameter for attachments, but the schema covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no new meaning beyond 'by its title' matching the title parameter. This meets the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves wiki page content by title and specifies the return format (Textile/Markdown). This distinguishes it from siblings like list_wiki_pages or get_wiki_page_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives like list_wiki_pages or get_wiki_page_version. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets a specific version of a wiki page. Useful for viewing page history.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| title | Yes | Wiki page title | |
| version | Yes | Version number of the wiki page | |
| include | No | Include additional data: attachments |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Gets', implying a read operation, but does not disclose permissions, side effects, or that it is read-only. This is minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and directly states the action and use case. No unnecessary words, though slightly more detail could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 data is returned. It does not mention return format or fields. The optional 'include' parameter (attachments) is not explained. The tool's purpose is clear but the description lacks completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters (100% coverage). The description adds no additional meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Gets' and the resource 'specific version of a wiki page', and implies its use for viewing history. It distinguishes from siblings like get_wiki_page (current version) and list_wiki_pages, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says 'Useful for viewing page history', which vaguely implies when to use. It does not specify when not to use, nor does it mention alternative tools like get_wiki_page or list_wiki_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all sprints of a project. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the plugin requirement, which is a behavioral constraint. However, with no annotations, it fails to disclose other aspects like read-only nature, pagination, or ordering of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences that convey essential information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description is somewhat complete. However, it lacks details about the return format, whether sprints are ordered, or any filtering capabilities, which are important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description in the schema is clear. The tool description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'lists all sprints of a project', but does not explicitly differentiate from sibling tools like get_agile_sprint (single sprint) or list_issues_by_sprint. It also mentions the plugin requirement, which is useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of when to prefer list_agile_sprints over get_agile_sprint or list_issues_by_sprint, nor any conditions like project membership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists news from all projects. Returns news with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions pagination but lacks behavioral details like rate limits, authentication, or what happens when no news exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with pagination, description covers core purpose and pagination. Could mention sorting or default order, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description adds nothing beyond schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly says 'Lists news from all projects' with pagination, which is specific and distinguishes it from 'list_project_news' which would be project-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'list_project_news'. Does not 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.
Lists all custom fields defined in Redmine. Requires administrator privileges.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions admin privilege requirement but lacks details on return format, pagination, or data limits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly efficient. No redundant information, front-loaded with purpose and permission.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and straightforward functionality, description covers essentials. Lacks mention of return value structure but sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema, and description does not need to add parameter info. Baseline of 4 for zero parameters with 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all custom fields in Redmine with a specific verb and resource. It is distinct from sibling tools like list_issues or list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly indicates when to use (listing custom fields) and a prerequisite (admin privileges). Does not explicitly exclude other contexts, but no ambiguity given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all document categories defined in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Lists') but does not explicitly disclose authentication needs, rate limits, or return format. With no annotations, the description provides minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is front-loaded and efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the essential purpose. However, it could hint at the return type (e.g., 'returns a list of category names') to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is empty. The description adds no parameter information, which is acceptable per baseline rules for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'document categories', making the tool's purpose unambiguous. It distinguishes from siblings like 'list_issue_categories' through the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool versus alternatives (e.g., list_issue_categories). The description simply states what it does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all groups in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose pagination behavior, default ordering, or rate limits. The minimal description leaves behavioral attributes undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 5 words conveys the core purpose with no extraneous information. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not indicate return format (e.g., JSON array of group objects). Fails to address pagination behavior despite input parameters suggesting it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in input schema). The description adds no additional meaning beyond what the schema provides, achieving baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and resource 'all groups', clearly indicating it returns a collection. It is distinct from sibling tools like 'get_group' (single group) and CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. For example, it doesn't mention that offset/limit allow pagination or that this is the primary way to retrieve all groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all issue categories of a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits like read-only nature, pagination, filtering capabilities, or authorization requirements. It merely states what it does without side-effect or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence, 7 words) but lacks essential guidance on usage and behavior, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description should still hint at return format or limitations. It does not, leaving gaps for an agent to understand the full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'project_id' with description identical to that in the tool description. Schema coverage is 100%, so the description adds no additional meaning beyond the schema, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and resource 'issue categories' with scope 'of a project', distinguishing it from siblings like 'get_issue_category' (single) and 'create_issue_category' (create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'get_issue_category' for a single category or 'create_issue_category' for adding. The description lacks context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all issue priorities defined in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Lists all issue priorities', making it clear this is a read-only, non-destructive operation with no side effects. Despite no annotations, the behavior is fully transparent for a parameterless 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, no output schema), the description is complete. It adequately explains the tool's purpose without missing critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description is not required to add parameter information. The baseline score of 4 is appropriate as the schema coverage is 100% and no param details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'issue priorities defined in Redmine', precisely identifying the tool's function and distinguishing it from other list tools like list_issue_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., list_issue_statuses, list_trackers). The description lacks contextual advice for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all relations of an issue.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID (required) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is minimal, failing to disclose behavioral traits like return format, pagination, error conditions, or side effects. The agent lacks critical information for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. While very brief, it fits the simple tool structure, though could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is insufficient. It does not explain what relations are, the format of the output, or any constraints, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter well at 100%, with a clear description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all relations of an issue, using a specific verb and resource. It distinguishes from sibling tools like create_issue_relation, delete_issue_relation, and get_issue_relation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_issue_relation for a single relation. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists issues in Redmine with advanced filters, sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) | |
| sort | No | Sort field and direction. Examples: status:asc, priority:desc, updated_on:desc. Multiple: status:asc,priority:desc | |
| include | No | Comma-separated: attachments, relations, changesets, journals, watchers, allowed_statuses, children | |
| issue_id | No | Filter by issue ID(s). Comma-separated or range. Examples: 1,2,3 | |
| project_id | No | Filter by project ID or identifier | |
| subproject_id | No | Filter by subproject. Use !* to exclude subproject issues | |
| tracker_id | No | Filter by tracker ID | |
| status_id | No | Filter by status. Values: open, closed, * (all), or numeric ID | |
| priority_id | No | Filter by priority ID | |
| assigned_to_id | No | Filter by assignee. Numeric ID or me for current user | |
| author_id | No | Filter by author ID | |
| category_id | No | Filter by issue category ID | |
| fixed_version_id | No | Filter by target version ID | |
| parent_id | No | Filter by parent issue ID | |
| subject | No | Filter by subject. Use ~ prefix for contains: ~keyword | |
| created_on | No | Filter by creation date. Examples: >=2024-01-01, <=2024-12-31, ><2024-01-01|2024-12-31 | |
| updated_on | No | Filter by last updated date. Same format as created_on |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'lists issues' without mentioning read-only, permissions, rate limits, or side effects. The lack of detail leaves the agent underinformed about non-obvious behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words, but it is very brief. It could be expanded slightly to improve completeness without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 18 optional parameters and no output schema or annotations, the description is too minimal. It fails to explain the output format, provide examples, or set expectations about default behavior or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented. The description adds no additional parameter context beyond what the schema provides, so baseline 3 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists issues in Redmine, with advanced filters, sorting, and pagination. It distinguishes from siblings like get_issue (single issue) and search (broader) by specifying the resource and capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives such as search or list_issues_by_sprint. The description implies using it for filtered listing but does not provide when-not-to-use or contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all issues assigned to a specific sprint. Uses the RedmineUP Agile plugin filter. More efficient than list_issues when you need to filter by sprint.
| Name | Required | Description | Default |
|---|---|---|---|
| sprint_id | Yes | Numeric sprint ID (required) | |
| project_id | No | Filter by project ID or identifier (recommended to narrow results) | |
| status_id | No | Filter by status. Values: open, closed, * (all), or numeric ID | |
| limit | No | Number of items per page (default 25, max 100) | |
| offset | No | Number of items to skip (default 0) | |
| sort | No | Sort field and direction. Examples: status:asc, priority:desc | |
| include | No | Comma-separated: attachments, relations, journals, watchers, children |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavior. It mentions the use of a plugin filter, but does not disclose side effects, authentication needs, or behavior for missing sprints. For a read-like operation, this is acceptable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states the core purpose, the second adds efficiency context and plugin detail. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers the purpose, efficiency, plugin dependency, and parameters are fully described in schema. Minor gaps: no mention of auth or error states, but adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds value by noting the plugin dependency, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all issues assigned to a specific sprint, using a specific plugin filter. It distinguishes itself from the sibling 'list_issues' by mentioning better efficiency for sprint filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'More efficient than list_issues when you need to filter by sprint,' providing clear guidance on when to use this tool over the alternative. It does not list exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all issue statuses defined in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the burden. It states 'lists all issue statuses,' which implies a read operation, but it does not disclose additional behavioral traits such as pagination, authorization requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the tool's purpose without any wasted words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no annotations), the description is nearly complete. It could potentially mention the return format, but the lack of this detail does not significantly impair understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage (empty object), there is nothing to add. Per guidelines, baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'lists' and identifies the resource as 'issue statuses defined in Redmine,' which clearly distinguishes it from sibling tools like list_issues or list_trackers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., when to use list_issue_statuses instead of list_issues or list_issue_priorities). Usage must be inferred from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all files attached to a project (available since Redmine 3.4).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only states the basic function, omitting details like authentication requirements, pagination, or whether it returns all files. This is a significant gap for a listing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence that immediately states the purpose. No redundant or extraneous information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate but lacks details on return format or pagination. It meets the minimum for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter fully (100% coverage), and the description does not add further meaning. Baseline 3 is appropriate as the description does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists all files attached to a project', specifying the action and resource. It also includes a version note for context, effectively distinguishing it from sibling tools like 'list_issues' or 'list_project_versions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives, such as when to use 'create_project_file' or search tools. The version mention is helpful but insufficient for guiding selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all memberships (users/groups with roles) of a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required | |
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not mention permissions, pagination behavior (though schema has offset/limit), or the structure of returned data. Lacks context like whether it returns all memberships or just active ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that efficiently conveys purpose. No unnecessary words. Structure is appropriate for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 provides minimal context. It explains what the tool does but omits details about return format, sorting, or any side effects. Adequate for a basic list operation but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description adds no additional meaning beyond schema. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it lists memberships (users/groups with roles) for a project. Clear verb and resource, distinct from siblings like get_membership (single) and create/delete/update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_membership. The existence of siblings implies differentiation but it is not stated. Implicit that it lists all memberships for a project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists news of a specific project with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral traits. Only 'pagination' is mentioned. Missing details on ordering, authentication requirements, or whether it returns all news or recent ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence that captures the core functionality. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool, but lacks details on output format, sorting, or whether it returns metadata like total count. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds 'pagination' context, but this is already implied by the offset/limit parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists news for a specific project with pagination. It distinguishes from sibling tools like 'list_all_news' by scoping to a project, but does not explicitly contrast with 'get_news' or 'create_news'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., 'list_all_news' for global news). No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all projects in Redmine with pagination and optional filters.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) | |
| include | No | Comma-separated: trackers, issue_categories, time_entry_activities, enabled_modules, issue_custom_fields | |
| status | No | Filter by status. Values: 1=active, 5=closed. Operators: = (default), ! (not equal). Examples: 1, 1|5, !1 | |
| id | No | Filter by project ID. Special values: mine, bookmarks. Examples: 1|2|3, mine | |
| name | No | Filter by project name. Operators: ~ (contains), !~ (not contains), ^ (starts with), $ (ends with) | |
| description | No | Filter by description. Operators: ~ (contains), !~ (not contains), ^ (starts with), $ (ends with) | |
| parent_id | No | Filter by parent project. Operators: = (default), ! (not equal), * (any=subproject), !* (none=root). Values: ID, mine, bookmarks | |
| is_public | No | Filter by public/private: 1=public, 0=private | |
| created_on | No | Filter by creation date. Examples: >=2024-01-01, t (today), >t-7 (last 7 days), lm (last month) | |
| updated_on | No | Filter by last updated date. Same format as created_on |
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 mentions pagination and filters but does not disclose any destructive actions, authentication requirements, rate limits, or details about the return data. It is a read operation but not explicitly marked as such.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without unnecessary words. It could slightly benefit from mentioning that it returns a list or notes about the default ordering, but it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 tool's purpose and key features adequately for a listing tool. It could include more context about the response format or default behavior, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no additional meaning beyond what the schema already provides by simply stating 'optional filters' without elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists', the resource 'all projects in Redmine', and key features 'with pagination and optional filters'. This distinguishes it from sibling tools like get_project or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing projects with filters and pagination but does not explicitly mention when to use this tool versus alternatives like search_in_project or get_project. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all versions (milestones) of a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string). Required |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like pagination, permissions required, or ordering. Minimal info for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded verb, no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with one parameter and no output schema. Lacks info on response structure or pagination, but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with a description of project_id. Description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and what is being listed (versions/milestones of a project). It distinguishes from siblings like get_version (single) and create/update/delete versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_version for a single version). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all saved (public and private) queries in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read-only operation but does not disclose any additional traits such as pagination, ordering, or performance characteristics. Basic purpose is clear but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the key information. Every word is warranted and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is mostly complete for a simple list tool. It explains what is returned (all saved queries) but could be slightly more precise about the scope within Redmine. Still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. According to guidelines, baseline is 4 even with no parameter info. The description adds no param details as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Lists' and clearly identifies the resource 'saved (public and private) queries in Redmine'. It distinguishes itself from sibling tools as the only tool for listing queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. Usage is implied as it is a straightforward list operation, but the description lacks when-not or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all roles defined in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks details on behavior (e.g., pagination, authentication requirements, or side effects). With empty annotations, description should compensate but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but at the expense of informational content. Not verbose, but lacks structure like bullet points or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is minimally adequate. It covers purpose but omits scope (e.g., system-wide roles, permissions required).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no value beyond the empty schema (coverage 100%). Baseline score of 3 is appropriate as there is no need for additional parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the action ('Lists all roles') and the resource ('roles defined in Redmine'). This clearly differentiates from sibling 'get_role' which fetches a single role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use 'list_roles' versus alternatives like 'get_role'. Does not mention any prerequisites or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists time entries in Redmine with optional filters by user, project, issue, activity and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) | |
| user_id | No | Filter by user ID | |
| project_id | No | Filter by project ID or identifier | |
| issue_id | No | Filter by issue ID | |
| activity_id | No | Filter by activity ID | |
| spent_on | No | Filter by spent date. Examples: >=2024-01-01, ><2024-01-01|2024-12-31, t (today), lw (last week) | |
| from | No | Filter entries from this date (YYYY-MM-DD) | |
| to | No | Filter entries up to this date (YYYY-MM-DD) |
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 only mentions listing with filters, omitting pagination behavior (offset/limit), sorting, or any side effects. Minimal transparency for a list tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence that front-loads the action ('Lists time entries') and then lists filters. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (9 params, pagination), the description is adequate but missing details on return format, sorting defaults, and pagination behavior. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; each parameter has a description. The description repeats filter dimensions but doesn't add semantic nuance beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists time entries' and enumerates the optional filter dimensions (user, project, issue, activity, date range). It distinguishes well from sibling tools like get_time_entry (single entry) and create_time_entry (create operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_time_entry or when pagination is needed. The description implies filtering context but lacks when-not or performance considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all time entry activities defined in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as response format, pagination, or authentication requirements. Since no annotations are present, the description carries full responsibility but offers minimal information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the action and resource, containing no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, yet the description does not explain what fields or data are returned. For a list operation, agents need to know if results include IDs, names, or other attributes to use them downstream.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the baseline is 4. The description does not add meaning beyond the schema, but this is acceptable given the parameterless design.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'all time entry activities' in Redmine, using a specific verb and resource. It effectively distinguishes from sibling tools like 'list_time_entries' or 'list_trackers' by focusing on activity types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'list_time_entries' or 'list_issue_statuses'. The description lacks context for its typical use case, e.g., retrieving options for creating time entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all trackers available in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with no side effects, but it does not disclose any behavioral details beyond that, such as whether the list is paginated or sorted. Annotations are absent, so the description carries the full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that is front-loaded with the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is nearly complete. However, it lacks detail on what information is returned (e.g., tracker IDs and names).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds no additional parameter information, but none is needed. Baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lists) and the resource (all trackers available in Redmine). It distinguishes itself from sibling tools, as no other tool lists trackers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 other list_* tools. The description does not mention prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists users in Redmine with optional filters. Requires admin privileges.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) | |
| include | No | Comma-separated: auth_source | |
| status | No | Filter by status. Values: 1=active, 2=registered, 3=locked. Operators: = (default), ! (not equal). Examples: 1, 1|2, !3 | |
| name | No | Filter by name, login, or email (contains search). Examples: john, admin | |
| group_id | No | Filter by group membership. Value is the group ID | |
| login | No | Filter by login. Operators: ~ (contains), = (exact), ! (not equal), ^ (starts with), $ (ends with) | |
| firstname | No | Filter by first name. Operators: ~ (contains), = (exact), ! (not equal), ^ (starts with), $ (ends with) | |
| lastname | No | Filter by last name. Operators: ~ (contains), = (exact), ! (not equal), ^ (starts with), $ (ends with) | |
| No | Filter by email address. Operators: ~ (contains), = (exact), ! (not equal), ^ (starts with), $ (ends with) | ||
| admin | No | Filter by admin privilege: 1=admin, 0=non-admin | |
| auth_source_id | No | Filter by authentication source. Operators: = (default), ! (not equal), * (any), !* (none) | |
| twofa_scheme | No | Filter by two-factor authentication scheme. Operators: = (default), ! (not equal), * (any), !* (none) | |
| created_on | No | Filter by creation date. Examples: >=2024-01-01, >t-30, lm | |
| last_login_on | No | Filter by last login date. Examples: >=2024-01-01, >t-30, !* (never logged in) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides the admin privilege requirement but no other behavioral traits (e.g., pagination limits, response format, rate limiting). Schema covers parameters, so the gap is in behavioral context beyond params.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose. Could be improved by including more behavioral info in the same space, but it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, no output schema, and many sibling tools, the description is too sparse. It lacks context on return format, pagination, error handling, or typical usage patterns. Inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no parameter semantics beyond what the schema already provides. No added value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists users with optional filters and requires admin privileges. The verb and resource are specific. However, it does not explicitly differentiate from siblings like search or list_groups, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions admin requirement. No guidance on when to use vs alternatives, no exclusions, and no context on prerequisites beyond admin. The agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all wiki pages (index) of a project. Returns titles, versions and dates.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the output includes titles, versions, and dates, but does not mention if it includes all versions or just current, the meaning of 'dates', any permissions required, or whether the operation is read-only. It hints at read nature but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that effectively conveys purpose and return data. No redundant information. Perfectly concise while covering key aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally complete for a simple list tool, but lacks details like pagination, ordering, inclusion of archived pages, or any filtering capabilities. With no output schema, the return format is partially described but not fully. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (project_id described as 'Project ID (numeric) or identifier (string)'). The description adds no additional semantic value beyond the schema; it merely restates the parameter's role in listing pages of a project. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all wiki pages of a project and returns titles, versions, and dates. This distinguishes from siblings like get_wiki_page (single page) and get_wiki_page_version (specific version). However, it does not explicitly differentiate from other list tools like list_projects or list_agile_sprints, though context suggests it's for wiki pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios where this tool is preferred over get_wiki_page, get_wiki_page_version, or other list tools. Implied usage only from 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.
Removes a user from a group.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Numeric group ID | |
| user_id | Yes | Numeric user ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It only states the basic action, omitting side effects, permission requirements, error handling (e.g., if user not in group), or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (6 words) and front-loaded. Every word is necessary, but it could benefit from a brief note on behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and full schema coverage, the description is minimally adequate. However, it lacks details on return type, error conditions, or side effects, which is expected for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description. The tool description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action of removing a user from a group, with a specific verb and resource. However, it does not differentiate itself from the sibling tool 'add_user_to_group', which is its direct inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'remove_watcher' or 'delete_membership'. There is no mention of prerequisites like the user being a member of the group.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Removes a user from the watchers of an issue.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Numeric issue ID | |
| user_id | Yes | User ID to remove from watchers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds no behavioral context beyond the tool's name. It does not disclose side effects, permissions needed, or behavior when the user is not a watcher.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core action efficiently. It could be slightly more informative but is appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward removal tool with no output schema and no annotations, the description covers the basic action. However, it lacks details on whether the user must be an active watcher or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions are already present. The tool description adds no extra meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Removes a user from the watchers of an issue.' It distinguishes from sibling 'add_watcher' by its name, but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Sibling tools like 'add_watcher' exist but are not mentioned. There is no context about prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a global search across all Redmine resources (issues, news, documents, changesets, wiki pages, messages, projects).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query string (required) | |
| scope | No | Search scope: 'all' (default), 'my_projects', 'subprojects' | |
| all_words | No | If true, all words must match. If false, any word. Default true | |
| titles_only | No | If true, search only in titles. If false, search in content too | |
| issues | No | Include issues in search results (default true) | |
| news | No | Include news in search results | |
| documents | No | Include documents in search results | |
| changesets | No | Include changesets in search results | |
| wiki_pages | No | Include wiki pages in search results | |
| messages | No | Include forum messages in search results | |
| projects | No | Include projects in search results | |
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the scope and lists resources but fails to disclose behavioral traits such as read-only nature, auth requirements, rate limits, search algorithm details (e.g., case sensitivity), or pagination behavior beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that clearly communicates the tool's function without redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters and no output schema, the description provides minimal context. It does not explain search behavior (e.g., tokenization, relevance), result format, or pagination details. For a complex search tool, more completeness is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description adds no extra meaning beyond listing resource types, which are already parameters. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'global search across all Redmine resources' and lists the specific resource types (issues, news, documents, etc.). This distinguishes it from sibling tool 'search_in_project', which is scoped to a single project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives like 'search_in_project'. The description does not mention contexts where global search is appropriate or where it is not, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches within a specific project's scope (issues, wiki pages, news, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| q | Yes | Search query string (required) | |
| scope | No | Search scope: 'all' (default), 'my_projects', 'subprojects' | |
| all_words | No | If true, all words must match. If false, any word. Default true | |
| titles_only | No | If true, search only in titles. If false, search in content too | |
| issues | No | Include issues in search results (default true) | |
| news | No | Include news in search results | |
| documents | No | Include documents in search results | |
| changesets | No | Include changesets in search results | |
| wiki_pages | No | Include wiki pages in search results | |
| messages | No | Include forum messages in search results | |
| projects | No | Include projects in search results | |
| offset | No | Number of items to skip (default 0) | |
| limit | No | Number of items per page (default 25, max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as being read-only, side effects, or permissions required. For a search tool, it's likely read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and to the point. It could be slightly more structured but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 14 parameters, 2 required, and no output schema, the description is too minimal. It does not mention required parameters, pagination, result format, or behavior when no results are found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all 14 parameters. The description adds no additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'searches', the resource 'within a specific project's scope', and lists example content types (issues, wiki pages, news). This distinguishes it from the sibling 'search' tool which is likely global.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for project-scoped search but does not explicitly state when to use this tool over alternatives like 'search' 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.
Unarchives a previously archived project.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID (numeric) or identifier (string) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the unarchive action but omits side effects like required permissions, consequences of unarchiving, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, concise, and no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema), the description is adequate but could mention return value or failure handling. Still sufficient for a simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Project ID (numeric) or identifier (string)'. The description adds no extra meaning; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unarchives a previously archived project' clearly states the action (unarchives) and the resource (project), distinguishing it from sibling 'archive_project'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when project is archived) but lacks explicit guidance on prerequisites or when not to use (e.g., project already active). No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing sprint. Requires the RedmineUP Agile plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | Project ID (numeric) or identifier (string) | |
| sprint_id | Yes | Numeric sprint ID | |
| name | No | New sprint name | |
| start_date | No | Sprint start date (DD.MM.YYYY) | |
| end_date | No | Sprint end date (DD.MM.YYYY) | |
| status | No | Sprint status | |
| sharing | No | Sprint sharing setting |
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 'updates an existing sprint' without detailing permissions, side effects, or validation. The plugin note is useful but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no fluff. Every word serves a purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter update tool with no output schema and no annotations, the description is brief. It covers the essential action and plugin dependency but lacks details on return values or full behavioral context, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing sprint, distinguishing it from siblings like create_agile_sprint (create) or delete_agile_sprint (delete). The plugin requirement is specified, adding precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a plugin requirement but does not provide explicit guidance on when to use versus alternatives or when not to use. It is implied for modifying sprints, but lacks exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates metadata of an attachment (filename, description). Only available since Redmine 3.4.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric attachment ID | |
| filename | No | New filename for the attachment | |
| description | No | New description for the attachment |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions the action and version requirement, without disclosing side effects, permissions needed, or error handling (e.g., what happens if the attachment does not exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and a version constraint. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is too minimal. It does not explain return behavior, partial vs full updates, or error conditions, leaving gaps for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description reaffirms the fields but adds no new meaning beyond the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('updates metadata') and the resource ('attachment'), specifying the fields affected (filename, description). This distinguishes it from sibling tools like delete_attachment, get_attachment, and upload_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for modifying attachment metadata, which is distinct from other attachment operations. However, it does not explicitly state when to use it vs alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing group.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric group ID to update (required) | |
| name | No | New group name | |
| user_ids | No | Array of user IDs. Replaces all current group members |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely states 'Updates an existing group' without disclosing behavioral traits such as mutation, replacement of user_ids, or required permissions. Since no annotations are provided, the description should fill this gap but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and concise. However, it could include a bit more context (e.g., what fields can be updated) without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool mutates data and has no annotations or output schema, the description should provide more context, such as success/failure behavior, side effects, or permissions. It is incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is well-documented in the schema. The description adds no extra semantics beyond what the schema provides, meeting baseline expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Updates an existing group' uses a specific verb and resource, clearly distinguishing from sibling tools like create_group (creates) and delete_group (deletes). It leaves no ambiguity about the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool vs alternatives (e.g., add_user_to_group for adding a user without replacing all members). There is no mention of prerequisites, such as the group needing to exist, or when updates are not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing issue. Can change fields, add notes/comments, or change status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue ID to update (required) | |
| project_id | No | Move issue to another project | |
| subject | No | Issue subject / title | |
| tracker_id | No | Tracker ID | |
| status_id | No | Status ID | |
| priority_id | No | Priority ID | |
| description | No | Issue description | |
| category_id | No | Issue category ID | |
| fixed_version_id | No | Target version ID | |
| assigned_to_id | No | Assignee user ID | |
| parent_issue_id | No | Parent issue ID | |
| custom_fields | No | Custom field values | |
| is_private | No | Whether the issue is private | |
| estimated_hours | No | Estimated hours | |
| done_ratio | No | Percentage done (0-100) | |
| start_date | No | Start date (YYYY-MM-DD) | |
| due_date | No | Due date (YYYY-MM-DD) | |
| notes | No | Comment/note to add to the issue (visible in journal) | |
| private_notes | No | Whether the note is private | |
| uploads | No | Attachments (requires prior upload to get tokens) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden but only states basic purpose. Does not disclose side effects (e.g., journal creation), permission requirements, or behavior of partial updates. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. Could benefit from structured formatting given the complexity (20 params), but the conciseness itself is not a flaw. Slightly under-characterized for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 20 parameters, no output schema, and no annotations, the description is too sparse. Missing: return value details, prerequisites (issue must exist), confirmation of partial updates, and any rate limits or safety considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions already document each parameter. The tool's description adds broad categorization ('fields, notes/comments, status') but does not provide specific insights beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'updates' and resource 'issue', with examples of what can be changed (fields, notes, status). However, it does not differentiate from sibling update tools like update_issue_category or update_journal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., update_journal for journal updates, update_project for project-level changes). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing issue category.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric issue category ID to update (required) | |
| name | No | New category name | |
| assigned_to_id | No | Numeric user ID to auto-assign issues in this category |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'updates' without disclosing side effects, idempotency, or required permissions. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. Highly concise, though at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with 3 params and no output schema, the description lacks details on return values, error handling, or what happens on failure. Incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description does not add additional meaning beyond the schema, but the baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates an existing issue category' with a specific verb and resource, and distinguishes from sibling tools like create, delete, get, and list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., create_issue_category, delete_issue_category). No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the notes of an issue journal entry (comment). Requires the user to be the author or an admin.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric journal ID | |
| notes | Yes | New text for the journal note |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses permission requirement, but lacks details on side effects, error handling, or reversibility. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Front-loaded with purpose and condition. Could be slightly more structured but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 2 parameters, no output schema, no annotations. Description covers purpose and permission but misses potential error cases or response format. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so schema already documents both parameters. Description does not add parameter-specific info beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Updates the notes of an issue journal entry (comment)' – specific verb and resource. Among many update_* tools, this uniquely identifies journal entry updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a clear condition: 'Requires the user to be the author or an admin.' This tells the agent when the tool is permissible. No explicit alternatives or when-not-to-use, but the condition is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the roles of an existing project membership.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric membership ID to update (required) | |
| role_ids | Yes | New array of role IDs (required, replaces current) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states 'updates roles' without mentioning that the role array replaces existing roles, or any destructive or authentication aspects. The minimal text adds little 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and does not fully earn its place by providing sufficient clarity. It is adequate but not optimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no behavioral details, the description is incomplete. It omits important context such as the effect of replacing roles, required permissions, or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not add any extra meaning beyond the schema's parameter descriptions; it merely restates 'updates roles' without elaborating.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'updates the roles of an existing project membership,' specifying the verb (updates) and resource (project membership), distinguishing it from sibling tools like 'create_project_membership' and 'delete_membership'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'add_user_to_group' or 'create_project_membership'. The description lacks 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.
Updates the account details of the currently authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
| firstname | No | First name | |
| lastname | No | Last name | |
| No | Email address | ||
| language | No | Language preference (e.g., en, es, fr) | |
| custom_fields | No | Custom field values | |
| mail_notification | No | Email notification preference: all, selected, only_my_events, only_assigned, only_owner, none | |
| notified_project_ids | No | Project IDs for email notifications (only when mail_notification=selected) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'updates' but doesn't disclose auth requirements, idempotency, or what happens on partial updates. Minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence efficiently conveys the purpose. No fluff, but could benefit from slightly more structure (e.g., bullet points) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 7 optional parameters and no output schema, yet the description provides no context about update constraints, error conditions, or behavior. Incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 no additional meaning beyond the schema, so it stays at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates account details of the currently authenticated user, which is specific and distinct from sibling tools like update_user (which updates other users).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., update_user). No mention of prerequisites 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.
Updates an existing news item.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric news ID | |
| title | No | Updated news title | |
| description | No | Updated news body/content | |
| summary | No | Updated summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It simply says 'updates' without detailing how updates work (e.g., partial vs full replacement, idempotency, side effects). This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no wasted words. However, it is overly terse and lacks detail, but for conciseness, it is not verbose. Slight deduction for minimalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations or output schema, the description should provide more context (e.g., what happens if the ID doesn't exist, whether other fields remain unchanged). The current description is incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The description adds no extra meaning beyond listing 'id', 'title', 'description', 'summary' as updateable fields. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'updates' and the resource 'existing news item', which distinguishes it from create_news and delete_news. It directly conveys the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_news or delete_news. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing project in Redmine.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Project ID (numeric) or identifier (string) | |
| name | No | Project display name | |
| identifier | No | Project identifier | |
| description | No | Project description | |
| homepage | No | Project homepage URL | |
| is_public | No | Whether the project is public | |
| parent_id | No | ID of the parent project | |
| inherit_members | No | Inherit members from parent project | |
| default_assigned_to_id | No | Default assignee ID for new issues | |
| default_version_id | No | Default target version ID for new issues | |
| default_issue_query_id | No | Default saved query ID for issue list | |
| tracker_ids | No | IDs of trackers available in this project | |
| enabled_module_names | No | Module names: issue_tracking, time_tracking, news, documents, files, wiki, repository, boards, calendar, gantt | |
| issue_custom_field_ids | No | IDs of issue custom fields enabled for this project | |
| custom_fields | No | Custom field values for the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'updates', omitting any behavioral traits such as whether it is safe, requires specific permissions, or has side effects. The agent gets no risk cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but too minimal. It lacks structure or front-loading of key information, making it less helpful despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 15 parameters and no output schema, the description is insufficient. It does not explain the update behavior, success indicators, or error conditions, leaving a significant gap for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is described in the schema. The description adds no extra semantic value; baseline 3 is appropriate as the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 project in Redmine, which distinguishes it from creation (create_project) and deletion (delete_project) among siblings. However, it lacks specificity about what aspects can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like archive_project or update_issue. The description does not mention prerequisites or context, leaving the agent to infer usage from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing time entry.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric time entry ID to update (required) | |
| issue_id | No | Issue ID to reassign time to | |
| project_id | No | Project ID or identifier to reassign time to | |
| hours | No | Number of hours spent | |
| activity_id | No | Time activity ID | |
| comments | No | Description of the work done | |
| spent_on | No | Date the time was spent (YYYY-MM-DD) | |
| user_id | No | User ID (requires admin privileges) | |
| custom_fields | No | Custom field values |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only says 'updates' but does not disclose behavioral traits such as required permissions, error behavior (e.g., if ID not found), or whether it is a partial or full update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence, but it may be too minimal given the complexity of 9 parameters. It lacks detail that could fit without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no output schema, the description should provide context about the update behavior (e.g., partial update, required fields, return value). The current description is insufficient for an agent to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-described in the schema. The description adds no extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Updates' and the resource 'existing time entry,' distinguishing it from create and delete operations. However, it lacks specificity about which fields can be updated, which is partially covered by the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like create_time_entry or delete_time_entry. The description does not mention prerequisites, such as requiring the ID of an existing time entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing user. Requires admin privileges.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric user ID to update (required) | |
| login | No | User login name | |
| firstname | No | First name | |
| lastname | No | Last name | |
| No | Email address | ||
| password | No | New password | |
| auth_source_id | No | External authentication source ID. Set to null for local auth | |
| mail_notification | No | Email notification preference: all, selected, only_my_events, only_assigned, only_owner, none | |
| must_change_passwd | No | Force password change at next login | |
| generate_password | No | Generate a random password automatically | |
| status | No | User status: 1=active, 2=registered, 3=locked | |
| admin | No | Whether the user has admin privileges | |
| language | No | User language preference | |
| custom_fields | No | Custom field values | |
| group_ids | No | Group IDs to assign the user to. Admin-only. Replaces all current group memberships | |
| send_information | No | Send account information email to the user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates mutation and a privilege requirement but lacks details on side effects (e.g., notification emails, password generation behavior, group membership replacement).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded information. No unnecessary words. Could be expanded slightly without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 16 parameters handling sensitive user updates, the description lacks critical context: no mention of return value, no hints on parameter interactions (e.g., password vs generate_password), and no explanation of the group_ids replacement behavior. Schema covers basics but description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The tool description adds no extra parameter meaning, but the schema is thorough, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates') and resource ('existing user'), making the purpose obvious. It implicitly distinguishes from create/delete tools but doesn't explicitly differentiate from 'update_my_account'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is the admin privilege requirement. No information about when to use this tool versus alternatives like update_my_account, or any non-obvious prerequisites (e.g., user existence, permitted field combinations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing version.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric version ID to update (required) | |
| name | No | New version name | |
| status | No | Version status: open, locked, or closed | |
| sharing | No | Sharing scope: none, descendants, hierarchy, tree, or system | |
| due_date | No | Due date in YYYY-MM-DD format | |
| description | No | Version description | |
| wiki_page_title | No | Associated wiki page title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as partial update behavior, error conditions, or side effects beyond the basic update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it lacks substance and does not provide helpful context. It is not wasteful but also not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain update behavior (partial vs full), return values, or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds no extra meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Updates') and the resource ('existing version'). It distinguishes itself from sibling tools like create_version, delete_version, and get_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, no prerequisites, and no context about required permissions or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads a binary file to Redmine and returns an upload token. IMPORTANT: Redmine requires the request to use Content-Type: application/octet-stream for all file uploads — always set content_type to 'application/octet-stream', regardless of the actual file type. Using any other MIME type (e.g. 'image/png', 'application/pdf') will cause Redmine to reject the upload with HTTP 406. The returned token must be passed in the 'uploads' field when creating or updating issues, wiki pages, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Name for the uploaded file as it will appear in Redmine | |
| content_type | Yes | MUST be 'application/octet-stream'. Redmine rejects uploads with any other Content-Type (HTTP 406). Do not use the actual MIME type of the file here. | application/octet-stream |
| file_path | Yes | Absolute path to the local file to upload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals the critical Content-Type requirement and rejection behavior. It does not mention file size limits, authentication, or error handling for missing files, but covers the essential API behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main action, then crucial requirements, then token usage. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and file upload complexity, the description explains the upload process and token purpose well. It lacks details on response structure (e.g., token format) but is adequate for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by emphasizing the content_type must be 'application/octet-stream' and explaining the token's role in later operations, going beyond schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Uploads a binary file to Redmine and returns an upload token.' It specifies the verb and resource, and distinguishes from sibling tools like create_project_file by explaining the token-based workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to always set Content-Type to 'application/octet-stream', warns of HTTP 406 rejection, and explains token usage for subsequent operations. It does not explicitly list when not to use this tool, but context from siblings implies this is for initial token generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.1.0add_user_to_groupadd_watcherarchive_projectassign_issue_to_sprintcreate_agile_sprintcreate_groupcreate_issuecreate_issue_categorycreate_issue_relationcreate_newscreate_or_update_wiki_pagecreate_projectcreate_project_filecreate_project_membershipcreate_time_entrycreate_usercreate_versiondelete_agile_sprintdelete_attachmentdelete_groupdelete_issuedelete_issue_categorydelete_issue_relationdelete_membershipdelete_projectdelete_time_entrydelete_userdelete_versiondelete_wiki_pageget_agile_sprintget_attachmentget_current_userget_groupget_issueget_issue_agile_dataget_issue_categoryget_issue_relationget_membershipget_my_accountget_newsget_projectget_roleget_time_entryget_userget_versionget_wiki_pageget_wiki_page_versionlist_agile_sprintslist_all_newslist_custom_fieldslist_document_categorieslist_groupslist_issue_categorieslist_issue_prioritieslist_issue_relationslist_issue_statuseslist_issueslist_issues_by_sprintlist_project_fileslist_project_membershipslist_project_newslist_project_versionslist_projectslist_querieslist_roleslist_time_entrieslist_time_entry_activitieslist_trackerslist_userslist_wiki_pagesremove_user_from_groupremove_watchersearchsearch_in_projectunarchive_projectupdate_agile_sprintupdate_attachmentupdate_groupupdate_issueupdate_issue_categoryupdate_journalupdate_membershipupdate_my_accountupdate_newsupdate_projectupdate_time_entryupdate_userupdate_versionupload_fileScored across 89 tools
Most tools have clearly distinct purposes due to descriptive names and detailed descriptions. However, the large number (89) introduces some potential overlaps, such as multiple ways to list/filter issues (list_issues, list_issues_by_sprint, search, search_in_project) and get_issue_agile_data vs get_issue. These could cause misselection if descriptions are not carefully read.
Tool names consistently follow a verb_noun pattern (e.g., create_issue, list_projects, update_user). The verbs are well-chosen and indicate the action clearly. There are very few deviations (e.g., create_or_update_wiki_page), and overall the pattern is predictable and uniform.
With 89 tools, the count is high for a single server, but it reflects the broad scope of Redmine's functionality (multiple entities, CRUD, Agile plugin, etc.). While each tool serves a specific purpose, the server could benefit from consolidation (e.g., merging some list/get tools). The count is borderline excessive but not unreasonable for the domain.
The tool set covers CRUD operations for most Redmine entities (projects, issues, users, groups, versions, news, wiki, time entries, etc.) and includes specialized operations like agile sprints and file uploads. Minor gaps exist (e.g., no direct custom field value management, no workflow transitions), but overall the surface is comprehensive for typical use.
An MCP server that provides access to Testiny projects, test cases and test runs
MCP server for Linear project management and issue tracking
A MCP server built for developers enabling Git based project management with project and personal…
MCP server for Product Management
