This server acts as an MCP bridge that enables AI models to query and retrieve data from various cloud services, APIs, and infrastructure through Steampipe's SQL interface.
Core Capabilities:
Execute SQL queries against Steampipe's unified data layer using the run_steampipe_query tool
Access configured data sources including cloud providers (AWS, Azure, GCP), SaaS platforms (GitHub, Slack, Jira, Salesforce), and APIs
Retrieve structured data as JSON for AI processing and analysis
Perform analytics and reporting with aggregations, joins, and complex queries across different sources
Integration with MCP-compatible AI assistants like Claude for conversational infrastructure access
Example Use Cases:
Query GitHub repositories, issues, and pull requests using SQL syntax
Investigate security configurations and compliance across multi-cloud environments
Automate data discovery through natural language requests
Generate reports on resource usage, costs, or cloud infrastructure
Provides access to GitHub repository data through Steampipe, allowing queries for repository information such as names and fork counts.
Click on "Deploy 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., "@mcp-steampipe show me my top 5 GitHub repositories by stars"
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.
This is a simple steampipe MCP server. This acts as a bridge between your AI model and Steampipe tool.
Python 3.10+ installed.
uv installed (my fav) and mcp[cli]
Steampipe installed and working.
Steampipe plugin configured (e.g., github) with necessary credentials (e.g., token in ~/.steampipe/config/github.spc).
Any LLM supporting MCP. I am using Claude Here.
Node.js and npx installed (required for the MCP Inspector and potentially for running some MCP servers).
Related MCP server: steam-mcp
This is an awesome tool for testing your if your MCP server is working as expected
Running the Interceptor
npx -y @modelcontextprotocol/inspector uv --directory . run steampipe_mcp_server.py
A browser window should open with the MCP Inspector UI (usually at http://localhost:XXXX).
Wait for the "Connected" status on the left panel.
Go to the Tools tab.
You should see the run_steampipe_query tool listed with its description.
Click on the tool name.
In the "Arguments" JSON input field, enter a valid Steampipe query:
{
"query": "select name, fork_count from github_my_repository "
}execute and view the json results
Pretty straightforward. Just run the interceptor and make sure the tool is working from the directory. Then add the server configuration to the respective LLM and select the tool from the LLM.
If the tool is not found in the interceptor then that means @mcp.tool() decorator has some issue.
Execution error - Look at the "Result" in the Inspector and the server logs (stderr) in your terminal. Did Steampipe run? Was there a SQL error? A timeout? A JSON parsing error? Adjust the Python script accordingly.
tail -f ~/Library/Logs/Claude/mcp.log
tail -f ~/Library/Logs/Claude/mcp-server-steampipe.logSecurity Risk Claude blindly executes your sql query in this POC so there is possibility to generate and execute arbitary SQL Queries via Steampipe using your configured credentials.
Executes a SQL query using the Steampipe CLI and returns the results as a JSON string.
Args: query: The SQL query to execute via Steampipe (e.g., "select login from github_user limit 1"). Ensure the query is valid Steampipe SQL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
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 states that the tool executes a query and returns JSON results, but lacks critical details such as execution timeouts, error handling, authentication requirements, or rate limits. This leaves significant gaps in understanding how the tool behaves in practice.
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 well-structured and concise, with no wasted words. It starts with a clear purpose statement, followed by a labeled 'Args' section with a bullet point for the single parameter. Each sentence adds value, making it easy to scan and understand quickly.
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's complexity (executing SQL queries with potential side effects) and the lack of annotations and output schema, the description is moderately complete. It covers the basic purpose and parameter semantics but misses behavioral details like error responses, performance considerations, or output structure, which are important for a query execution tool.
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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that the 'query' parameter is 'The SQL query to execute via Steampipe' and provides an example, clarifying that it must be 'valid Steampipe SQL.' This compensates well for the schema's lack of detail, though it doesn't cover all potential edge cases.
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: 'Executes a SQL query using the Steampipe CLI and returns the results as a JSON string.' It specifies the verb ('executes'), resource ('SQL query'), and output format ('JSON string'). However, with no sibling tools mentioned, there's no explicit differentiation from alternatives, preventing a perfect score.
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?
The description provides minimal usage guidance. It includes an example query but does not specify when to use this tool versus other methods (e.g., direct database access or other query tools). There is no mention of prerequisites, error conditions, or typical use cases beyond the basic example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0run_steampipe_queryScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined and distinct by default.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The naming follows a clear verb_noun pattern (run_steampipe_query).
A single tool is too few for most practical purposes, as it severely limits the server's functionality and flexibility. While it might cover the basic query execution, it lacks any supporting operations like listing available tables, checking query status, or managing connections.
The server is severely incomplete for interacting with Steampipe. It only provides query execution, missing essential operations such as listing available plugins/tables, describing table schemas, managing connections, or handling query errors and metadata. This will cause significant agent failures in complex workflows.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Access New Relic observability data through MCP - query metrics, logs, traces, entities, and more
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Query metrics, targets, entities, and team data in your Steep workspace via MCP.
