Which integrations are available for this server?

Provides integration with YouTrack, an issue tracking and project management tool by JetBrains, enabling management of issues, sprints, knowledge base articles, and projects.

How do I use YouTrack MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@YouTrack MCP create a new issue in PROJECT-1 for fixing the login bug" 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.

YouTrack MCP

by DashingNights

Overview Schema Related Servers Score Discussions

Remote

YouTrack MCP TypeScript Server

License: MIT

A Model Context Protocol (MCP) server for YouTrack integration, providing a standardized interface for LLMs to interact with YouTrack's issue tracking, agile management, and knowledge base features.

Features

Issue Management
- Create, read, update, delete issues
- Add comments and attachments
- Search issues with advanced filtering
- Track issue time and estimation
Agile & Sprint Management
- Create and manage sprints
- Assign issues to sprints
- Track sprint progress
State Management & Workflows
- Transition issues through states
- Start working on issues with automatic assignment
- Complete issues with proper resolution
Knowledge Base Integration
- Create and manage articles
- Link issues to knowledge base articles
- Search knowledge base content
Project Management
- List and filter projects
- Get project details and customization options

Related MCP server: YouTrack MCP Server

Installation

# Clone the repository
git clone https://github.com/itsalfredakku/youtrack-mcp.git
cd youtrack-mcp-ts

# Install dependencies
npm install

# Build the project
npm run build

Configuration

Copy the example environment file and configure it with your YouTrack instance details:

cp .env.example .env

Edit the .env file with your specific configuration:

# YouTrack instance URL (without trailing slash)
YOUTRACK_URL=https://your-instance.youtrack.cloud

# YouTrack permanent token
# Generate from: Profile > Account Security > Tokens
YOUTRACK_TOKEN=your-permanent-token-here

# Optional: Default project ID
PROJECT_ID=PROJECT-1

# Optional: Enable webhooks (true/false)
ENABLE_WEBHOOKS=false

# Optional: Webhook server port (default: 3000)
WEBHOOK_PORT=3000

# Optional: Webhook secret for signature verification
WEBHOOK_SECRET=your-webhook-secret

# Optional: Log level (error, warn, info, debug)
LOG_LEVEL=info

# Optional: Cache TTL in milliseconds (default: 300000 = 5 minutes)
CACHE_TTL=300000

# Optional: Enable cache (true/false, default: true)
CACHE_ENABLED=true

Usage

Starting the Server

# Start the MCP server
npm start

# Start in development mode with auto-reload
npm run dev

Interacting with the Server

The YouTrack MCP server exposes tools following the Model Context Protocol. LLM applications can discover and use these tools to interact with YouTrack.

Example: Creating an Issue

{
  "tool": "create_issue",
  "params": {
    "projectId": "PROJECT-1",
    "summary": "Implement new feature",
    "description": "We need to implement the new feature as described in the specs.",
    "type": "Task",
    "priority": "Normal"
  }
}

Example: Searching Issues

{
  "tool": "search_issues",
  "params": {
    "query": "project: PROJECT-1 #bug state: Open",
    "limit": 10
  }
}

Example: Starting Work on an Issue

{
  "tool": "start_working_on_issue",
  "params": {
    "issueId": "PROJECT-1-123",
    "comment": "Starting implementation of this feature",
    "estimatedTime": "2d"
  }
}

Available Tools

The server provides 60+ tools for interacting with YouTrack. Here are some of the most commonly used:

Issue Management

create_issue - Create a new issue
get_issue - Get issue details
update_issue - Update an issue
add_issue_comment - Add a comment to an issue
search_issues - Search for issues

Agile & Sprint Management

list_sprints - List all sprints
create_sprint - Create a new sprint
assign_issue_to_sprint - Add an issue to a sprint
get_sprint_issues - Get all issues in a sprint

State Management

start_working_on_issue - Begin work on an issue
change_issue_state - Change an issue's state
complete_issue - Mark an issue as completed

