OpenShift MCP Server

Server Quality Checklist

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

Latest release: v1.2.0
Disambiguation5/5
Each tool maps to a distinct OpenShift operation (get vs. describe vs. create vs. apply, etc.) with clear boundaries. The functions are well-separated and unlikely to be confused.
Naming Consistency5/5
All tools follow a consistent oc_ prefix with snake_case verb or noun forms (e.g., oc_describe, oc_new_app, oc_api_resources). The naming pattern is uniform and predictable.
Tool Count5/5
14 tools is well within the ideal range for a domain-specific server covering common OpenShift operations. Each tool serves a necessary purpose without redundancy.
Completeness5/5
The set covers the full lifecycle: authentication (login), resource discovery (api_resources, explain), creation/updating (create, apply, patch, new_app), inspection (get, describe, logs), scaling, exposure, and deletion. Operators are also supported. No critical gaps for typical cluster management.
Average 3.2/5 across 14 of 14 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior1/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 says 'Create' and gives examples, offering no information about idempotency, failure behavior, authentication requirements, or side effects. This is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified for a tool with 13 parameters. It lacks structure and additional context, making it efficient yet incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 13 optional parameters and no output schema or annotations. The description provides only a vague overview, failing to explain parameter relationships, return values, or usage scenarios across different resource types. It is far from 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%, so the baseline is 3. The description adds no parameter-specific meaning, leaving the schema's individual parameter descriptions to carry the semantics.
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 OpenShift resources, listing examples like projects, deploymentconfigs, and routes. However, it does not distinguish from sibling tools such as oc_apply or oc_new_app, which also create resources.
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 regarding when to use oc_create versus alternatives like oc_apply or oc_new_app. The description gives no context for choosing this tool over its 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?
With no annotations, the description must carry the burden of disclosing behavioral traits. It only offers a vague claim about 'comprehensive error handling and validation' without specifics on side effects, idempotency, cluster requirements, or handling of conflicts. This is insufficient for a mutating tool with 20 parameters.
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 very concise and front-loaded with the core action. However, the phrase 'for all scenarios' is vague and adds little value, slightly reducing the score from a perfect 5.
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 tool with 20 parameters, no annotations, and no output schema, a one-sentence description is inadequate. It fails to mention the various input modes (URL, file, manifest, kustomize), prunability, server-side apply, or wait/force options, leaving major gaps in understanding the tool's full capabilities.
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 all 20 parameters (100% coverage), so the description need not add parameter details. The description adds no parameter-specific meaning, but the schema is thorough, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies YAML manifests to an OpenShift cluster. The verb 'apply' is specific and implies create-or-update behavior, distinguishing it from siblings like oc_create or oc_delete, though it does not 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 provides no guidance on when to use this tool versus alternatives such as oc_create, oc_patch, or oc_delete. No scenarios or exclusion criteria are mentioned, leaving the agent to infer usage 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 only states a high-level action and does not disclose side effects (e.g., creating a Route object), overwrite behavior, permission requirements, or failure modes, which are critical for a mutating Kubernetes/OpenShift tool.
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, focused sentence with no redundant words. It front-loads the action and includes a useful parenthetical resource list, though it could be more detailed for a tool this complex.
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 20 parameters and no output schema, a one-sentence description is inadequate. It does not explain prerequisites, route creation semantics, or interaction with existing routes, leaving the agent without sufficient context to invoke the tool correctly.
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 the baseline is 3. The description adds no parameter-specific meaning—it only mentions secure route endpoints and TLS termination, which loosely aligns with routeType/certificate params but doesn't clarify them beyond the schema.
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 uses the specific verb 'Expose' and identifies the resource types (service, deployment, etc.) and key capability (secure route endpoints with SSL/TLS termination). It distinguishes from sibling tools like oc_create or oc_apply by focusing on route-based exposure, though it doesn't explicitly say 'creates a route'.
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 explicit when-to-use or alternatives are provided. The description implies usage for exposing resources with TLS termination but does not contrast with sibling tools like oc_create or oc_apply, which could also create routes.
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 only says 'Get...' without mentioning whether the operation is read-only, how output is returned, potential permissions needed, or any side effects. This leaves critical behavioral ambiguity for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb and resource examples. It is concise and free of fluff, though it could be expanded to include more contextual structure without becoming verbose.
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 8 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain the return format, default behavior, or when to use optional parameters like fieldSelector or allNamespaces, making the tool difficult to invoke correctly without additional knowledge.
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 has 100% description coverage, including examples for resourceType. The tool description adds no extra parameter-specific meaning beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets OpenShift resources and provides examples such as pods, deploymentconfigs, routes, and projects. It does not explicitly differentiate from sibling tools like oc_describe, but the verb 'get' and resource list make the primary purpose understandable.
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 offers no guidance on when to use this tool versus alternatives like oc_describe or oc_logs. There is no mention of exclusions, preferred scenarios, or distinctions from sibling tools, leaving the agent without clear selection criteria.
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, so the description bears full responsibility for behavioral disclosure. It states that the tool patches resources, implying modification, but does not disclose that it mutates existing resources, may require specific permissions, can be dangerous with force, or that dryRun is available. Deeper behavioral context is absent.
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 directly states the purpose. It contains no redundant words and efficiently conveys the core functionality.
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 11 parameters, no annotations, and no output schema, the description is too sparse to give a complete picture. It lacks information about return values, side effects, error scenarios, or practical examples, leaving the agent to infer most behavioral context from the schema alone.
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?
Input schema coverage is 100%, so the baseline is 3. The description adds a little value by explicitly naming the three patch types, which maps to the patchType parameter, but it does not add syntax or usage details beyond what the schema already documents.
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 action ('Patch') and resource scope ('OpenShift resources'), and names the three patch operation types (strategic merge, JSON merge, JSON patch). It is specific enough to distinguish from create/delete/scale, but does not explicitly contrast with sibling tools like oc_apply, which also modifies resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as oc_apply, oc_create, or oc_scale. There is no mention of prerequisites, typical use cases, or when to choose a specific patch type.
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 bears the full burden. It only states the high-level purpose and does not disclose whether the operation is read-only, what output formats are supported, or any side effects. This is minimal behavioral disclosure beyond the name and purpose.
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 with no fluff. It effectively communicates the tool's core purpose, though it could be enhanced with a second sentence about usage without adding much length.
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 tool has 6 parameters and no output schema, yet the description provides only a high-level purpose. It does not mention the return format, how field paths work, or how it interacts with the OpenShift API. Given the tool's complexity, this is insufficient for an agent to fully understand its capabilities.
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?
All parameters have detailed descriptions in the input schema (100% coverage). The description adds no parameter-specific information, so the baseline of 3 applies. The schema adequately explains the parameters.
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 purpose: explaining OpenShift/Kubernetes resource schemas, fields, and API documentation. It uses a specific verb and resource, and the scope is clear, though it does not explicitly differentiate from sibling tools like oc_describe or oc_api_resources.
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 usage context is implied by the purpose: when you need to understand schemas or fields, this tool is the choice. However, there is no explicit guidance on when to use this vs alternatives, no exclusions, and no mention of specific use cases.
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 mentions output formats, omitting important traits like whether it requires an authenticated cluster, whether it is read-only, error behavior, or what a human-readable summary includes.
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 states the core action and key output capability. It is appropriately concise, though the word 'share' is slightly vague and could be replaced with clearer language like 'returns' or 'displays'.
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 minimally viable: it states the action and mentions output formats, and the schema covers all parameters. However, given the ambiguity among sibling tools and the lack of annotations or output schema, it could benefit from usage guidance and behavioral details to be 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%, so the input schema fully documents all five parameters. The description adds no additional meaning beyond mentioning output formats, which the schema already captures via the 'output' enum and description.
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 the specific verb 'Describe' and names the resource type ('any OpenShift resource'), clearly distinguishing it from siblings like oc_get and oc_explain. It also mentions the key differentiator of multiple output formats, including human-readable summary.
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?
There is no explicit guidance on when to use this tool instead of oc_get or oc_explain. The description implies a describe operation, but does not state when this is preferred over alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description mentions 'streaming options' which implies follow behavior, but it does not disclose potential long-running operations, large log outputs, or permission requirements. This lack of detail leaves the agent without important behavioral awareness.
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 efficiently conveys the tool's purpose. It is appropriately sized with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters) and lack of annotations or output schema, the one-sentence description provides only a high-level overview. While the schema fills in parameter details, the description does not address usage context, edge cases, or alternatives, leaving the agent with limited guidance for selection.
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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides, such as examples or interaction effects between parameters.
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 'Get logs from OpenShift resources' with specific resource examples (pods, deployments, builds). This distinguishes it from sibling tools like oc_get or oc_describe, which serve different purposes. The verb 'Get' and resource 'logs' provide a clear, specific 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 does not provide any guidance on when to use this tool versus alternatives. It neither names alternative tools nor gives exclusions. However, the explicit focus on logs implies a distinct use case, but it's not directly stated.
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 mentions 'comprehensive safety checks, validation, and error handling' but these are vague and unsubstantiated. It doesn't disclose specific behaviors like confirmation prompts, dry-run capabilities, or destructive consequences, which is a significant gap for a deletion 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 sentence that front-loads the primary action ('Delete OpenShift resources') and avoids redundancy. The additional phrase 'with comprehensive safety checks, validation, and error handling' is generic but does not bloat the description excessively.
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 destructive tool with 20 parameters, no annotations, and no output schema, the description is severely under-specified. It doesn't explain when deletion occurs, what safety mechanisms exist, how to choose between manifest/name/selector based deletion, or what the expected results are. This inadequacy could lead to misuse.
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 all 20 parameters (100% coverage), so the description doesn't need to explain them. It adds no additional parameter semantics beyond the schema, but the baseline of 3 is appropriate given the 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 uses a specific verb ('Delete') and resource ('OpenShift resources'), making the tool's purpose unambiguous. It distinguishes well from sibling tools like oc_create, oc_apply, and oc_get, which handle different lifecycle operations.
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 deleting resources but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It doesn't mention scenarios like manifest-based deletion vs. inline resource selection, leaving the when-to-use context underdeveloped.
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. It mentions 'securely' but does not disclose side effects such as modifying kubeconfig, persisting credentials, changing the current context, or requiring network access to the cluster. This is a notable gap for a login tool that changes state.
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 auth methods, with no filler words. It is appropriately sized.
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 tool has 10 parameters and no output schema or annotations, yet the description only covers the basic login action. It omits important context like the effect on the local kubeconfig, the need for network access to the server, and how login interacts with other oc tools. This is insufficient for an AI agent to fully understand usage and consequences.
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 already provides detailed descriptions for all 10 parameters, including conditional requirements (required if authMethod is token/password). The description adds no additional parameter-level meaning beyond restating the auth methods, so it does not improve on the schema.
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 action (log into) and resource (OpenShift cluster), and explicitly lists the authentication methods (username/password or token). This distinguishes it from sibling tools like oc_get or oc_apply, which perform cluster operations rather than authentication.
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 a prerequisite for other oc commands but does not explicitly state when to use it or when not to use it, nor does it mention alternatives. There is no guidance about requiring an existing cluster connection or how it fits into a workflow.
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 mentions the main action but omits important behavioral details such as automatic namespace creation (createNamespace defaults to true), what OpenShift resources are created (BuildConfig, DeploymentConfig, Service, Route), and behavior if the app already exists. This is limited transparency for a mutating 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 sentence that front-loads the verb and resource, is free of filler, and every word contributes. It is appropriately sized for its purpose.
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 13 parameters, no annotations, and no output schema, a single-sentence description is insufficient. It lacks context on the overall workflow, prerequisites, side effects, and how parameters relate (e.g., how builderImage interacts with strategy). The description does not explain what the user should expect to happen after invoking the tool.
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 the baseline is 3. The description adds no extra meaning beyond the schema; references to 'S2I build' and 'edge-terminated route' are already reflected in parameters like strategy and exposeRoute. No further parameter interaction or format details are given.
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 action ('Create a new application'), the resource ('from a GitHub repository'), and the method ('using S2I build and expose it with an edge-terminated route'). This distinguishes it from siblings like oc_create (generic create) and oc_expose (route-only).
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 context is implied: this tool is for creating a new app from a GitHub repo with S2I. However, there is no explicit when-to-use guidance or mention of alternatives among sibling tools such as oc_create or oc_apply. No exclusions or decision criteria are provided.
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. It states that it installs an operator but does not disclose side effects like namespace creation, CRD installation, or OLM subscription behavior. The schema hints at createNamespace and installPlanApproval, but the description itself lacks behavioral detail.
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 key information: install, operator, cluster, and methods. Every word earns its place with no 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?
For a complex tool with 10 parameters and multiple installation methods, the description is minimal. It provides a high-level overview but lacks guidance on how to select the source method or what happens after installation. The schema provides detailed parameter descriptions, but the overall context is incomplete.
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 fully documents each parameter. The description adds no additional parameter context or examples, providing no value beyond the schema. 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 clearly states the verb 'Install' and the resource 'an Operator' on an OpenShift/Kubernetes cluster, specifying three installation methods. This distinguishes it from sibling tools like oc_create or oc_apply, which handle general resource creation, while this is specific to operator installation.
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 context by mentioning OLM, Helm, or direct manifests, but does not explicitly state when to choose this tool over alternatives or when to use each source method. It gives no exclusions or prerequisites, leaving the agent to infer from the schema.
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 transparency burden. 'List' signals a read-only operation, but the description does not explicitly note that it makes no changes, nor does it disclose behavior like cluster context usage or output structure beyond 'details'.
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 to stating the tool's action and scope.
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 read-only discovery tool, the description combined with a fully documented schema is largely sufficient. It lacks an explicit note about return format or output structure (no output schema exists), and no annotations add safety context, but the core purpose and parameters are covered.
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 six parameters are fully documented in the schema with types, defaults, and examples. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema handles the heavy lifting.
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 distinct resource ('all available API resources in the OpenShift cluster'), clearly differentiating from siblings like oc_get or oc_explain that target specific resources or explanations. It communicates both action and scope in a single sentence.
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 discovering API resources but provides no explicit when-to-use, prerequisites, or alternatives. It does not mention when to prefer oc_explain or oc_get, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately discloses the core behavior—changing replica counts—but does not mention side effects like rolling updates, potential downtime when scaling down, or required permissions. With no annotations, the description carries a moderate burden, but it remains truthful and understandable.
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 gets straight to the point without any filler. It is well-structured and easy to parse, conveying the essential action and resource types efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the five parameters are fully documented in the schema, the description covers the core purpose adequately. The only missing context is what the command returns (e.g., status output), but for a scaling operation this is not critical and the description is otherwise complete for execution.
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 descriptions already provide the necessary semantics. The tool description adds minimal additional value beyond stating the replica count target, which is already covered by the 'replicas' parameter description.
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 ('Scale') and clearly identifies the action ('number of pods') and the target resources ('deployment, deploymentconfig, replicaset, or statefulset'). This distinguishes it from sibling tools like oc_delete or oc_patch by specifying the scaling action and resource scope.
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 intended usage is implied by the name and description: use it to scale pod counts on a set of resource types. However, there is no explicit 'when to use' guidance or mention of alternatives like oc_patch for updating replicas, leaving some ambiguity for agents comparing tools.
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-server-openshift MCP server](https://glama.ai/mcp/servers/sanjaypsachdev/mcp-server-openshift/badges/card.svg)](https://glama.ai/mcp/servers/sanjaypsachdev/mcp-server-openshift)

Score Badge

Copy to your README.md:

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

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/sanjaypsachdev/mcp-server-openshift'

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