platform-mcp

by K-manankov

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.2.1
Disambiguation5/5
Each tool is clearly scoped to either Argo CD or Vault, and within each service the login, auth_status, logout, and exec actions are distinct. The system prefix (argocd_ vs vault_) removes any ambiguity between the two sets.
Naming Consistency5/5
All tool names follow the consistent pattern {service}_{action} using lowercase snake_case: login, auth_status, logout, exec. The naming is uniform and predictable across both Argo CD and Vault.
Tool Count5/5
With 8 tools covering two infrastructure services, the count is well-scoped. Each tool serves a clear and necessary purpose, leaving no redundancy or bloat.
Completeness5/5
For a server designed to provide authenticated CLI access to Argo CD and Vault, the tool surface is complete: login, auth status check, logout, and command execution for each system. The exec tools are generic enough to cover the full command surface of both CLIs.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral consequences. It only states that a saved session is deleted, without explaining side effects (e.g., whether the Vault token is invalidated server-side, whether other sessions are affected, or whether the action is reversible). 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 one short sentence with no redundant words. It is front-loaded and efficient, conveying the full purpose in minimal space.
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 simple nature of a logout tool, the description is adequate but leaves out behavioral details such as idempotency, error outcomes, or whether an active session is required. With no annotations and no output schema, a bit more context would be helpful, but the tool is basic enough that a 3 is appropriate.
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 tool has zero parameters and the schema is trivially 100% covered. Per the baseline rule for 0-param tools, the description need not add parameter details, and the empty schema leaves no room for ambiguity.
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 'Удалить сохранённую сессию Vault' (Delete saved Vault session) uses a specific verb and resource, clearly distinguishing it from siblings like vault_login and vault_auth_status. It leaves no ambiguity about the tool's core 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 siblings such as argocd_logout or vault_login. There is no mention of prerequisites, typical scenarios, or conditions under which this tool should be preferred.
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 bears the full burden of behavioral disclosure. 'Удалить сохранённую сессию' explicitly states that a saved session is deleted, which conveys a clear side effect. However, it does not indicate whether the deletion is purely local or also interacts with the server, and whether it is irreversible.
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 with no filler. Every word contributes to the meaning, and the information is efficiently front-loaded.
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 zero-parameter logout operation, the description is mostly sufficient. It could add a note about the irreversible nature of removing local credentials or that the user must re-authenticate afterwards, but the core behavior is clear enough for such a simple tool.
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 tool has zero parameters and the input schema is fully covered (empty schema). According to the calibration baseline for zero-parameter tools, a score of 4 is appropriate since there is no parameter information to add.
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 'Удалить сохранённую сессию Argo CD' clearly states the action (delete) and the resource (saved Argo CD session), distinguishing it from sibling tools like argocd_login and argocd_auth_status. The verb and object are specific and unambiguous.
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 explicit guidance on when to use this tool or how it relates to alternatives. It does not mention that it reverses argocd_login or that it should be called before checking auth status with argocd_auth_status. Usage context must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds significant behavioral context: server-side address/token injection, JSON output, and secret redaction ('Значения секретов вырезаются'). It omits the __confirm requirement for mutating operations (only in schema), but the redaction and credential handling are valuable disclosures.
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 well-structured: purpose, constraints, examples, and output behavior in three tight paragraphs. The examples are relevant and not excessive, earning their place.
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 generic command executor, it covers execution scope, authentication precondition, output format, and secret safety. The missing confirmation flow is covered in the schema, so the description is sufficiently complete for this 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%, with each parameter having a clear description. The description's examples ('kv get', 'kv put') show how to structure args arrays, but they add practical value rather than deep semantic meaning beyond 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 it executes vault commands on behalf of the logged-in user ('Выполнить команду vault ... от имени вошедшего пользователя'), which distinguishes it from sibling auth tools. Examples like 'kv get' and 'policy read' illustrate the supported operations.
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 specifies a precondition: login via vault_login ('вход делается через vault_login'), and prohibits certain flags (-address, -tls-skip-verify). It doesn't explicitly name alternatives, but sibling tools are clearly auth-only, leaving vault_exec as the execution counterpart.
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, the description carries the full burden of behavioral disclosure. It explains that the address and token are supplied by the server and that certain flags are prohibited, which adds useful context. However, it does not mention potential side effects of mutating commands (e.g., `app sync`) or the confirmation flow described in the `__confirm` parameter schema, nor does it describe error/exit-code handling.
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 well-structured and concise: it front-loads the purpose, then states key constraints, provides illustrative examples, and finishes with a useful tip. Every sentence serves a purpose without unnecessary verbosity.
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 an exec-style tool, the description covers invocation, authentication, forbidden flags, and output format advice. It does not explicitly state the return format (e.g., raw stdout, exit codes) or error handling, which is a minor gap given there is no output schema. Overall, it is sufficient for an agent to use the tool correctly.
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 already provides 100% coverage, but the description goes beyond by showing concrete examples of the `args` array structure and recommending `-o json` for better output parseability. This adds practical meaning that the schema alone does not convey.
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 explicitly states it executes an `argocd` command on behalf of the authenticated user, using a specific verb and resource. It clearly distinguishes itself from sibling tools like `argocd_login`, `argocd_auth_status`, and `argocd_logout` by focusing on command execution rather than authentication. Examples further solidify the scope.
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 clear context for when to use the tool (to run argocd commands) and gives practical advice, such as always adding `-o json` for parseable output and forbidding certain flags (`--server`, `--auth-token`, `--config`, `--core`). However, it does not explicitly state prerequisites like 'authenticate first with argocd_login' or compare with alternative tools for specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses that the tool returns immediately without waiting for login completion, which is a critical non-obvious behavior. It also states that a link is returned, adding useful context, though it doesn't detail side effects or error conditions.
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 highly concise, consisting of two short sentences that immediately convey the main action and the asynchronous behavior. It avoids extraneous details while including the essential next step, making it well-structured and efficient.
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?
The description sufficiently covers the tool's behavior for a simple login initiation: it returns a link and requires follow-up via argocd_auth_status. It doesn't describe the exact response format beyond 'link', but given the simplicity of the tool and absence of output schema, this is adequate. The context provided by sibling tools reinforces the intended workflow.
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 documents the single parameter noBrowser with a clear description in Russian, giving 100% schema coverage. The tool description does not elaborate on this parameter, but since the schema covers it, a baseline score of 3 is appropriate without additional value from the 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 clearly states it initiates an Argo CD login via GitLab SSO and returns a link immediately, using the specific verb 'login' and resource 'Argo CD'. It also distinguishes itself from the sibling argocd_auth_status by noting that the result must be checked via that tool, making the purpose unambiguous.
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 clear usage context by explaining that the login is asynchronous and directing the agent to call argocd_auth_status to verify the result. While it doesn't explicitly exclude other tools or mention preconditions, it effectively guides the agent to the correct workflow among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description adds meaningful behavioral context by specifying the exact output (user identity and token timeout). This is sufficient for a read-only status tool and supports the agent's understanding of what to expect.
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, clear sentence with no redundant information. It is concise and front-loaded, stating exactly what the tool reports.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with no output schema, the description provides all necessary context: it tells the agent what the tool returns and implies its read-only nature. There are no gaps in coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the description carries the full burden by confirming that no arguments are needed. This aligns with the baseline for parameterless tools.
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 explicitly identifies the tool's function: reporting who is logged into Argo CD and the token's expiration. It clearly distinguishes this status query from sibling tools like argocd_login and argocd_logout.
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 nature of a status tool implies it is used to check current authentication state, but no explicit guidance is given about when to use this versus alternatives. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It transparently reveals the asynchronous nature ('returns a link immediately, does not wait for login completion') and instructs to verify via vault_auth_status. This goes beyond basic 'login' expectations, though it does not mention edge cases like already-authenticated states or error handling.
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, front-loaded with the action and key detail (returns a link). Every sentence contributes value: the first states the purpose, the second explains the async behavior and follow-up. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple login tool with one optional parameter and no output schema, the description is complete. It tells the user what to expect (a link) and what to do next (call vault_auth_status). The schema covers the parameter, and the flow is adequately explained.
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 has 100% description coverage for the single parameter 'noBrowser'. The description does not add any additional meaning beyond what the schema already provides, so the baseline of 3 applies. No enhancement or clarification is needed.
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 purpose: 'Start login to Vault via GitLab SSO.' It uses a specific verb ('start login'), names the resource (Vault) and the method (GitLab SSO), and distinguishes itself from sibling tools like vault_logout or vault_auth_status by focusing on initiating the login flow.
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 clear usage context by stating that the tool returns a link immediately and that the result must be checked via vault_auth_status. This implicitly guides the user to follow up with the status check. However, it does not explicitly compare with alternatives like argocd_login, though the resource distinction is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly states what is reported (user and token expiry) and implies it is a read-only status operation. It does not mention prerequisites like 'must be logged in' or error handling, but for a simple status tool this is acceptable.
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 delivers complete meaning without waste. It is front-loaded with the core purpose and adds no redundant details.
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 tool with no parameters, no output schema, and a simple status-check function, the description adequately covers the essential information: who and until when. It does not detail edge cases like unauthenticated state, but that is not critical for this simple tool.
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 tool has zero parameters, and schema coverage is trivially 100%. Per the rubric, the baseline for 0 params is 4; the description appropriately omits parameter details since none exist.
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: showing who is logged into Vault and the token expiration time. It uses a specific verb (status check) and resource (Vault), distinguishing it from sibling tools like argocd_auth_status, which clearly targets ArgoCD.
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 context is evident: this is for checking Vault authentication status, as opposed to login/logout or ArgoCD-related tools. It stops short of explicitly naming alternatives or exclusion criteria, but the intended use is clear from the description and sibling list.
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:

[![platform-mcp MCP server](https://glama.ai/mcp/servers/K-manankov/platform-mcp/badges/card.svg)](https://glama.ai/mcp/servers/K-manankov/platform-mcp)

Score Badge

Copy to your README.md:

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

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