FreeScout MCP Server

Server Quality Checklist

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

Latest release: v3.1.0
Disambiguation3/5
Most tools map to single distinct actions, but get_ticket, analyze_ticket, and get_ticket_context all center on reading/understanding a single ticket. The get_ticket description's 'Fetch and analyze' wording blurs its boundary with analyze_ticket, so descriptions must be read closely to avoid misselection.
Naming Consistency5/5
All tools use the freescout_ prefix with a clear verb_noun structure: get_ticket, add_note, update_ticket, create_draft_reply, search_tickets, get_mailboxes. The verbs and nouns are consistent and predictable, with no mixed casing or irregular naming patterns.
Tool Count5/5
Eight tools is an appropriate size for a helpdesk assistant server. Each tool covers a distinct stage of the ticket workflow without ballooning into unnecessary operations or feeling too thin for the intended scope.
Completeness4/5
The set covers lookup, search, analysis, status/assignment updates, internal notes, context gathering, and draft replies, which is enough for common support ticket workflows. Obvious gaps like sending replies directly or deleting tickets are absent, but those are reasonable boundary choices for an assistant that drafts rather than sends.
Average 3.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 5 community issues answered or closed in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under GPL 3.0.
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 must carry the full behavioral burden. It only says 'Update ticket status and/or assignment' without disclosing side effects, permission requirements, reversibility, or any additional constraints. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, perfectly front-loaded with the action and target, containing zero fluff. It is optimally concise.
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?
For a mutation tool with no annotations, no output schema, and 4 parameters, the description is too sparse. It does not explain what happens when status changes, the role of userId, or any prerequisites. Missing essential behavioral context for safe usage.
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 all parameters are already documented. The description adds no extra semantics beyond a high-level summary of 'status and/or assignment', which overlaps with the schema descriptions. Baseline 3 applies since schema carries the burden.
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 'Update' and the resource 'ticket', specifying two update aspects: status and assignment. It distinguishes itself from sibling tools like search, note, or analyze, though it doesn't explicitly name an alternative. This is a clear statement of purpose.
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 usage guidelines—no 'when to use' or 'when not to use' instructions, and no comparison with alternatives. The agent must infer the intended scenario from the tool name and schema.
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 the full burden. It says 'Get ticket context and customer info' but doesn't disclose what exactly is returned, whether it's a read-only operation, any side effects, or performance implications. For a tool that fetches context, it should clarify the scope of data (e.g., full conversation history, customer details) and any limitations. The description is too vague about behavior.
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, concise and front-loaded with the main purpose. It's efficient with no wasted words. However, it could be slightly more structured by mentioning the output or usage context, but it's appropriately sized for a simple tool.
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 purpose (drafting personalized replies), the description is incomplete. It doesn't mention what kind of context is provided (e.g., customer name, previous interactions, sentiment) or how it integrates with the drafting workflow. With no output schema and no annotations, the description should provide more detail about the return value and its use. The single sentence is insufficient for an agent to know what to expect.
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% for the single parameter 'ticket', which is described as 'Ticket ID, ticket number, or FreeScout URL'. The description adds no additional meaning beyond that, but since the schema already covers it well, a baseline of 3 is appropriate. The description doesn't clarify how the tool resolves the ticket identifier, but that's not required.
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: 'Get ticket context and customer info to help draft personalized replies.' It specifies the resource (ticket) and the intent (drafting replies), which distinguishes it from siblings like freescout_get_ticket (which likely fetches raw ticket data) and freescout_analyze_ticket (which likely performs analysis). However, it doesn't explicitly differentiate from freescout_get_ticket, so it's not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when drafting personalized replies, but it doesn't explicitly state when to use this tool versus alternatives like freescout_get_ticket or freescout_analyze_ticket. There's no mention of when not to use it. The context is clear but lacks explicit exclusions or alternative guidance.
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, the description carries full responsibility for disclosing behavior. It only says 'add' (implying mutation) but does not explain side effects, required permissions, idempotency, or how the note is associated with a user (despite a userId parameter). No additional context on behavior is provided.
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?
A single sentence that conveys the essential action. No fluff, no redundant details. Front-loaded with the verb and object, making it easy to scan.
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?
This is a simple mutation tool with no output schema and no annotations. The description provides minimum viable information: it adds a note. But given the context of sibling tools (e.g., create_draft_reply, update_ticket), more context on when to use an internal note vs a customer-visible reply, or any prerequisites, would be valuable. The description is too thin to be fully complete for an agent that has limited knowledge of FreeScout internals.
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% – all three parameters (note, ticket, userId) are described in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate, since the schema already documents parameters and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Add an internal note to a FreeScout ticket.' This is specific and distinct from siblings like get_ticket or update_ticket, as it addresses a unique action (adding internal notes). The tool name and title are semantically consistent.
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 gives no guidance on when to use this tool versus alternatives (e.g., create_draft_reply or update_ticket). It doesn't mention typical use cases, prerequisites, or when not to use it. The only hint is the purpose statement itself.
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 that a draft is created and can be edited before sending. It does not mention side effects like whether the ticket is modified, whether any permissions are needed, whether the draft is stored permanently, or whether the operation is idempotent. For a write operation, this is insufficient context.
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, front-loaded sentence that communicates the purpose and the key behavior without any fluff. It earns its place by stating the core function and the 'editable before sending' nuance, and it does so 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?
For a tool with 6 parameters and no output schema, the description is minimal but not entirely inadequate. It conveys the main intent and the 'not sent yet' aspect, but it lacks details on how the draft relates to the ticket, whether the ticket status changes, or any prerequisites or constraints. Given the lack of annotations, this is a noticeable gap but not a critical failure.
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 100%, with every parameter (cc, to, bcc, ticket, userId, replyText) having a meaningful description. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a draft reply in FreeScout, with a specific verb ('Create') and resource ('draft reply'), and adds the key nuance that it can be edited before sending. This distinguishes it from sibling tools like freescout_add_note (which adds a note, not a reply) and freescout_update_ticket (which modifies ticket fields).
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 about when to use this tool versus alternatives, such as when to create a draft vs sending a reply directly, or when to use freescout_add_note instead. The description only states what it does, not the eligible scenarios 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?
No annotations are provided, so the description carries full burden. It implies a read-only fetch operation but does not explicitly state that it is non-mutating, nor does it explain what 'analyze' entails, return format, or any limitations. This is adequate but not rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and input requirement. Every word earns its place, with no unnecessary filler or redundancy.
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?
With two parameters, no output schema, and no annotations, the description is minimally sufficient. However, it fails to clarify the meaning of 'analyze' or how this tool differs from freescout_analyze_ticket, leaving context gaps for a more complex operation.
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 input schema provides descriptions for both parameters (ticket and includeThreads) with 100% coverage. The description adds no extra meaning beyond what the schema already documents, just echoing 'by ID or URL'. Baseline 3 is appropriate for full schema coverage.
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 fetches and analyzes a FreeScout ticket by ID or URL, using a specific verb and resource. However, it does not explicitly differentiate from the sibling freescout_analyze_ticket, so it misses the top score for sibling distinction.
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 freescout_analyze_ticket or freescout_search_tickets. There is no context about selecting this tool over others, so it falls to 'no guidance' / 2.
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 the full burden of behavioral disclosure. It states the analysis intent but does not disclose whether the tool is read-only, whether it can modify a ticket, what input formats are actually accepted beyond the schema hint, or how its output is returned.
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, front-loaded sentence with no filler, redundancy, or tangential information. Every word contributes to communicating the tool's purpose.
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?
The description is enough to recognize the tool's core purpose and names three kinds of output, which is minimal viable. However, with no annotations and no output schema, it omits important operational context like side effects, response shape, and when to select this tool instead of a retrieval-focused sibling.
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 only parameter, 'ticket', is already fully described in the schema as 'Ticket ID, ticket number, or FreeScout URL'. The description adds no additional parameter semantics, but the schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and names both the resource ('FreeScout ticket') and the output scope ('issue type, root cause, and suggested solution'). This clearly differentiates it from sibling tools that get, update, search, or add notes to tickets.
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 it should be used when a ticket needs diagnosis, but it does not explicitly state when to choose this over freescout_get_ticket or freescout_get_ticket_context, nor does it describe exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. The phrase 'list of available mailboxes' is terse and does not explicitly state that this is a read-only operation, nor does it provide any details about the response structure, potential errors, or system behavior. Compared to the calibration examples, this is less informative than the 'list ALL calls' description that earned a 3, hence a 2 is appropriate.
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, short sentence that is directly to the point. Every word adds value, and there is no fluff. This is an example of excellent conciseness, not under-specification.
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 simplicity of the tool (no parameters, no output schema, no nested objects), the description is mostly sufficient. However, it could provide a bit more context, such as the type of data returned (e.g., mailbox IDs and names) or note that no authentication is required, which would help an agent determine if this tool meets their needs without making a separate call. Thus, it is adequate but not outstanding.
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?
There are zero parameters, so the baseline of 4 is applied. The description does not need to add parameter context since none exist, and no additional information could meaningfully improve this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get list of available mailboxes' uses a specific verb 'Get', a clear resource 'mailboxes', and the qualifier 'available' indicates scope. It distinguishes itself well from sibling tools that deal with tickets and notes, making the function's purpose immediately obvious.
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 that this tool is used when you need a list of mailboxes, but it does not explicitly state when to use it versus alternatives or provide exclusions. Since there are no sibling tools that list mailboxes, the lack of explicit alternative guidance is mitigated, but the onboarding still relies on the agent inferring the obvious use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, and it does this well: it explicitly calls out FreeScout's subject-only search limitation, explains the `textSearch` alias, documents relative time filter formats, and states what `includeLastMessage: true` does. It does not cover all edge cases, but the key non-obvious behaviors are disclosed.
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 compact paragraph with no filler. Every sentence adds distinct information: search scope, the subject-only limitation, filter semantics, time filter syntax, and message-preview behavior. It is front-loaded with the core purpose and then efficiently elaborates.
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 13 parameters and no output schema, the description covers the primary query modes well but leaves gaps. It does not describe the return shape, default pagination behavior, or the meaning of `state`, `status`, and `mailboxId`, so an agent may still be uncertain about outputs and some filter combinations. This is adequate but not exhaustive.
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 description coverage is only 31%, so the description must compensate, and it meaningfully does so. It explains the relationship between `subject` and `textSearch`, clarifies `assignee` values ('unassigned' vs a user number), and adds semantic value for time filters and `includeLastMessage`. Some parameters like `mailboxId`, `state`, `status`, `page`, and `pageSize` remain undocumented, but the most behaviorally important parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Search for FreeScout tickets.' It goes on to clarify the exact scope of the search (subject-only, no message-body full-text), which sharply distinguishes this from related 'get' and 'analyze' sibling tools. An agent can reliably tell what this tool does without opening the schema.
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 gives practical how-to guidance: use `subject`/`textSearch` for subject, `customerEmail` for customer, `number` for a single ticket, and `assignee` for unassigned/specific users. However, it never explicitly compares this tool with siblings like `freescout_get_ticket`, and it does not state when NOT to use this tool, leaving tool-selection decisions to inference.
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:

[![mcp-freescout MCP server](https://glama.ai/mcp/servers/verygoodplugins/mcp-freescout/badges/card.svg)](https://glama.ai/mcp/servers/verygoodplugins/mcp-freescout)

Score Badge

Copy to your README.md:

[![mcp-freescout MCP server](https://glama.ai/mcp/servers/verygoodplugins/mcp-freescout/badges/score.svg)](https://glama.ai/mcp/servers/verygoodplugins/mcp-freescout)

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/verygoodplugins/mcp-freescout'

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