cloud-run

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing vs creating projects, listing vs getting services, fetching logs, and three deployment methods differentiated by file source (local files, folder, or content). The deployment tools include explicit 'use this tool if' guidance to remove any ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case: list_projects, create_project, list_services, get_service, get_service_log, deploy_local_files, deploy_local_folder, deploy_file_contents. The pattern is uniform and predictable.
Tool Count5/5
8 tools is well-scoped for a Cloud Run management server, covering project, service, log, and deployment operations without unnecessary redundancy. Each tool serves a distinct purpose within a reasonable count.
Completeness3/5
The tool set covers project listing/creation, service listing/detail/logs, and multiple deployment modes, but lacks operations for updating or deleting services, managing revisions, or handling traffic splits. These are notable gaps for a full Cloud Run lifecycle, though core workflows are handled.
Average 3.4/5 across 8 of 8 tools scored.
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 Apache 2.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?
With no annotations, the description bears full burden. It implies a read-only operation via 'Lists', but does not disclose pagination, output format, filtering, or any side effects. Minimal value added beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, and the action is front-loaded. It is concise without being verbose, though it could incorporate more context without losing efficiency.
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, the description provides a fundamental understanding of what it does, but it lacks details about the output structure (e.g., project names/IDs) or any usage notes. With no output schema or annotations, this is a marginal pass.
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?
Zero parameters make schema coverage trivially 100%. Baseline for 0 params is 4; description adds no parameter information, but none is needed, so the baseline stands.
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?
Verb 'Lists' and resource 'available GCP projects' are clear and unambiguous. It does not explicitly differentiate from sibling tools like list_services, but the resource type is specific enough for most agents. Minor deduction for lacking explicit 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?
No guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or scenarios, leaving the agent to infer its placement among list_services and other siblings.
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 only states 'gets details,' which implies a read operation, but it does not disclose potential error behaviors (e.g., not-found handling), required IAM permissions, rate limits, or what specific details are returned. For a tool without annotations, this is a minimal disclosure that leaves significant behavioral aspects unspecified.
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 and resource, with zero filler. It is efficiently structured and immediately understandable, achieving maximum conciseness without sacrificing necessary content.
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 read tool with no output schema and no annotations. The description offers only the bare minimum. Given the lack of annotations, the description should clarify what details are returned, potential failure cases, or any special handling. Without this, an agent cannot fully anticipate the tool's behavior, making the description incomplete for a tool with no other structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a description in the schema. The tool description adds no additional meaning beyond what the schema already provides. Thus, the baseline of 3 applies, as the schema adequately documents all parameters and the description does not compensate or enrich them 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?
The description clearly states a specific verb ('gets') and a well-defined resource ('details for a specific Cloud Run service'). The word 'specific' distinguishes it from list_services, which presumably lists all services. This is a precise, non-tautological statement that unambiguously identifies the tool's function.
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 its siblings (e.g., list_services for enumeration, get_service_log for logs). There is no mention of alternatives or prerequisites. The usage context is only implied by the generic 'gets details' phrasing, leaving the agent to infer when this should be chosen over other tools.
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 must carry the full behavioral disclosure burden. It only states that it deploys files, implying a mutation operation, but says nothing about side effects, required permissions, authentication, whether an existing Cloud Run service is updated or a new one created, or what happens on failure. For a deployment tool with significant side effects, this is a major gap.
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?
Two sentences with minimal waste. The core action and usage condition are front-loaded. The minor grammar error ('exists' instead of 'exist') is negligible. It earns a 4 for being concise and to the point, though it could have added behavioral context without sacrificing brevity.
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 deployment tool with no annotations and no output schema, the description is severely incomplete. It fails to explain deployment behavior, what the result will be, whether it is destructive, or any prerequisites (e.g., gcloud auth, project existence). The high schema coverage partially compensates for parameter details, but the overall operation context is missing, making it inadequate for reliable agent invocation.
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% – every parameter has a description, including the guidance on 'project' to have the user confirm it. The description adds no additional meaning beyond what the schema already provides; it merely restates 'absolute file paths' which is already in the schema. Baseline 3 is correct since the schema handles the parameter documentation.
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 ('Deploy local files to Cloud Run') and the resource (local filesystem files as an array of absolute paths). It distinguishes from likely siblings like deploy_file_contents and deploy_local_folder by the 'local files' phrasing, though it does not explicitly name alternatives. This is clear but lacks explicit sibling differentiation that would merit 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit condition: 'Use this tool if the files exists on the user local filesystem.' This tells the agent when to choose this tool over deploy_file_contents (which likely handles in-memory content) or deploy_local_folder. However, it does not state when not to use it or mention the other deploy tools as explicit alternatives, so a 4 is appropriate.
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 bear the burden of behavioral disclosure. 'Gets' implies a read-only operation, but the description doesn't mention permissions, pagination, or the nature of the returned logs. It provides only the basic action without additional behavioral 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, tightly written sentence with no filler. The action verb and object are front-loaded, making it easy to parse at a glance.
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 no output schema, the description leaves out what the returned logs will include (structure, size, ordering). For a simple tool this is acceptable, but an agent would benefit from knowing the response format or any constraints (e.g., time range) to fully anticipate the call.
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 each parameter (project, service, region) already described at the schema level. The tool description adds no further parameter semantics, so the baseline of 3 applies given the schema's adequacy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Gets') and a distinct resource ('Logs and Error Messages for a specific Cloud Run service'). It clearly implies this is for a single service, which differentiates it from list-style siblings, though it doesn't explicitly name alternatives.
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 choose this tool over siblings like get_service or list_services. It merely states what it does, leaving the agent to infer the appropriate context without any exclusionary or alternative routing.
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. 'Lists' implies a read-only operation, but the description does not explicitly state that it is safe/non-destructive, nor does it disclose what it returns (e.g., list of service names vs. full objects), pagination behavior, or error cases. This is a significant gap for a 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 sentence with no waste. It is front-loaded with the verb and resource, and includes both parameter scopes. This is appropriately concise and well-structured.
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 list operation with two fully described parameters and no output schema, the description is adequate in stating the primary function. However, it lacks details on the return format (what fields are included) and any caveats (e.g., pagination, absence of results). The agent can infer a list is returned, but not the structure. This is acceptable but not fully 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 description coverage is 100%, with both 'project' and 'region' having descriptions. The tool description adds no parameter information beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lists') and a specific resource ('Cloud Run services in a given project and region'). This clearly distinguishes it from get_service (singular) and from deployment-related siblings. The scope (project and region) is explicitly mentioned, matching the parameters.
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 does not mention that get_service retrieves a single service or that listing is for multiple services. There is no explicit context, exclusions, or alternative routing.
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 does disclose the 'attempts to attach' behavior, which implies possible failure, and explains auto-generation of project ID. However, it does not mention required permissions, potential side effects, or what happens if no billing account is available. It adds some value beyond just 'create', but remains incomplete for a mutation 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 two concise sentences with no filler. It front-loads the primary action and includes the most important behavioral caveat (billing attach attempt) early. Every sentence serves a purpose, making it efficient and easy to parse.
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 tool is simple with one optional parameter and no output schema, so the description is reasonably complete. However, it lacks a note about the return value or result of the operation (e.g., what the agent should expect back), and does not mention asynchronous behavior or potential errors. This is a minor but relevant gap for an agent invoking a creation action.
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%, so the parameter is already well-documented. The description reinforces the fact that projectId is optional and that auto-generation occurs, but adds no new semantic meaning beyond the schema. Baseline of 3 is appropriate given high schema coverage.
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 a specific verb ('Creates') and resource ('GCP project'), and adds a key behavioral detail (attaching to first available billing account). This differentiates it from sibling tools like list_projects and deploy_local_files, which are clearly read or deployment operations.
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 does not provide any guidance on when to use this tool versus alternatives. It does not mention exclusions or conditions that would select another tool. While the action is self-evident given the siblings, there is no explicit routing or contextual instructions.
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 carry the full burden of behavioral disclosure. The description only states the action and the input path; it does not disclose whether the deployment overwrites an existing service, requires special permissions, or has any side effects. For a deployment action, this is a significant transparency gap.
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 concise—two sentences—with the primary purpose stated first and the usage condition appended. There is no redundant or filler content; every sentence contributes to understanding the tool's purpose and when to use it.
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 deployment tool with no output schema and no annotations. The description only covers purpose and a usage tip, but omits crucial context such as what happens after deployment, how to verify success, whether the service gets replaced, or any required prerequisites. Given the complexity of deploying to Cloud Run, the description is critically incomplete for an agent to execute safely.
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 full descriptions for all four parameters (100% coverage), so the schema carries the burden. The tool description adds no parameter-specific meaning beyond the schema. The baseline of 3 is appropriate, as the schema already defines each parameter's purpose and defaults.
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: deploy a local folder to Cloud Run. It names a specific verb and resource, and the addition of 'Use this tool if the entire folder content needs to be deployed' distinguishes it from sibling tools like deploy_local_files and deploy_file_contents, which handle different deployment scopes.
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 provides a clear condition for when to use the tool: when deploying the entire folder content. It implies that for partial deployments, alternative tools should be used, though it does not explicitly name those alternatives. The schema also includes a guidance note on the project parameter (user confirmation), which adds to usage clarity.
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 carry the full behavioral burden. It states the action (deploy files) but does not disclose side effects such as creating or updating a Cloud Run service, potential overwrites, or whether the operation is async or sync. For a mutation tool that deploys services, this lack of effect disclosure is a significant gap.
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?
Two sentences with zero fluff. The opening sentence states the core action and method, and the second sentence gives the explicit usage condition. Everything in the description is essential and front-loaded.
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 deployment tool with 4 parameters and no output schema, the description covers the selection criteria but misses execution details like expected behavior, return values, or error handling. The schema covers parameter definitions, but the operational context (e.g., deployment progress, confirmation requirements for project ID) is absent, making the tool only partially complete for an agent.
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%, so the schema already documents all parameters. The description only repeats the main concept ('array of file objects containing filename and content'), which adds no new meaning beyond the schema. It does not clarify parameter relationships, defaults, or the meaning of 'project' being optional, so the 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 uses a specific verb ('Deploy'), names the resource ('files to Cloud Run'), and specifies the method ('by providing their contents directly'). It also distinguishes from siblings by noting the condition 'if the files only exist in the current chat context', which sets it apart from deploy_local_files and deploy_local_folder.
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 explicitly states when to use this tool: 'Use this tool if the files only exist in the current chat context.' This gives a clear selection criterion, though it does not name the alternative tools explicitly. The implicit contrast with local deployment tools is present but not spelled out as a formal 'when-not-to-use' statement.
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-run-mcp MCP server](https://glama.ai/mcp/servers/rajath-raman/cloud-run-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rajath-raman/cloud-run-mcp)

Score Badge

Copy to your README.md:

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

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