cloud-support-mcp

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a distinct operation on support cases: listing, getting, searching, creating, updating, closing, comments, attachments, and classifications. No two tools have overlapping purposes; even list vs search are clearly differentiated by description.
Naming Consistency4/5
Most tools follow a verb_noun pattern, but there is inconsistency in whether the noun is 'support_case' or 'case' (e.g., list_support_cases vs get_case_comments). This is a minor deviation that does not create confusion.
Tool Count5/5
10 tools is a well-scoped count for a support case management server. Each tool covers a necessary function without redundancy or bloat, making the set easy to navigate.
Completeness5/5
The tool set covers the full lifecycle of support cases: create, read (list/get/search), update, close, comment, and list attachments. It also includes classification search, which is needed for creation. There are no obvious dead ends or missing critical operations.
Average 3.5/5 across 10 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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?
With no annotations, the description carries the full burden for behavioral disclosure, but it offers only the basic 'list all' statement. It does not mention pagination, filtering behavior, permissions, or the possibility of large result sets, which are important for an agent to anticipate.
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, clear sentence with no wasted words. It is appropriately concise but could be slightly more informative about the tool's scope or relationship to siblings, preventing a perfect score.
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?
The description is very sparse given the tool's complexity. It lacks any mention of return format, pagination behavior, or how filtering works, and there is no differentiation from search_support_cases. The absence of an output schema makes this a significant gap for an agent to understand the tool's full behavior.
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 all four parameters (filter, parent, pageSize, pageToken) already documented. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all support cases for a Google Cloud project or organization' with a specific verb and resource scope. It distinguishes from some siblings like get_support_case (single case) but does not explicitly differentiate from search_support_cases, which likely offers similar listing with more advanced filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_support_cases or get_support_case. The phrase 'list all' implies a broad listing use, but there are no explicit exclusions or context cues, leaving the agent without clear decision 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?
There are no annotations, and the description does not disclose any behavioral traits. It does not mention pagination, return format, access requirements, or any side effects. Even the read-only nature is assumed rather than stated.
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, making it concise and efficient. However, it is so under-specified that it sacrifices substance for brevity, which is acceptable but not exemplary.
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?
With no output schema, no annotations, and a 6-parameter tool requiring a parent resource, the description is incomplete. It does not explain return behavior, pagination, or how it relates to sibling tools, leaving the agent with significant uncertainty.
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 covers 100% of parameters with descriptions, including enums and defaults, so the schema handles parameter semantics. The description adds no extra meaning beyond the generic 'various filters,' meeting the baseline but not exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches support cases, using the verb 'search' and a specific resource. However, it does not distinguish from sibling tools like 'list_support_cases' or 'get_support_case', as the phrase 'various filters' is vague and lacks detail.
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 does not explain whether search is text-based, field-based, or how it differs from listing cases. It merely says 'with various filters,' implying usage but leaving context ambiguous.
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?
Since no annotations are provided, the description must carry the burden of behavioral disclosure. It only states the creation action and parent association, omitting important details like required permissions, side effects, or the meaning of testCase or priority. This is a significant gap for a write operation.
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, front-loaded sentence that efficiently communicates the core action and the parent association. It is concise and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex schema with 9 parameters, a nested object, and no output schema, the description provides minimal contextual completeness. It does not explain the return value, failure behavior, or how parameters like classification or subscriberEmailAddresses factor into the creation process.
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 100% description coverage for all 9 parameters, so the baseline is 3. The description adds marginal value by mentioning parent association but does not clarify parameter details beyond what the schema already offers.
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 creates a new support case and associates it with a parent, using a specific verb and resource. It distinguishes from sibling tools like listing or updating cases, though it lacks additional detail about the case creation process.
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 implied usage is to create a new support case, but there is no explicit guidance on when to choose this tool over alternatives like update_support_case or search_support_cases. It doesn't mention prerequisites such as needing a parent resource or classification.
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 and no output schema, the description carries the full burden of behavioral disclosure. It only states the action ('Get') without detailing pagination, ordering, permissions, or whether the conversation history includes private/internal comments. This is a minimal read operation disclosure but lacks richness expected 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without unnecessary detail. Every word earns its place, making it maximally concise.
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 simple one-parameter fetch tool, the description is adequate but incomplete. It does not specify the return format or any edge cases, and since there is no output schema, the agent must guess what 'comments and conversation history' includes. The lack of annotations increases the burden, so a 3 reflects a minimum viable description.
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 provides 100% coverage for the single 'name' parameter with a clear format example. The description adds no parameter-specific meaning beyond restating the scope ('for a specific support case'), so the baseline score 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 clearly states the tool retrieves 'comments and conversation history' for a specific support case, using a specific verb ('Get') and resource ('comments and conversation history'). It distinguishes itself from siblings like get_support_case (case details) and create_case_comment (creation).
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 implies the tool is for retrieving comments for a case but provides no explicit guidance on when to use it versus alternatives like get_support_case or search_support_cases. There is no mention of prerequisites or exclusions, leaving the agent to infer usage from the name alone.
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 must disclose behavioral traits. It does not mention pagination (despite the pageSize/pageToken parameters), return format, or any access requirements. The phrase 'List all attachments' could mislead given pagination limits. This is a significant gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose without any fluff. Every word earns its place, making it highly concise and well-structured.
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?
With no output schema and no annotations, the description should clearly explain what the tool returns and how it behaves. It does not mention that results are paginated or what data is included for each attachment. For a simple tool this may be minimally viable, but it leaves important context gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter has a descriptive comment with examples and constraints (e.g., parent path format, pageSize max). The description adds no further semantic value beyond what the schema already provides, so a 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 ('List') and clearly identifies the resource ('attachments') and the scope ('associated with a support case'). It unambiguously distinguishes this tool from siblings like list_support_cases (lists cases) and get_case_comments (gets comments).
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?
Usage is implied by the tool's name and description: you use this when you need attachments for a case. However, there is no explicit guidance about when to prefer this over alternatives, nor any mention of prerequisites or exclusions, so it falls to implied usage rather than clear context.
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 the full burden for behavioral disclosure. It does not state any permissions needed, what 'detailed information' includes, or error behavior for nonexistent cases. The description simply says 'Get detailed information' without elaborating on any side effects, prerequisites, or output specifics beyond generic wording.
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 is front-loaded with the key verb and resource. Every word earns its place, and there is no unnecessary elaboration.
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 simple getter with one parameter and no output schema, the description is minimally viable but leaves gaps. It does not specify the structure of 'detailed information' or potential error conditions, which would be useful given that no output schema exists to clarify return values.
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 already provides 100% coverage for the single 'name' parameter, including an example format. The tool description adds no additional semantic value beyond what the schema describes, 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 clearly states the tool retrieves detailed information for a specific support case, using a specific verb ('Get') and resource ('support case'). This distinguishes it from sibling tools like list_support_cases (listing many) and get_case_comments (getting comments rather than case details).
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 you need details for a known case, but it does not explicitly mention alternatives or when not to use it. There is no mention of using list/search first to find the case or that get_case_comments is for comments, so guidance is only implicit.
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 the burden. It discloses the irreversible nature of closing ('cannot be reopened'), which is a significant behavioral trait. However, it does not mention permissions, idempotency, or what happens to related data (e.g., comments), so transparency is incomplete.
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 extremely concise and front-loaded, with two short sentences that convey the core action and a critical consequence. No wasted words or redundant information.
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 simple single-parameter mutation tool with no output schema or annotations, the description is largely complete. It states the action, the irreversibility, and the schema provides the parameter format. Minor gaps like permissions or response format are acceptable for this complexity, so a 4 is warranted.
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%, and the description adds no additional parameter semantics beyond what the schema already documents (resource name format). Baseline of 3 is appropriate since the description does not hinder parameter understanding.
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's function with a specific verb ('Close') and resource ('existing support case'). It also includes a key consequence (cannot be reopened), distinguishing it from siblings like update_support_case or create_support_case.
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 closing an existing case but provides no explicit guidance on when to choose this over alternatives such as update_support_case. No exclusion criteria or alternative tool names are mentioned.
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 for behavioral disclosure. It states 'Add' (implying mutation) but gives no details on permissions, side effects, rate limits, or return behavior. The phrase 'for communication with Google Support' adds context but not behavioral traits.
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 sentence, front-loaded with the action verb 'Add', and contains no extraneous information. It is concise and to the point.
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 simple two-parameter tool with fully described schema, the description provides adequate context for basic usage. However, since there is no output schema and no annotations, additional information about expected outcomes or error conditions would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter entries for both 'body' and 'parent'. The description itself does not add parameter-specific details, so the baseline score 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 clearly states the verb 'Add' and the resource 'comment to a support case', making the tool's purpose unambiguous. It is easily distinguished from sibling tools like create_support_case (creates a case) and get_case_comments (reads comments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for adding comments to existing cases, which is distinct from listing, getting, or closing cases. However, it does not explicitly state when not to use alternatives or mention any prerequisites, so it lacks explicit exclusion guidance.
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 must disclose behavior. 'Search and retrieve' implies read-only, but the description does not explicitly state it is non-mutating, nor does it mention permissions, ordering, or filtering semantics. Minimal behavioral context is added.
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. Every word contributes meaning, making it concise and well-structured.
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 simple search tool with three optional parameters and no output schema, the description gives sufficient context for its purpose. It does not detail response format or pagination behavior, but the schema covers pagination parameters. Adequate but not exhaustive.
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 covers 100% of parameters with descriptive text, including an example for 'query' and defaults for 'pageSize'. The description adds no parameter details beyond the schema, so baseline 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 verb ('search and retrieve'), resource ('valid case classifications'), and purpose ('for creating support cases'). It distinguishes from sibling tools that manage support cases directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for creating support cases' gives clear context for when to use this tool, but it does not explicitly exclude alternatives or name sibling tools. There is no when-not guidance, so it earns a 4.
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 present, so the description must carry behavioral disclosure. It discloses that only certain fields are updatable, which is a useful constraint, but omits any side effects, permissions, or how updateMask interacts.
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?
Single sentence conveying the essential function and constraint with no redundancy.
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 mutation tool with 5 params and no output schema, the description covers the main constraint and leaves field-level details to the schema. It doesn't explain the updateMask behavior or required name, but schema covers those. Acceptable.
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?
The schema fully documents all five parameters, so baseline is 3. The description adds the key semantic that only priority, displayName, and subscriberEmailAddresses are mutable, which is not fully captured by the schema alone.
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?
Clearly states the action ('Update') and resource ('existing support case'), and specifies the updatable fields, distinguishing it from create/close siblings.
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?
Provides a constraint on which fields can be updated but doesn't explicitly contrast with alternative tools like create_support_case or close_support_case, nor mention when to prefer this tool.
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:

[![cloud-support-mcp MCP server](https://glama.ai/mcp/servers/polar3130/cloud-support-mcp/badges/card.svg)](https://glama.ai/mcp/servers/polar3130/cloud-support-mcp)

Score Badge

Copy to your README.md:

[![cloud-support-mcp MCP server](https://glama.ai/mcp/servers/polar3130/cloud-support-mcp/badges/score.svg)](https://glama.ai/mcp/servers/polar3130/cloud-support-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/polar3130/cloud-support-mcp'

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