Knowledge Base

create_article - Create a knowledge base article
update_article - Update an article
get_article - Get article details
search_articles - Search knowledge base articles

Project Management

list_projects - List all accessible projects
get_project_details - Get project information

Development

Prerequisites

Node.js 18.x or later
npm 8.x or later
A YouTrack instance with API access

Development Workflow

# Install dependencies
npm install

# Start in development mode with auto-reload
npm run dev

# Run linting
npm run lint

# Run type checking
npm run type-check

# Build the project
npm run build

Project Structure

src/index.ts - Main entry point
src/youtrack-client.ts - YouTrack API client
src/tools/ - Individual MCP tool implementations
src/utils/ - Utility functions and helpers
src/types/ - TypeScript type definitions
src/config/ - Configuration management

Testing

# Run all tests
npm test

# Run specific test suites
npm run test:queries
npm run test:issues

Troubleshooting

Common Issues

Authentication errors: Verify your YouTrack token has the necessary permissions and hasn't expired.
Project not found: Ensure the project ID exists and is accessible to your account.
API rate limiting: YouTrack may impose rate limits. Consider implementing retry logic for critical operations.
State transition errors: Some state transitions may be prohibited by your YouTrack workflow configuration.

Logs

Logs are stored in the logs directory:

combined.log - All log entries
error.log - Error-level logs only

Set the LOG_LEVEL environment variable to control logging verbosity (error, warn, info, debug).

Contributing

Please read CONTRIBUTING.md for details on our code of conduct and the process for submitting pull requests.

Fork the repository
Create your feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add some amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Acknowledgements

Available Tools

12 tools

adminC

Administrative operations: search users, inspect fields, list field values, bulk update, create dependencies

ParametersJSON Schema

Name	Required	Description
`operation`	Yes	Admin operation to perform
`query`	No	Search query (for search_users)
`projectId`	No	Project ID (for project-specific operations)
`fieldName`	No	Field name (for field_values)
`issueIds`	No	Issue IDs (for bulk operations)
`updates`	No	Update data (for bulk_update)
`sourceIssueId`	No	Source issue ID (for dependencies)
`targetIssueId`	No	Target issue ID (for dependencies)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It lists operations but fails to mention that 'bulk_update' or 'create dependencies' are mutable and potentially destructive. No information on authentication, 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently lists the types of operations. It front-loads the purpose and uses a semicolon-separated list, which is clear. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 parameters, 5 distinct operations) and no output schema, the description is too brief. It does not explain how the operations work, what results to expect, or provide examples. A more detailed description is needed for effective tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The tool description adds context by naming operations but does not explain parameter interactions or dependencies (e.g., which params are required for each operation). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it covers 'Administrative operations' and lists specific actions (search users, inspect fields, etc.). This distinguishes it from more focused sibling tools like issues or projects, but it bundles multiple operations, reducing specificity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. For example, there is no mention that for standard user searches one should use this tool instead of a dedicated user tool, nor are any 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.

agile_boardsC

Agile boards and sprints: list boards/sprints, get details, create sprints, assign issues

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: boards (list), board_details (get board), sprints (list), sprint_details (get sprint), create_sprint (new), assign_issue (to sprint)
`boardId`	No	Board ID (required for board_details, sprints, sprint_details, create_sprint)
`sprintId`	No	Sprint ID (required for sprint_details, assign_issue)
`issueId`	No	Issue ID (required for assign_issue)
`projectId`	No	Project ID for filtering
`name`	No	Sprint name (for create_sprint)
`start`	No	Sprint start date YYYY-MM-DD (for create_sprint)
`finish`	No	Sprint end date YYYY-MM-DD (for create_sprint)

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must fully convey behavioral traits. It only lists actions without disclosing side effects, authentication needs, rate limits, or error behaviors. The 'create' and 'assign' actions imply mutations but no details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with a colon-separated list is concise and front-loaded. However, it is very brief and could be expanded slightly for better usability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks details on return values, pagination, or behavior per action. Given the multiple actions and no output schema, the description is insufficient for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with adequate parameter descriptions. The brief description adds little beyond summarizing actions, not enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool handles agile boards and sprints with specific actions: list, get details, create, assign. However, it does not differentiate from sibling tools like 'issues' or 'projects' that might also handle similar tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings or prerequisites. The description lacks context for selecting between this and other related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

