Kion MCP Server
OfficialClick on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Kion MCP ServerWhat are my total cloud costs this month?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Kion MCP Server
Installation
For more detailed installation and usage instructions, please see oursupport documentation
Claude Desktop Extension
uv is currently a requirement for the desktop extension. Please see installation instructions
Once uv is installed, the Claude Desktop Extension can be installed by downloading the .dxt archive from the releases section, and then the archive can be installed via the extension settings in Claude Destkop, double clicking the file, or dragging the file onto the extension settings.
Dockerhub
Releases are published to the kionsoftware/kion-mcp repository, and can be run directly using docker.
Pypi
This package can be installed via pip.
pip install kion-mcp-server
Related MCP server: mcp-sonarcloud
Development Setup
Install uv
Install uv using homebrew with brew install uv
Install an MCP client
An MCP server needs an MCP client to run it. For development - the mcp inspector is a great tool for getting up and running with the server.
Add this server as a tool
For your MCP client there should be a json file defining what MCP Servers it has access to. Look up where this file is for your client and add something similar to this to it (json objects vary slightly by client check your client's documentation for the exact required JSON. MCP inspector has fields that can be configured directly.):
"KionMcp": {
"command": "uv",
"args": [
"--directory",
"<absolute path to this folder>",
"run",
"kion-mcp-server"
]
}NOTE: sometimes you will need to give an exact path to uv for some clients to work properly. Just run which uv and put the output of that as the command in the JSON
Available Tools
2 toolscheck_config_statusA
Call this tool AFTER manually updating the config file to activate API tools. ONLY call this tool if the setup_kion_config tool required manual config and the user says they've completed those steps. DO NOT CALL IT ON SUCCESSFUL CONFIGURATION.
This tool verifies the configuration is valid and activates all Kion API tools. Only needed if setup_kion_config required manual configuration steps.
After calling this tool, all Kion API tools should be available. If you don't see them, ask the user to send another message.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations exist, the description explains what the tool does: verify configuration and activate all Kion API tools. It also mentions the expected outcome. Could detail potential errors, but adequate for a simple verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with key instructions but has some repetition (e.g., 'Call this tool AFTER...' and 'Only needed if...'). Still mostly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description covers when to call, what it does, and what to expect after calling. Completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description does not need to add parameter info; no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to be called after manual config file update to verify and activate API tools. It specifies the condition and distinguishes from setup_kion_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call (after manual config, only if setup_kion_config required manual steps) and when not to call (on successful configuration). Also ties to sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
setup_kion_configA
REQUIRED SETUP: This Kion MCP Server is missing required configuration.
Call this tool to begin setup. It will try to collect your Kion instance URL and authentication details.
After calling this tool:
If it returns "Configuration completed successfully!" and says tools should now be available, then all Kion API tools are ready. If you don't see them, ask the user to send another message.
If it requires manual configuration, follow the instructions provided, then call check_config_status to activate the API tools.
Once setup is complete, you can use this server to help the user report on their cloud spend, cloud compliance, Kion org chart and budgeting management, and other Kion features.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool attempts to collect URL and auth details, and describes two potential outcomes (success with auto-configuration vs. manual instructions). It doesn't mention side effects, but as a setup 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'REQUIRED SETUP' and uses a structured list for post-call actions. While somewhat verbose, every sentence adds value, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and a sibling tool, the description covers the setup process and follow-up steps. It could mention the output schema more explicitly, but the return messages are described adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description naturally adds no parameter details. Baseline 4 is appropriate as no missing information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a required setup tool for the Kion MCP Server, specifying that it collects instance URL and authentication details. It distinguishes itself from the sibling tool 'check_config_status' by outlining the two possible outcomes, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance: 'Call this tool to begin setup.' It provides step-by-step post-call instructions, including when to use the sibling tool if manual configuration is needed. This fully informs the agent on correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.5.0- First observed
check_config_status - First observed
setup_kion_config
TDQS
The two tools have clearly distinct purposes: setup_kion_config initiates configuration, check_config_status verifies after manual steps. No overlap.
Both tools follow a consistent verb_noun pattern using snake_case (setup_kion_config, check_config_status).
The server advertises features like cloud spend and compliance, but only provides two setup tools. The count is far too low for the stated scope.
The actual API tools for reporting and management are absent. The current tools only handle setup, leaving core functionality missing.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Query OneLens cloud-cost data in natural language: breakdowns, trends, cost centers. Read-only.
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Interact with the Stitch API using natural language commands.
Deploy, monitor, and manage your OpenClaw AI assistants via natural language.
Related MCP Servers
- AlicenseCqualityDmaintenanceEnables AI assistants to manage multi-cloud resources (AWS, Azure, GCP) including resource operations, cost analysis, monitoring metrics, and security compliance checks through natural language commands.26162MIT
- AlicenseAqualityCmaintenanceEnables interaction with SonarCloud projects, issues, quality gates, and security hotspots through natural language.15MIT
- AlicenseNot gradedqualityDmaintenanceEnables natural language interaction with Groundlight to create and manage computer vision detectors, submit image queries, and set up alerts.4Apache 2.0
- AlicenseCqualityDmaintenanceEnables analyzing AWS cloud spending and Bedrock usage through natural language queries using Claude.414MIT No Attribution
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/kionsoftware/kion-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server