The Freshrelease MCP Server enables AI models to interact with Freshrelease for comprehensive project, task, and test case management through its API.
Project and Task Management: Create, retrieve, and list projects and tasks with support for descriptions, assignees, due dates, and issue types using tools like fr_create_project, fr_get_project, fr_create_task, fr_get_task, and fr_get_all_tasks.
Smart Name Resolution: Automatically convert human-readable names (user emails, issue types, statuses, sprints, releases, project keys) to their corresponding Freshrelease IDs, with custom field detection and prefixing.
Test Case Management: List, retrieve, filter, and link test cases to issues with hierarchical section support and bulk operations using fr_list_testcases, fr_get_testcase, and fr_link_testcase_issues.
Advanced Filtering: Filter tasks and test cases using various criteria including standard and custom fields, with automatic name-to-ID resolution via fr_filter_tasks and fr_filter_testcases.
User and Entity Lookups: Search for users by name or email, resolve issue types, and retrieve IDs for sprints, releases, tags, and subprojects within projects.
Filter Persistence: Save and reuse custom filters using fr_save_filter with query hashes from filtering operations.
Cache Management: Clear internal caches for custom fields, lookup data, name-to-ID resolution, and test case forms to refresh data without server restart.
Performance Monitoring: Track and reset performance statistics for monitored functions with fr_get_performance_stats and fr_clear_performance_stats.
HTTP Client Management: Properly close HTTP connections with fr_close_http_client for cleanup.
Mentioned as the distribution platform where the MCP server package can be fetched and run using uvx
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., "@Freshrelease MCP Server show me all open tasks in the FS project"
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.
An MCP server that enables AI models to interact with Freshrelease through powerful tools for complete project and test management.
🤖 AI-Native: Built specifically for AI model integration via MCP protocol
🔧 Complete Management: Projects, tasks, test cases, test runs, and user management
🧠 Smart Resolution: Automatically converts names to IDs (users, sprints, projects, etc.)
📋 Native Filtering: Full support for Freshrelease's native query_hash format
🌲 Hierarchical Navigation: Navigate through 7-level deep section hierarchies
⚡ Performance Optimized: Built-in caching, connection pooling, and batch processing
🎯 Label-Based Filtering: Use intuitive field names like "Owner" instead of "owner_id"
Related MCP server: Freshservice MCP Server
Category | Key Features |
Core Management | Projects, tasks, users, and issue types |
Test Management | Test cases, test runs, and execution tracking |
Smart Filtering | Advanced task and test case filtering |
Lookup & Utilities | Name-to-ID resolution and cache management |
Tool | Purpose | Key Parameters |
| Get project details |
|
| Get task by ID/key |
|
| List all project tasks |
|
| Get comprehensive AI insights for epics with detailed task analysis |
|
| Resolve issue type names |
|
| Get form fields for issue types |
|
| Find users by name/email |
|
Tool | Purpose | Key Parameters |
| List all test cases |
|
| Get specific test case |
|
| Get tests by section |
|
| Link tests to issues |
|
| Advanced test filtering with AI insights |
|
| Add tests to run |
|
| Get comprehensive test run summary with AI quality analysis |
|
Tool | Purpose | Key Parameters |
| Advanced task filtering with native query_hash |
|
| Get issue form schema |
|
| Get test form schema | - |
| Get all form schemas | - |
Tool | Purpose | Key Parameters |
| Find sprint by name |
|
| Find release by name |
|
| Find tag by name |
|
| Get active sub-project sprint |
|
| Resolve sub-project names |
|
| Clear filter cache | - |
| Clear all caches | - |
🧠 Name-to-ID Resolution: Converts user names, sprint names, issue types, etc. to IDs automatically
📋 Native Query Format: Full support for Freshrelease's query_hash format with all operators
🌲 Hierarchical Sections: Navigate up to 7 levels deep section hierarchies (e.g., "Level1 > Level2 > Level3")
🔄 API Compatibility: Handles both nested {"users": [...]} and direct array response formats
⚡ Performance Optimized: Multi-level caching, connection pooling, optimized batch processing
🔗 Flexible Project IDs: Accept both project keys ("FS") and numeric IDs (123)
🎯 Custom Field Support: Auto-detects and handles custom fields with "cf_" prefixing
📊 Multiple Query Formats: Native query_hash, comma-separated strings, or JSON objects
# Easy install (no Python needed)
curl -LsSf https://astral.sh/uv/install.sh | sh
# Or with Python: uv tool install freshrelease-mcpAPI Key: Freshrelease → Profile → API Key
Domain: company.freshrelease.com (your domain)
Project Key: e.g., "FS", "PROJ" (optional)
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"freshrelease-mcp": {
"command": "uvx",
"args": ["freshrelease-mcp"],
"env": {
"FRESHRELEASE_API_KEY": "your_api_key",
"FRESHRELEASE_DOMAIN": "company.freshrelease.com",
"FRESHRELEASE_PROJECT_KEY": "FS"
}
}
}
}✅ You'll see Freshrelease tools available!
Get project overview:
"Show me all tasks in the FS project"
Get specific task details:
"Get details for task FS-123"
Get comprehensive epic insights with AI analysis:
"Show me detailed insights for epic FS-223786 including git status and risk assessment"
The AI will automatically:
Fetch the epic details and all child tasks with full information
Analyze git/PR development status from task descriptions
Provide AI-powered insights on completion rates, team distribution, and timeline risks
Provide status breakdown and progress summary
Show assignee distribution and priority breakdown
Use natural language filtering:
"Find all high priority tasks owned by John Doe that are currently in progress"
The AI understands both:
Friendly labels: "Owner", "Status", "Priority"
Technical names: "owner_id", "status_id", "priority_id"
Native Freshrelease filtering with existing filters:
"Filter tasks using saved filter ID 102776 with custom fields and date ranges"
Sprint and date-based filtering:
"Show me all bugs in Sprint 1 created between Dec 2024 and Aug 2025"
Filter test cases naturally:
"Find all high and medium severity functional tests in the Authentication section"
Navigate hierarchical sections:
"Get all test cases from Authentication > Login Tests > Positive Cases section"
The AI can navigate up to 7 levels deep in section hierarchies automatically.
Get concise test run summary with AI insights:
"How is test run 150183 performing?"
Response example: "23/25 tests executed (92% complete). 21 passed, 2 failed. Quality score: Good. Fix 2 failing test cases."
This project includes comprehensive tools to maintain code quality and prevent common issues:
CODE_QUALITY_GUIDE.md)Complete indentation standards and best practices
Project-specific code patterns and templates
Common mistakes to avoid with examples
Performance optimization guidelines
Pre-commit checklist for developers
quality_check.py)Run quality checks on any Python file:
python3 quality_check.py src/freshrelease_mcp/server.pyFeatures:
✅ Indentation validation (4-space standard)
✅ MCP tool structure verification
✅ Function docstring checks
✅ Async/await pattern validation
✅ Error handling analysis
Example output:
✅ No issues found in src/freshrelease_mcp/server.py✅ Optimized Test Run AI: Simplified fr_get_testrun_summary with concise insights, quality scores, and focused recommendations
✅ Epic AI Insights: Renamed and enhanced fr_get_epic_insights with comprehensive AI analysis including git/PR status, risk assessment, and detailed task analysis
✅ Test Case AI Summary: Renamed fr_filter_testcases to fr_testcase_filter_summary with intelligent insights and automation analysis
✅ Code Quality Tools: Added comprehensive code quality guide (CODE_QUALITY_GUIDE.md) and automated quality checker (quality_check.py)
✅ Enhanced Field Mapping: Fixed filtering issues with improved field label resolution
✅ Better Error Handling: Comprehensive logging and error messages for debugging
✅ Issue Key Resolution: Support for parent_id and epic_id filtering using issue keys
✅ Fixed Fields Mapping Error: Resolved "Failed to get project fields mapping: 0" error
✅ API Response Handling: Better handling of nested vs. direct array responses
✅ Common Field Mappings: Added support for "Parent", "Epic", "Owner" field labels
Not seeing tools in Cursor?
Check ~/.cursor/mcp.json is valid JSON
Restart Cursor completely
Verify credentials: uvx freshrelease-mcp --help
Environment Variables:
FRESHRELEASE_API_KEY="your_api_key" # Required
FRESHRELEASE_DOMAIN="company.freshrelease.com" # Required
FRESHRELEASE_PROJECT_KEY="FS" # Optional default projectMIT License - see LICENSE file for details.
⭐ Like this project? Give it a star on GitHub!
🐛 Found a bug? Open an issue
💡 Have ideas? Start a discussion
Create a project in Freshrelease.
| Name | Required | Description | Default |
|---|---|---|---|
| description | No | ||
| name | 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 carries the full burden of behavioral disclosure. It states the tool creates a project, implying a write operation, but doesn't cover permissions, side effects, error handling, or response format. This is a significant gap for a mutation tool with zero annotation coverage.
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, direct sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes to stating the tool's purpose efficiently.
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 (a mutation with 2 parameters, no annotations, but an output schema exists), the description is incomplete. It states the basic purpose but lacks behavioral details and parameter semantics. The presence of an output schema means return values are documented elsewhere, but the description doesn't provide enough context for safe and effective 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 description coverage is 0%, so the description must compensate but doesn't mention parameters at all. It fails to explain what 'name' and 'description' mean in context, their constraints, or how they affect project creation, leaving parameters undocumented beyond the schema's basic structure.
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 ('Create') and resource ('a project in Freshrelease'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'fr_create_task' beyond specifying the resource type, which is why it doesn't reach a perfect score.
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. The description doesn't mention prerequisites, when not to use it, or how it relates to sibling tools like 'fr_get_project' or 'fr_create_task', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a task under a Freshrelease project.
- due_date: ISO 8601 date string (e.g., 2025-12-31) if supported by your account
- issue_type_name: case-insensitive issue type key (e.g., "epic", "task").
Resolved to an `issue_type_id` via `/project_issue_types` and added to payload.
- user: optional name or email. If provided and `assignee_id` is not,
resolves to a user id via `/{project_identifier}/users?q=...` and sets `assignee_id`.
- additional_fields: arbitrary key/value pairs to include in the request body
(unknown keys will be passed through to the API). Core fields
(title, description, assignee_id, status, due_date, issue_type_id) cannot be overridden.
| Name | Required | Description | Default |
|---|---|---|---|
| additional_fields | No | ||
| assignee_id | No | ||
| description | No | ||
| due_date | No | ||
| issue_type_name | No | ||
| project_identifier | Yes | ||
| status | No | ||
| title | Yes | ||
| user | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals some behavioral traits: it mentions resolution of issue_type_name and user to IDs via API calls, and notes that additional_fields are passed through with core fields protected from override. However, it doesn't cover important aspects like authentication needs, rate limits, error handling, or what the creation response looks like.
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 appropriately sized and front-loaded with the main purpose. The bullet points efficiently organize parameter details without redundancy. However, the final bullet about additional_fields is slightly verbose and could be tightened.
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 9-parameter creation tool with no annotations but an output schema, the description does well: it explains parameter semantics thoroughly, mentions internal resolution behaviors, and notes field protection. The output schema likely covers return values, so the description doesn't need to explain those. It could improve by adding more behavioral context like auth or error handling.
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?
Given 0% schema description coverage, the description compensates fully by explaining the semantics of key parameters: due_date format (ISO 8601), issue_type_name resolution, user resolution logic, and additional_fields behavior (pass-through with core field protection). It adds significant meaning beyond the bare schema, covering most parameters effectively.
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 ('Create a task') and resource ('under a Freshrelease project'), which provides specific verb+resource information. However, it doesn't explicitly differentiate from sibling tools like fr_create_project or fr_get_all_tasks, though the purpose is reasonably distinct by 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?
The description provides no guidance on when to use this tool versus alternatives like fr_create_project or fr_get_all_tasks. It mentions some internal resolution logic (e.g., for issue_type_name and user), but doesn't offer explicit usage 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.
Get a task from Freshrelease by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| project_identifier | 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 full burden of behavioral disclosure. It only states the action ('Get a task') without mentioning whether this is a read-only operation, what permissions are required, how results are returned (e.g., pagination, format), or any rate limits. This leaves critical behavioral traits unspecified for a tool that presumably interacts with an external API.
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's technically concise, but its brevity contributes to underspecification rather than efficiency. It's front-loaded with the core action, though the misleading content reduces its effectiveness.
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 (external API interaction), lack of annotations, and the description's contradictions with both the tool name and parameter schema, it's incomplete. While an output schema exists (which might help with return values), the description fails to provide adequate context for safe and correct usage, especially with misleading information about parameters.
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 must compensate for the lack of parameter documentation. The description mentions 'by ID' but the only parameter is 'project_identifier' (not a task ID), creating a direct contradiction. This adds negative value rather than clarifying parameter meaning, failing to address the schema's gap.
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 states 'Get a task from Freshrelease by ID' which provides a basic verb+resource combination, but it's misleading because the tool name is 'fr_get_all_tasks' (suggesting multiple tasks) while the description references a single task by ID. This creates confusion rather than clarity, though it's not a complete tautology.
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 like 'fr_get_task' (which appears to be a sibling tool for getting a single task). There's no mention of prerequisites, context, or differentiation from similar tools, leaving the agent with insufficient usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the issue type object for a given human name within a project.
This function lists issue types under the specified project and returns the first match by case-insensitive name comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_type_name | Yes | ||
| project_identifier | 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 carries the full burden of behavioral disclosure. It adds some context: it lists issue types and performs case-insensitive matching, returning the first match. However, it doesn't cover important aspects like error handling (e.g., if no match is found), performance characteristics, or authentication needs, leaving gaps for a tool with no annotation support.
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 appropriately sized with two sentences that are front-loaded: the first states the purpose, and the second explains the behavior. There's no wasted text, but it could be slightly more structured (e.g., bullet points for key points) to enhance clarity without adding length.
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 an output schema (which reduces the need to describe return values), no annotations, and low schema coverage, the description is moderately complete. It covers the basic operation but lacks details on error cases, performance, or integration with sibling tools. For a retrieval tool with two parameters, it's adequate but has clear gaps in contextual 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?
The schema description coverage is 0%, so the description must compensate. It mentions 'issue type name' and 'project identifier' but doesn't add detailed meaning beyond what the schema titles imply (e.g., format of identifiers, examples, or constraints). The description provides some context about how parameters are used (case-insensitive matching), but doesn't fully document the two required parameters, resulting in a 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 tool's purpose: 'Fetch the issue type object for a given human name within a project.' It specifies the verb ('fetch'), resource ('issue type object'), and scope ('within a project'). However, it doesn't explicitly differentiate from sibling tools like 'fr_get_project' or 'fr_get_task', which reduces it from a perfect score.
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 by mentioning it 'lists issue types under the specified project' and returns 'the first match by case-insensitive name comparison,' which suggests it's for retrieving a specific issue type by name. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., vs. 'fr_get_all_tasks' or 'fr_get_task'), and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a project from Freshrelease by ID or key.
- project_identifier: numeric ID (e.g., 123) or key (e.g., "ENG")
| Name | Required | Description | Default |
|---|---|---|---|
| project_identifier | 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 full burden. It states the tool retrieves a project but doesn't disclose behavioral traits like authentication requirements, rate limits, error handling, or what happens if the project doesn't exist. The description adds minimal context beyond the basic 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bullet point explaining the parameter. Every sentence earns its place with zero waste.
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 an output schema (which handles return values), 1 parameter with 0% schema coverage, and no annotations, the description is reasonably complete: it explains what the tool does and parameter semantics. However, it lacks behavioral context that would be important for a retrieval tool with no annotation coverage.
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 description coverage, the description compensates by explaining the parameter semantics: it clarifies that project_identifier accepts either numeric ID or string key with examples (123, 'ENG'). This adds meaningful context beyond the schema's basic type definition.
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 'Get' and resource 'project from Freshrelease', specifying it retrieves by 'ID or key'. It distinguishes from siblings like fr_create_project (create) and fr_get_all_tasks (list tasks), but doesn't explicitly differentiate from fr_get_task which retrieves tasks rather than 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 implies usage when needing to retrieve a specific project by identifier, but provides no explicit guidance on when to use this versus alternatives like fr_create_project or fr_get_all_tasks. No when-not scenarios 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.
Get a task from Freshrelease by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| project_identifier | 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 carries the full burden of behavioral disclosure. It only states the action ('Get a task'), implying a read operation, but lacks details on permissions, error handling, rate limits, or response format. This leaves significant gaps in understanding how the tool behaves beyond basic 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.
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 low complexity (2 required parameters) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and 0% schema coverage, it should provide more context on parameters and behavior to be fully complete for a retrieval 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 0%, so the schema provides no parameter details. The description mentions 'by ID', which loosely relates to the 'key' parameter, but doesn't explain 'project_identifier' or clarify that both are required. It adds minimal meaning beyond the bare schema, failing to compensate for the low 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 states the basic action ('Get a task') and resource ('from Freshrelease by ID'), which clarifies the purpose. However, it's vague about what 'ID' refers to (the 'key' parameter) and doesn't distinguish it from sibling tools like 'fr_get_all_tasks' or 'fr_get_project', missing specificity for a 4-5 score.
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 doesn't mention prerequisites, context (e.g., after creating a task), or exclusions, leaving the agent to infer usage from the name alone, which is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk update multiple test cases with issue links by keys.
- Resolves `testcase_keys[]` via `GET /{project_identifier}/test_cases/{key}` to ids
- Resolves `issue_keys[]` via `GET /{project_identifier}/issues/{key}` to ids
- Performs: PUT `/{project_identifier}/test_cases/update_many` with body
{ "ids": [...], "test_case": { "issue_ids": [...] } }
| Name | Required | Description | Default |
|---|---|---|---|
| issue_keys | Yes | ||
| project_identifier | Yes | ||
| testcase_keys | 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 carries the full burden of behavioral disclosure. It explains the multi-step process (resolving keys to IDs then performing a PUT update), which adds useful context about the tool's internal workflow. However, it doesn't cover critical aspects like error handling, permissions required, or rate limits, leaving gaps in 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 appropriately sized and front-loaded with the main purpose, followed by bullet points detailing the process. Each sentence earns its place by explaining the workflow, though it could be slightly more streamlined by avoiding API endpoint specifics that might be redundant if the agent already knows the system.
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 (bulk update with key resolution), no annotations, and an output schema (which reduces need to explain returns), the description is moderately complete. It outlines the process but misses details like error cases, side effects, or performance considerations, making it adequate but with clear gaps 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 0%, so the description must compensate for undocumented parameters. It mentions 'testcase_keys[]' and 'issue_keys[]' but doesn't explain their formats, constraints, or relationships beyond the API calls. This adds minimal semantic value over the bare schema, failing to adequately address the coverage gap.
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 ('bulk update') and resource ('multiple test cases with issue links by keys'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from potential siblings like 'fr_create_task' or 'fr_get_task', which would require a 5.
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 whether it's for batch operations or how it differs from single-update methods. It lacks context about prerequisites or exclusions, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search users in a project by name or email.
Calls `/{project_identifier}/users?q=search_text` and returns the JSON response.
| Name | Required | Description | Default |
|---|---|---|---|
| project_identifier | Yes | ||
| search_text | 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 carries the full burden of behavioral disclosure. It describes the API endpoint and return format ('JSON response'), but lacks details on permissions, rate limits, error handling, or pagination. It doesn't clarify if this is a read-only operation or has side effects, leaving gaps in behavioral understanding.
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 sentences: one states the purpose and the other provides implementation details. It's front-loaded with the core functionality, but the second sentence could be more integrated or omitted if redundant with structured data, though it adds some context here.
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 an output schema (which reduces the need to describe return values), no annotations, and low schema coverage, the description is moderately complete. It covers the basic operation and endpoint, but lacks details on behavioral traits, parameter meanings, and usage context, making it adequate but with clear gaps for a search 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 0%, so the description must compensate. It mentions the parameters indirectly ('project_identifier' and 'search_text' in the endpoint example) but doesn't explain their semantics, constraints, or formats beyond what's implied. For example, it doesn't specify what 'project_identifier' represents or how 'search_text' is matched, leaving parameters inadequately documented.
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 with a specific verb ('Search') and resource ('users in a project'), and specifies the search criteria ('by name or email'). However, it doesn't explicitly differentiate from sibling tools like 'fr_get_project' or 'fr_get_all_tasks', which might also retrieve user-related information in different contexts.
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 searching users within a project, but provides no explicit guidance on when to use this tool versus alternatives like 'fr_get_project' for project details or other user-related operations. It mentions the project context but doesn't specify prerequisites or exclusions.
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.0.0fr_create_projectfr_create_taskfr_get_all_tasksfr_get_issue_type_by_namefr_get_projectfr_get_taskfr_link_testcase_issuesfr_search_usersScored across 8 tools
The tools have clear distinctions for core operations like create_project, create_task, get_project, get_task, and search_users, but there is notable overlap between fr_get_all_tasks and fr_get_task, where the former's name suggests retrieving multiple tasks but its description indicates fetching a single task by ID, causing potential confusion. Additionally, fr_link_testcase_issues stands out as a specialized bulk operation that might not be immediately distinguishable from other task-related tools without careful reading.
All tools follow a consistent naming pattern with the prefix 'fr_' followed by a verb_noun structure (e.g., fr_create_project, fr_get_task, fr_search_users). This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or convention across the eight tools.
With 8 tools, the count is reasonable for a project and task management server, covering essential operations like creation, retrieval, and search. However, the scope feels slightly thin as it lacks update or delete operations for projects and tasks, which are common in such domains, making it borderline but still functional for basic workflows.
The tool set has significant gaps for a project and task management domain. It includes create and get operations for projects and tasks, but missing update and delete tools limits lifecycle coverage. While there are auxiliary tools for issue types, users, and test case linking, the absence of core CRUD operations for managing existing resources will likely cause agent failures in handling modifications or removals.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Manage projects, tasks, time tracking, and team collaboration through natural language.
Manage Avaza projects, tasks, timesheets, expenses, invoices, and scheduling from AI assistants.
AI-native project management for tasks, docs, collaboration, and agents.