analyticsC

Analytics and reporting: project statistics, time tracking, Gantt, critical path, resource allocation, milestone progress

ParametersJSON Schema

Name	Required	Description
`reportType`	Yes	Report type to generate
`projectId`	No	Project ID (required for most reports)
`startDate`	No	Start date YYYY-MM-DD (for time-based reports)
`endDate`	No	End date YYYY-MM-DD (for time-based reports)
`userId`	No	User ID (for user-specific reports)
`milestoneId`	No	Milestone ID (for milestone reports)

TDQS

C2.6/5.0

Behavior2/5

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 whether reports are read-only, authentication needs, or rate limits. The burden falls entirely on the description, which only lists report types.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, but it is essentially a list without structure or context. It could be more organized to improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 6 parameters, no output schema, and 1 required parameter, the description is incomplete. It does not describe the output format, prerequisites for different report types, or behavior for missing optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds minimal value beyond repeating the enum values in a different format. It does not explain what each report type returns or when to use specific parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides analytics and reporting, listing specific report types. However, it does not distinguish from sibling tools like time_tracking or projects, which may overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description lacks context for choosing this tool over siblings such as time_tracking or issues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

authB

Authentication: status, OAuth2 login, logout, re-authenticate, validate token

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action: status (check auth), login (OAuth2 browser), logout (sign out), reauth (force re-auth), test (validate token)

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It lists actions but does not mention side effects such as opening a browser for login, invalidating sessions on logout, or the interactive nature of reauth. This lack of detail reduces transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that efficiently communicates the tool's purpose. It is front-loaded with the keyword 'Authentication' and lists all key actions. However, it could be slightly better structured with a colon and list format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description should provide more context about return values and side effects. For example, it does not indicate that login and reauth involve browser interaction, which is critical for an agent to understand. The description is insufficient for a complete understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the single parameter with detailed enum descriptions, so the description adds minimal extra meaning. It essentially restates the enum values, meeting the baseline but not exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it handles authentication tasks and lists specific actions (status, login, logout, reauth, test), distinguishing it from sibling tools that focus on other domains (e.g., issues, projects). However, it is terse and could use a more explicit verb-resource phrase like 'Manage authentication state'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly tells the agent to use this tool for authentication-related operations, but it does not provide explicit guidance on when to use versus alternatives, nor does it mention any prerequisites or conditions for using specific actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

commentsC

Issue comments: list, add, update, delete

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: get (list comments), add (new comment), update (edit), delete (remove)
`issueId`	Yes	Issue ID
`commentId`	No	Comment ID (required for update/delete)
`text`	No	Comment text (required for add/update)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description lacks behavioral details such as whether actions are destructive, authentication requirements, rate limits, or idempotency. It only lists actions without explaining implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (one line), but it omits important context that could be conveyed with slightly more structure, such as listing the actions or including usage examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool performs CRUD operations with 4 parameters and no output schema, the description should include return value information, error handling, or preconditions. It lacks completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with clear parameter descriptions. However, the tool description itself adds no additional semantic value beyond repeating the actions already detailed in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Issue comments: list, add, update, delete' clearly indicates the tool manages issue comments with four actions. It distinguishes from siblings like 'issues' (which likely deals with the issues themselves) and other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that to view comments on an issue one should use this tool with action 'get' rather than using the 'issues' tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

issuesC

