Freshrelease MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness2/5
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.
Average 3/5 across 8 of 8 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the 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.
Conciseness4/5
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.
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 (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.
Parameters2/5
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.
Purpose2/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('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.
Conciseness5/5
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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 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.
Parameters2/5
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.
Purpose3/5
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.
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. 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
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. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource '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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![freshrelease_mcp MCP server](https://glama.ai/mcp/servers/dasscoax/freshrelease_mcp/badges/card.svg)](https://glama.ai/mcp/servers/dasscoax/freshrelease_mcp)

Score Badge

Copy to your README.md:

[![freshrelease_mcp MCP server](https://glama.ai/mcp/servers/dasscoax/freshrelease_mcp/badges/score.svg)](https://glama.ai/mcp/servers/dasscoax/freshrelease_mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dasscoax/freshrelease_mcp'

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