Provides tools for managing Redmine tasks, including listing tasks, logging time, updating status, progress, and adding notes.
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 Show me my open tasks"
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 - Manage tasks, log time, update status via Claude/AI assistants.
List Tasks - View tasks assigned to you with status filtering
Task Details - Get detailed information about specific issues
Log Time - Record time entries with comments
Update Status - Change issue status (in progress, resolved, etc.)
Update Progress - Set completion percentage (0-100%)
Add Notes - Add comments to issues
Daily Summary - Check today's logged hours
Time Logs Range - View logged hours within a date range
Related MCP server: Redmine MCP Server
pip install xukaaaa-redmine-mcpOr install from source:
git clone https://github.com/xukaaaa/redmine-mcp-server.git
cd redmine-mcp-server
pip install -e .Set the following environment variables:
export REDMINE_URL="https://your-redmine-instance.com"
export REDMINE_API_KEY="your-api-key"Log in to your Redmine instance
Go to My Account (top right)
Find API access key on the right sidebar
Click Show or Reset to get your key
Add to your Claude Desktop config (~/.config/claude/claude_desktop_config.json on Linux/Mac or %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"redmine": {
"command": "redmine-mcp-server",
"env": {
"REDMINE_URL": "https://your-redmine-instance.com",
"REDMINE_API_KEY": "your-api-key"
}
}
}
}Tool | Description |
| List tasks assigned to you (filter: open/closed/status name) |
| Get detailed info about a specific issue |
| Log time entry with hours and comment |
| Change issue status |
| Update completion percentage |
| Add a comment to an issue |
| View today's time entries and total hours |
| View time logs within a date range (from_date, to_date) |
| Clear cached metadata |
Ask Claude:
"Show me my open tasks"
"What's the status of issue #123?"
"Log 2 hours on task #456 for code review"
"Mark issue #789 as resolved"
"Update task #101 to 80% complete"
"How many hours have I logged today?"
"Show me my time logs from 2025-12-23 to 2025-12-27"
# Clone the repo
git clone https://github.com/xukaaaa/redmine-mcp-server.git
cd redmine-mcp-server
# Install in development mode
pip install -e .
# Run the server
redmine-mcp-serverMIT License - see LICENSE for details.
xukaaaa - GitHub
Thêm comment (note) vào task
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | ||
| note | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the basic operation (adding a note) without discussing side effects, authorization requirements, idempotency, or whether the note is appended or replaces existing ones. 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?
The description is extremely concise—a single sentence with no filler. It is front-loaded with the action. However, conciseness comes at the cost of omitting useful details that could fit in one additional sentence.
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 presence of an output schema, the description does not need to detail return values. The tool is simple with two required parameters. Yet the description lacks any context about prerequisites (e.g., issue must exist) or typical usage, making it merely adequate. A slightly more complete description would improve usability.
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 0%, so the description should compensate. However, it does not explain the parameters at all. The parameter names (issue_id, note) are self-explanatory to a degree, but the description adds no meaning beyond the schema itself, missing an opportunity to clarify format constraints or relationships.
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 ('Thêm comment (note)') and the target resource ('vào task'), making it immediately obvious that this tool adds a note to a task. It is distinct from sibling tools like log_time or update_issue_status.
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. It lacks any mention of prerequisites, typical scenarios, or exclusions. The agent receives no help in deciding between add_note and other tools like update_issue_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Xóa cache để reload metadata từ Redmine
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It states it clears cache and reloads metadata, but does not mention whether this is a safe operation, required permissions, or impacts on other users. The term 'reload metadata' is ambiguous regarding scope and 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 short sentence, but it effectively conveys the core purpose. It could be improved by front-loading the action and adding context, but it 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's simplicity (no parameters, no nested objects) and presence of an output schema, the description is partially complete. However, it lacks contextual details such as when cache clearing is appropriate and what exactly 'reload metadata' entails, relying on the output schema for return values.
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 the description does not need to provide parameter details. Schema coverage is trivially 100%. A baseline of 4 is appropriate as no compensation 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 states it clears cache to reload metadata from Redmine, specifying the exact action and resource. It distinguishes itself from sibling tools which are all data retrieval or 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. It does not specify prerequisites, conditions for cache staleness, 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.
Xem chi tiết một task cụ thể bằng ID.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies read-only via 'view' but does not disclose any side effects, authentication requirements, or behavior when the ID is not found. The existence of an output schema partially covers return format, but 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, front-loaded sentence with no wasted words. It efficiently conveys 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?
For a simple retrieval tool with an output schema, the description is minimally adequate. However, it lacks usage guidelines and parameter details, which are important for effective tool selection among similar siblings.
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 0%, and the description adds no extra meaning for the 'issue_id' parameter beyond the schema's type (integer). For a low-coverage schema, the description should compensate, but it does not mention what the parameter represents or how to obtain it.
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 'view', resource 'details of a task', and method 'by ID'. It is specific and distinguishes from sibling tools like get_time_logs_range or list_my_tasks, which deal with multiple tasks or ranges.
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 over siblings such as get_time_logs_range or list_my_tasks. The description only explains the basic function without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Xem tổng giờ đã log trong khoảng thời gian. Args: from_date: Ngày bắt đầu (YYYY-MM-DD) to_date: Ngày kết thúc (YYYY-MM-DD)
| Name | Required | Description | Default |
|---|---|---|---|
| from_date | Yes | ||
| to_date | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates the action (view total hours) but does not mention side effects, authentication needs, rate limits, or whether it's read-only. The implied read-only nature is insufficient for transparent behavior 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 extremely concise: one sentence for purpose, then a minimal two-line parameter list. Every sentence adds value, with no redundancy or filler. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple aggregated query with two required parameters and an output schema, the description is nearly complete. It covers the purpose and parameter format. Since the output schema exists, the lack of return-value description is acceptable. Minor gap: no mention of behavior if from_date > to_date.
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 description adds format guidance ('YYYY-MM-DD') for both parameters, which the schema lacks (no description). However, it omits details like inclusivity of dates, order validation, or range bounds. With schema coverage at 0%, this moderate addition earns a 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 ('Xem tổng giờ đã log' – view total logged hours) and the resource (time logs in a date range). It differentiates from siblings like 'get_today_logs' (single day) and 'log_time' (logging), making the tool's scope unambiguous.
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., 'get_today_logs' for today's logs) or when not to use it. The description merely states what it does, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kiểm tra tổng giờ đã log trong hôm nay
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation ('check'). It does not disclose behavior when no logs exist, authentication requirements, or aggregation details, which are critical since annotations are absent.
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 unnecessary 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 tool is simple with no parameters and an output schema, so the description is minimally adequate. However, it lacks context about when to use this vs. sibling tools like 'get_time_logs_range', and the Vietnamese language may hinder English agents.
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, the description correctly implies that no input is needed. However, it does not add meaning beyond the schema (which has no properties), so a baseline 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 'Kiểm tra tổng giờ đã log trong hôm nay' clearly states the verb (check), resource (total hours logged), and temporal scope (today). It distinguishes this tool from the sibling 'get_time_logs_range', which covers a date range.
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. The description does not mention exclusions or prerequisites, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lấy danh sách task được assign cho tôi. Args: status_filter: Trạng thái task (open, closed, hoặc tên status cụ thể like 'in_progress'). Default: open.
| Name | Required | Description | Default |
|---|---|---|---|
| status_filter | No | open |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden for behavioral traits. It does not disclose any behavioral aspects such as read-only nature, data scope (e.g., current user only), pagination, or error conditions. Lacks 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?
The description is relatively concise with a clear structure (purpose sentence followed by Args block). It is not overly verbose, but could be more front-loaded by omitting the 'Args:' label if not needed.
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 covers the basic operation and one parameter well, but lacks context about important aspects like pagination, size limits, or whether the list is exhaustive. With an output schema (unseen), return values are not necessary to describe, but more guidance on filtering beyond status would improve 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?
The description adds significant meaning to the 'status_filter' parameter beyond the schema, specifying allowed values ('open', 'closed', 'in_progress') and default. Schema description coverage is 0%, so the description compensates well.
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 tasks assigned to the user. It uses specific verb 'lấy danh sách' (get list) and resource 'task', and distinguishes from sibling tools like 'get_issue_details' (single issue) or 'get_today_logs' (time logs).
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 offers no guidance on when to use this tool versus alternatives. No explicit when-to-use or when-not-to-use information is provided, leaving the agent without context for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log thời gian làm việc vào task với đầy đủ parameters. Args: issue_id: ID của task hours: Số giờ (ví dụ 1.5) comment: Mô tả công việc đã làm activity_id: ID của activity (ví dụ: 14 cho Development). Default: từ cache spent_on: Ngày làm việc (YYYY-MM-DD). Default: today custom_fields: Custom fields dạng JSON string (ví dụ: '[{"id": 64, "value": "Coding"}]')
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | ||
| hours | Yes | ||
| comment | Yes | ||
| activity_id | No | ||
| spent_on | No | ||
| custom_fields | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the existence of defaults. With no annotations, it fails to mention idempotency, side effects (e.g., creation vs. update), 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?
The description is concise (4 sentences) and front-loaded with the main purpose. It clearly lists parameters with examples, avoiding unnecessary 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 the presence of an output schema (not shown) and the tool's straightforward nature (logging time with defaults), the description covers essential parameter details and examples, making it sufficiently 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 0%, but the description compensates by explaining defaults (activity_id from cache, spent_on today) and providing examples (custom_fields JSON, activity_id 14). However, issue_id, hours, and comment lack added semantics beyond names.
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 logs working time into a task ('Log thời gian làm việc vào task'), specifying the action and resource. It distinguishes from sibling log retrieval tools by indicating it creates logs.
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 update_issue_status or add_note. Missing context on prerequisites, such as requiring an existing issue or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cập nhật trạng thái của task. Args: issue_id: ID của task status_name: Tên trạng thái (ví dụ: 'resolved', 'in progress', 'completed') act_start: Ngày bắt đầu thực tế (YYYY-MM-DD). Bắt buộc khi status=completed. Default: today act_finish: Ngày kết thúc thực tế (YYYY-MM-DD). Bắt buộc khi status=completed. Default: today
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | ||
| status_name | Yes | ||
| act_start | No | ||
| act_finish | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose side effects, authorization, or response behavior 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?
Concise, front-loaded purpose, bullet list for parameters. No wasted sentences.
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?
Covers all parameters and conditions; output schema exists to handle return values, so not needed. Lacks error handling info, but acceptable.
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 0% schema coverage, description fully compensates by explaining each parameter, format, defaults, and conditional requirements.
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 action ('Cập nhật trạng thái của task') and resource. Examples of status names provide specificity.
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 conditional requirements for parameters (status=completed) and defaults, but does not explicitly compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cập nhật % hoàn thành (0-100)
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | ||
| percent | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It adds the range constraint (0-100) for percent, but lacks details on idempotency, error handling, or side effects, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, achieving maximum 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 2-parameter tool, the description is minimal but omits usage guidelines and parameter semantics. The existence of an output schema reduces the need to describe return values, but overall completeness is only 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 0%, so the description should compensate. It adds a range constraint for percent but provides no context for issue_id. This partial compensation merits a 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 specifies the verb 'Cập nhật' (update), the resource '% hoàn thành' (completion percentage), and the constraint '(0-100)', clearly distinguishing it from sibling tools like update_issue_status and log_time.
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 (e.g., update_issue_status), nor does it mention prerequisites or contexts.
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.
v0.1.4add_noteclear_cacheget_issue_detailsget_time_logs_rangeget_today_logslist_my_taskslog_timeupdate_issue_statusupdate_progressScored across 9 tools
Each tool has a clearly distinct purpose: adding notes, clearing cache, viewing issue details, querying time logs, logging time, listing tasks, updating status, updating progress. No overlaps.
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_my_tasks, get_issue_details, update_issue_status). The naming is uniform and predictable.
With 9 tools, the server is well-scoped for Redmine task management. Each tool serves a specific need without excessive length or sparse coverage.
The tool set lacks issue creation and deletion, which are fundamental for full lifecycle management. Users cannot create new tasks, only update or view existing ones, limiting agent capabilities.
Remote MCP for Kanban AI boards—manage projects, tasks, and comments from AI tools.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Manage Timequip projects, tasks, comments, members, and dashboards through MCP.