Issue lifecycle: create, update, query/search, change state, comment, start/complete work

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: create (new issue), update (modify), get (single issue), query (advanced search), search (smart search), state (change state), complete (mark done), start (begin work)
`projectId`	No	Project ID (required for create action)
`issueId`	No	Issue ID (required for update, get, state, complete, start actions)
`summary`	No	Issue title/summary (for create/update)
`description`	No	Issue description (for create/update)
`query`	No	Search query (for query/search actions)
`state`	No	New state (for state action)
`priority`	No	Issue priority
`assignee`	No	Assignee username
`type`	No	Issue type (Bug, Feature, Task, etc.)
`comment`	No	Comment for state changes or completion

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description should clarify behavioral traits. It only mentions actions but lacks details on side effects, required permissions, or consequences (e.g., what happens after 'complete' or 'start'). The description is too terse.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise (10 words) and front-loads the core concept. While it could benefit from slight expansion for clarity, it wastes no words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters, 8 actions, no output schema, no annotations), the description is insufficient. It omits context about return values, action relationships, and prerequisites, leaving significant gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions. The tool description adds no extra parameter-level 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Issue lifecycle' and lists actions (create, update, query/search, change state, comment, start/complete work), indicating the tool's scope. However, it does not distinguish from sibling tools like 'query' or 'comments', which may cause confusion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description only lists actions without explaining context such as prerequisites or when to choose a sibling like 'query' or 'comments'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

knowledge_baseC

Knowledge base: list, get, create, update, delete, search articles

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: list (all articles), get (single), create (new), update (edit), delete (remove), search (find)
`articleId`	No	Article ID (required for get, update, delete)
`title`	No	Article title (required for create, optional for update)
`content`	No	Article content (required for create, optional for update)
`summary`	No	Article summary (optional)
`tags`	No	Article tags (optional)
`searchTerm`	No	Search term (required for search action)
`projectId`	No	Project ID for filtering

TDQS

C2.4/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral traits like side effects or authorization needs. It only lists actions without noting that delete is permanent or that mutations require write access.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise but lacks necessary detail. It is a single line listing actions, which is under-specified for a multi-action tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, no output schema), the description fails to explain return values, error handling, or usage patterns per action. It is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already describes parameters. The description adds no additional parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly lists actions (list, get, create, update, delete, search) and the resource (articles), making the tool's purpose clear. It differentiates from siblings which are in other domains.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. While siblings are unrelated, the lack of usage context or prerequisites is a gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

notificationsC

Notifications: status, list, clear, subscribe/unsubscribe, list subscriptions

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: status (connection status), list (recent notifications), clear (clear all), subscribe (create subscription), unsubscribe (remove subscription), subscriptions (list subscriptions)
`limit`	No	Maximum number of notifications to return (for list action)
`id`	No	Subscription ID (for unsubscribe action)
`name`	No	Subscription name (for subscribe action)
`filters`	No	Notification filters (for subscribe action)
`enabled`	No	Whether subscription is enabled (for subscribe action)
`deliveryMethods`	No	Delivery methods for notifications (for subscribe action)

TDQS

C2.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits such as side effects (e.g., 'clear' action), authentication requirements, or rate limits. The actions are named but not explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely short (seven words) and unstructured. While brief, it is under-informative and not efficient for decision-making.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, nested objects, no output schema), the description is grossly incomplete. It fails to explain actions, return values, or usage context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the parameter descriptions in the schema are clear. The tool description adds no additional meaning beyond the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description merely lists actions ('status, list, clear, subscribe/unsubscribe, list subscriptions') without a clear verb+resource statement like 'Manage notifications'. It is vague and fails to distinguish from sibling tool 'subscriptions'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives (e.g., the sibling 'subscriptions' tool). The description does not specify context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

projectsB

Project management: list projects, get details, validate access, list custom fields, retrieve statistics

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action to perform: list (all projects), get (project details), validate (check access), fields (custom fields), status (project statistics)
`projectId`	No	Project ID or shortName (required for get, validate, fields, status actions)
`fields`	No	Comma-separated fields to return (for list action)	id,name,shortName,description

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It does not mention whether operations are read-only or have side effects, authentication needs, or rate limits. The nature of actions like 'validate' and 'status' remains unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the domain and lists actions. While it could benefit from bullet points for readability, it is efficient and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-action tool with no output schema, the description does not detail return values or when to use each action. It covers the five actions but lacks specifics about projectId format or behavior differences across actions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining each action's purpose (e.g., 'list (all projects)'), which clarifies the enum values beyond the schema's brief descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool is for project management and lists specific actions (list, get, validate, fields, status). It clearly distinguishes from sibling tools by its focus on project-level operations, but it aggregates multiple actions rather than a single verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternative tools (e.g., issues, admin). The description lists actions but does not explain context or prerequisites for choosing this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

queryC

Raw YouTrack query using native syntax (returns issues matching the expression)

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	YouTrack query syntax string. Examples: • "state: Open" - All open issues • "project: PROJECT-1 assignee: me" - My issues in project • "priority: High created: >2025-01-01" - High priority recent issues • "#bug -state: Resolved" - Open bugs (full-text search)
`fields`	No	Comma-separated field names to return. Example: "id,summary,state,priority" or "id,summary,description,assignee,created"	id,summary,description,state,priority,reporter,assignee
`limit`	No	Maximum number of issues to return (1-1000, default: 50)

TDQS

C2.9/5.0

Behavior2/5

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 the tool returns matching issues but omits that it is a read-only operation, how errors are handled (e.g., invalid syntax), or any rate limits. The description lacks transparency for a raw query executor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the purpose. It is efficient but could be slightly more structured (e.g., adding a brief note on usage).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a raw query tool (3 parameters, no output schema), the description provides only the basic function. It does not explain the return format or error behavior, which are important for completeness. Decently adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions including examples and defaults. The tool description adds no extra meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a raw YouTrack query and returns matching issues. It uses the verb 'query' and mentions native syntax, distinguishing it from sibling tools like 'issues' which likely handle simpler lookups. However, it could be more explicit about when to use this over the 'issues' tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like the 'issues' sibling. It does not specify any exclusions or prerequisites, leaving the agent to infer usage context on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

subscriptionsC

Notification subscriptions: create, update, delete, list

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: create (new subscription), update (modify existing), delete (remove), list (all subscriptions)
`id`	No	Subscription ID (required for update/delete actions)
`name`	No	Subscription name (required for create action)
`filters`	No	Notification filters (project, issue type, priority, etc.)
`enabled`	No	Whether subscription is enabled
`deliveryMethods`	No	How notifications should be delivered
`updates`	No	Updates to apply to subscription (for update action)

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies side effects (create, delete) but with no annotations to cover behavioral traits like authentication, rate limits, error handling, or scope of changes. The brief phrase does not disclose safety or operational nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise at one sentence, but this brevity sacrifices clarity for a tool with 7 parameters and nested objects. It front-loades the purpose but omits necessary detail, making it barely adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (7 params, nested objects, no output schema), the description is incomplete. It does not explain return values, success/error indicators, or how actions like 'list' behave. The schema partially compensates, but significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which already explain required fields and defaults. No extra value is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool manages notification subscriptions with create, update, delete, and list actions. It identifies the resource (subscriptions) and the operations, but does not distinguish from sibling tools like 'notifications', which may overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as 'notifications' or 'admin'. There are no context indicators, prerequisites, or exclusions, leaving the agent to infer usage independently.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

time_trackingC

Time tracking & work items: log time, manage entries and work items, generate reports

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action: log_time (add time), get_time_entries (list entries), update_time_entry (edit), delete_time_entry (remove), get_work_items (list items), create_work_item (new), update_work_item (edit), time_reports (analytics)
`issueId`	No	Issue ID (required for most time tracking operations)
`duration`	No	Time duration (e.g., "2h", "1d", "30m") for log_time
`description`	No	Work description or comment
`date`	No	Date for time entry (YYYY-MM-DD format, defaults to today)
`workItemId`	No	Work item ID (for update/delete operations)
`timeEntryId`	No	Time entry ID (for update/delete operations)
`projectId`	No	Project ID (for reports and filtering)
`userId`	No	User ID (for reports and filtering)
`startDate`	No	Start date for reports (YYYY-MM-DD)
`endDate`	No	End date for reports (YYYY-MM-DD)
`workType`	No	Type of work (Development, Testing, Documentation, etc.)

TDQS

C2.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden for behavioral disclosure. It only lists high-level functions without detailing behavioral traits like mutability, idempotency, rate limits, or side effects. The enum descriptions in the schema provide some action-level context, but the description itself adds little beyond summarizing the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the main capabilities. However, it could be more structured by grouping actions or providing a brief example. Overall, it is appropriately sized but could earn its place with more precision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (12 parameters, 8 enumeration actions, no output schema), the description is severely incomplete. It does not explain return values, pagination, error handling, or usage patterns for different actions. The agent is left with insufficient context to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter's purpose is already documented. The description adds no new meaning beyond restating the actions listed in the action enum descriptions. It does not explain parameter interdependencies, default behaviors, or format constraints beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool covers time tracking, work items, and reports, with specific actions like 'log time', 'manage entries', 'generate reports'. However, it does not distinguish it from sibling tools like 'analytics' (which may also generate reports) or 'issues' (which may have time tracking).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool vs alternatives. It does not specify prerequisites, when not to use it, or mention sibling tools. The agent must infer usage from the broad description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Disambiguation5/5

Each tool is grouped by clear domain (e.g., issues, agile_boards, comments) with distinct responsibilities. Overlaps like issues and query are resolved by raw query being a specialized search tool, while notifications and subscriptions are differentiated by subscription management being a subset of notifications.

Naming Consistency5/5

All tool names follow a consistent lowercase underscore pattern (e.g., agile_boards, time_tracking). The naming is predictable and uses nouns or adjective_noun combinations, making it easy for an agent to infer functionality.

Tool Count5/5

With 12 tools covering core project management domains (issues, boards, analytics, etc.), the count is well-scoped. Each tool serves a necessary purpose without unnecessary bloat or missing critical features.

Completeness5/5

The tool set provides comprehensive lifecycle coverage: issue CRUD, state transitions, comments, time tracking, project management, agile boards, knowledge base, notifications, subscriptions, analytics, and admin operations. No obvious dead ends or missing operations for a project management system.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

YouTrack MCP Server
Project Management Developer Tools
lucyfuur94
A
license
Not graded
quality
D
maintenance
A comprehensive Model Context Protocol server for YouTrack integration, providing extensive tools for issue tracking, project management, workflow automation, and team collaboration.
Updated a year ago (2025-08-05 06:59 UTC)
10
3
MIT
YouTrack MCP Server
abdullahtas0
A
license
Not graded
quality
C
maintenance
A comprehensive Model Context Protocol server that provides AI agents with 44 tools to manage JetBrains YouTrack issues, sprints, and projects via the REST API. It supports full YouTrack query language and works with both Cloud and Server instances for complete project management integration.
Updated 6 months ago (2026-03-07 00:18 UTC)
48
MIT
YouTrack MCP
Project Management Search
tonyzorin
A
license
Not graded
quality
A
maintenance
MCP server for interacting with YouTrack, enabling issue management, project operations, and search via natural language.
Updated 8 days ago (2026-08-26 23:52 UTC)
436
94
MIT
YouTrack MCP Server
Project Management Developer Tools
VitalyOstanin
A
license
Not graded
quality
A
maintenance
MCP server for comprehensive YouTrack integration, enabling issue management, work tracking, search, and knowledge base operations.
Updated 11 days ago (2026-08-24 03:08 UTC)
145
6
MIT

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DashingNights/youtrack-mcp'

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