This server provides read-only MCP tools to monitor on-premises Linux VMs and PostgreSQL databases over SSH.
VM & Service Management
list_vms — Discover all configured VMs with reachability status and watched service names
get_service_status — Check systemd state, uptime, and last 5 log lines for a service
get_service_logs — Retrieve bounded journald logs filtered by severity level and line count
get_log_file — Fetch the last N lines of an allowed log file, with optional grep filtering
get_infra_overview — Combined snapshot of service statuses and database health for a VM in one call
Database Inspection
get_db_status — View connection counts, waiting locks, and long-running queries for a PostgreSQL database
query_db — Execute caller-supplied SELECT statements (read-only, row-limited)
list_tables — List all tables (schema + name) in a database, with optional cache refresh
describe_table — Inspect a table's columns, types, primary key, and foreign keys
Auditing
get_audit_log — View recent entries from the local append-only audit log of all remote operations
Safety & Security
All DB queries run in a READ ONLY transaction; SSH commands are checked against per-VM allowlists
Log file access is restricted to an allowed directory list (path traversal blocked)
All output is bounded server-side (200 log lines, 100 DB rows, 200 tables max) with truncation flagged
Provides read-only access to PostgreSQL databases over SSH, allowing agents to query tables, describe schemas, list tables, and check database health metrics such as connection counts and locks.
Read-only MCP access to on-prem Linux VMs and PostgreSQL databases over SSH.
agent ──stdio──▶ infra-mcp ──SSH──▶ VMs (journald · log files)
└──▶ DBs (read-only PostgreSQL)An agent can check service health, retrieve bounded logs, inspect DB state, and explore table schemas — without terminal access. Every remote operation is allowlist-gated and written to an append-only audit log.
uv tool install infra-mcp
# or
pip install infra-mcpRelated MCP server: mcp-infra-readonly
Copy infra-mcp.yaml.example to ~/.infra-mcp/infra-mcp.yaml and edit it.
# Generate a starter config from ~/.ssh/config
infra-mcp generate-config -o ~/.infra-mcp/infra-mcp.yaml
# Create the read-only PostgreSQL role(s)
infra-mcp setup
# Check VM reachability
infra-mcp test
# Refresh discovered services, log dirs, and databases (updates config in place)
infra-mcp discover --in-placeOverride the config path with --config or INFRA_MCP_CONFIG.
infra-mcp runRegister as a stdio MCP server in your client (Claude Code, Cursor, …) with command infra-mcp run.
infra-mcp checks PyPI for a newer release once a day and, when one exists, prints a
one-line hint to stderr telling you how to upgrade:
uv tool upgrade infra-mcp # or: pip install --upgrade infra-mcpThe check runs in the background, never blocks startup, and never touches stdout. Print
the installed version with infra-mcp --version. Disable the check entirely by setting
INFRA_MCP_NO_UPDATE_CHECK=1.
Tool | Purpose |
| All VMs with reachability and watched services |
| Service states + DB health for one VM in a single call |
| systemd state, uptime, last 5 log lines |
| Bounded journald logs, filtered by severity |
| Last N lines of an allowed log file, optional grep |
Tool | Purpose |
| Connection counts, waiting locks, long-running query count |
| Bounded caller-supplied |
| Tables in a database (schema + name), capped at 200 |
| Columns, types, primary key, foreign keys for one table |
Tool | Purpose |
| Recent entries from the local audit log |
All output is bounded server-side (200 log lines, 100 DB rows, 200 tables/columns max). Truncation is always flagged with a -- TRUNCATED: marker. list_tables and describe_table cache results in memory (TTL: schema_cache_ttl_hours, default 24 h); pass refresh: true to force a live re-read.
SSH commands and systemd services are checked against a per-VM allowlist before any network call.
All DB queries run as a read-only role inside a READ ONLY transaction.
Log file paths are resolved against a per-VM directory allowlist (.. traversal blocked).
Every remote operation is appended to a local JSONL audit log.
Describes one named table — its columns and types, primary key, and foreign-key relationships — scoped to just that table, so you can author a correct (possibly multi-table) query directly. Indexes and comments are not included. Set refresh=true to force a live re-read.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Database name as defined in infra-mcp.yaml | |
| table | Yes | Table name; use schema.table to disambiguate across schemas | |
| refresh | No | Skip the in-memory cache and force a live re-read |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses caching behavior and refresh capability, and states what is excluded. Is a read operation implicitly. Lacks explicit safety statements but is transparent.
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?
Two sentences, front-loaded with purpose, no filler. Each sentence adds value (purpose, exclusions, refresh). Highly concise.
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?
Has output schema so return details not needed. Describes included and excluded content, refresh behavior. Could mention permission requirements but not critical. Generally complete for a schema description 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?
100% schema coverage, so baseline 3. Description adds no additional meaning beyond schema: 'schema.table' disambiguation is already in schema param description, and refresh behavior is also in schema. No extra context for parameters.
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?
Clearly states it describes one table's columns, types, primary key, and foreign keys. Distinguishes from sibling list_tables (lists names only) and query_db (runs queries) by scoping to a single table and including schema details.
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?
Implies use for authoring correct queries, mentions excluded features (indexes, comments), and explains refresh behavior. Does not explicitly compare to alternatives but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns recent entries from the local audit log (oldest first).
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Maximum entries to return; server-capped at 200 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only mentions ordering and that entries are 'recent', which is vague. It does not indicate read-only nature, authentication needs, rate limits, or any side effects. This is insufficient for a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that efficiently conveys the tool's purpose and ordering. No wasted words or repetition. Ideal brevity.
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?
The description covers the basic purpose and ordering, and an output schema exists so return values need not be explained. However, vagueness around what constitutes 'recent' and lack of any additional context (e.g., log retention, clearing) makes it only minimally complete for a simple 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?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning for the 'lines' parameter beyond what the schema already provides (default and cap). No improvement or degradation.
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 returns recent entries from the local audit log with oldest first ordering. The verb 'Returns' and resource 'audit log' are specific, and the ordering detail adds value. However, it does not explicitly differentiate from sibling tools like get_log_file, though the name implies distinct purpose.
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?
No guidelines on when to use this tool versus alternatives like get_log_file or get_service_logs. No prerequisites or context for usage are provided. The description simply states what it does without any direction on appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns health metrics for a configured database: connection counts, waiting locks, and long-running query count.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Database name as defined in infra-mcp.yaml |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes the output but does not mention side effects, permissions required, caching, or rate limits. It is adequate but thin for a read-only tool.
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 a single concise sentence that front-loads key information. Every word adds value, and there is no redundancy or verbosity.
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 one parameter and an output schema, the description provides sufficient context on what the tool returns (three health metrics). It could mention permissions or prerequisites, but overall it is complete enough for a simple 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 schema already covers the 'db' parameter with a clear description ('Database name as defined in infra-mcp.yaml'). The description adds no additional meaning beyond implying the parameter specifies which database.
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 returns health metrics for a configured database, listing specific metrics (connection counts, waiting locks, long-running query count). This is specific and distinguishable from sibling tools like get_service_status or get_infra_overview.
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 implies usage for checking database health, but does not explicitly state when to use this tool versus alternatives. No when-not or alternative guidance is provided, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns service statuses and database health for a named VM in a single call. Call this first when diagnosing any VM-level issue. Unreachable services or databases are listed with an error note rather than failing the whole call.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes | VM name as defined in infra-mcp.yaml |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that unreachable components are listed with error notes rather than failing globally, which is valuable. However, it does not specify behavior if the VM itself does not exist, leaving a minor 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second gives usage advice and behavioral note. Every sentence earns its place, and the description is front-loaded.
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 one simple required parameter, the description covers purpose, usage priority, and error handling sufficiently. No critical information is missing for an agent to correctly invoke the 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?
Only one parameter with 100% schema coverage, and the schema already describes it. The description adds context that the VM name is defined in infra-mcp.yaml, linking to an external source, which enhances understanding beyond the schema.
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 returns service statuses and database health for a named VM, using a specific verb and resource. It distinguishes from sibling tools like get_service_status (single service) and get_db_status (database only) by offering a combined overview.
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 advises to call this first when diagnosing any VM-level issue, providing a clear usage priority. Also describes error behavior (unreachable services listed with notes instead of failing) which helps the agent decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the last N lines of a log file on a VM, with optional grep pattern. Both grep and line-capping execute on the VM before any data is transmitted.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes | VM name as defined in infra-mcp.yaml | |
| path | Yes | Absolute path to the log file; must be under a configured log_dirs entry | |
| lines | No | Maximum lines to return; server-capped at 200 | |
| pattern | No | Extended regex applied on the VM before transmission (grep -E) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses a key behavioral trait: grep and line-capping execute on the VM before data transmission. However, it does not mention potential side effects, authorization needs, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences effectively communicate purpose and key behavior with no wasted words. The structure is front-loaded with the primary action.
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?
The description covers the main functionality and a key behavioral detail. With an output schema present, the return values do not need explanation. However, it could mention prerequisites like VM availability or file existence.
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?
Schema description coverage is 100%, so baseline is 3. The description adds the behavioral note that processing occurs on the VM, but does not provide additional semantic meaning beyond the existing schema descriptions for each parameter.
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 returns the last N lines of a log file on a VM with optional grep pattern, specifying verb and resource. It distinguishes from siblings like get_service_logs by focusing on VM-level log files.
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?
No guidance is provided on when to use this tool over alternatives such as get_service_logs or get_audit_log. The description lacks context for choosing this tool among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns bounded journald logs for a service, filtered by severity level. Filtering and line-capping execute on the VM before transmission.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes | VM name as defined in infra-mcp.yaml | |
| service | Yes | systemd service name; must be in the VM's allowlist | |
| level | No | Minimum severity to include: error | warning | info | debug | error |
| lines | No | Maximum lines to return; server-capped at 200 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that filtering and line-capping execute on the VM before transmission, adding value beyond no annotations. However, lacks details on error handling or authentication needs.
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?
Two efficient sentences with no waste, front-loaded with the core action and a key behavioral detail.
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?
With output schema present, return value explanation not needed. Covers core functionality but misses edge cases like invalid VM/service. Adequate for a straightforward log retrieval 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?
Schema coverage is 100% with good parameter descriptions. The description adds only the processing location context; does not significantly enhance understanding beyond schema.
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 returns bounded journald logs for a service filtered by severity level, specific verb+resource with clear scope, distinguishing from siblings like get_audit_log or get_log_file.
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?
No explicit guidance on when to use versus alternatives. Implied usage for service logs, but lacks when-not-to-use or comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns systemd state, uptime, and last 5 log lines for a service on a VM. Use for a quick health check before requesting full logs.
| Name | Required | Description | Default |
|---|---|---|---|
| vm | Yes | VM name as defined in infra-mcp.yaml | |
| service | Yes | systemd service name; must be in the VM's allowlist |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return data clearly and implies a read-only operation. No side effects mentioned, but for a simple status check, this is sufficient.
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?
Two sentences with no wasted words. The first sentence states the output, the second gives usage guidance. Front-loaded and 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 a simple tool with 2 parameters and an output schema, the description fully covers what data is returned and when to use it, meeting all needs for this low-complexity 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?
Schema coverage is 100% with descriptive parameter names and descriptions. The description does not add extra semantics beyond the schema, so baseline 3 is appropriate.
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?
Clearly states it returns systemd state, uptime, and last 5 log lines for a service on a VM, distinguishing itself from siblings like get_service_logs by positioning as a quick health check.
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 'Use for a quick health check before requesting full logs,' providing context and implicitly contrasting with the full log tool. Could add more exclusions or prerequisites but is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the tables of a configured database with their schema/namespace, in one bounded call — no column detail. Call this first to decide which tables are relevant before describing them. Set refresh=true to force a live re-read.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Database name as defined in infra-mcp.yaml | |
| refresh | No | Skip the in-memory cache and force a live re-read |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: bounded call (no pagination), no column detail, and caching mechanism with refresh option. Additional details like side effects or auth are not needed for a read-only listing tool.
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?
Three sentences, front-loaded with core purpose, no redundant prose. Every sentence adds value: purpose, usage guidance, and optional parameter behavior.
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 low complexity (2 params, output schema exists), the description fully covers what an agent needs to know: what it returns, how to use it sequentially, and optional behavior. No gaps remain.
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?
Schema coverage is 100%, so the schema already documents both parameters adequately. The description reiterates the refresh behavior but adds no new semantic insight beyond what the parameter descriptions provide. Baseline 3 is appropriate.
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 lists tables of a configured database with schema/namespace, explicitly noting it is a bounded call with no column detail. This distinguishes it from siblings like describe_table, which likely provides column info.
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 advises calling this first to decide which tables are relevant before describing them, implying a sequential use with describe_table. It also explains when to set refresh=true. While no explicit when-not is given, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all configured VMs with reachability status and watched service names. Call this first in any session to discover available infrastructure.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the output but does not mention safety, authorization, rate limits, or side effects. The 'call first' hint implies it is a safe read operation, but lacks explicit transparency.
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?
Two sentences, both essential and front-loaded. The first defines the tool's function, the second provides crucial usage guidance. No wasted words.
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 absence of parameters and the presence of an output schema, the description effectively covers the tool's purpose and usage context. Mentioning specific output attributes and ordering it first in sessions completes the picture.
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 exist, so schema coverage is automatically 100%. The baseline for 0 params is 4, and the description adds no parameter information, which is acceptable.
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 returns all configured VMs with specific attributes (reachability status, watched service names), distinguishing it from sibling tools that focus on databases, logs, or other infrastructure.
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 advises calling this tool first in any session to discover infrastructure, providing clear usage context. It does not list exclusions or alternatives, but the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes a caller-supplied SELECT statement against a configured database, bounded by row limit. Only SELECT is permitted.
| Name | Required | Description | Default |
|---|---|---|---|
| db | Yes | Database name as defined in infra-mcp.yaml | |
| sql | Yes | SELECT statement to execute; non-SELECT statements are rejected | |
| limit | No | Maximum rows to return; server-capped at 100 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that only SELECT is allowed and that results are bounded by a row limit, but does not mention logging, error handling, or if the operation is read-only (though implied). The description adds limited value beyond the schema, which already states the SELECT restriction.
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?
Single sentence that clearly states the tool's action and key constraint. No unnecessary words; front-loaded with the verb and resource.
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?
For a simple query tool with 3 parameters and an output schema (known from context), the description is mostly adequate. It states the operation and constraint. However, it could briefly mention that the result format is handled by the output schema. Still, it covers essential behavioral information.
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?
Input schema has 100% coverage, providing descriptions for all three parameters. The description does not add substantial meaning beyond what the schema already offers; it only reiterates the row limit bound. Baseline score of 3 is appropriate.
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?
Description explicitly states the action 'Executes a caller-supplied SELECT statement' against a configured database, clearly identifying the resource and operation. It distinguishes from sibling tools like describe_table and list_tables by focusing on executing arbitrary SELECT queries.
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?
Description implies usage for running SELECT queries but does not specify when to use this tool versus alternatives like describe_table or list_tables. No explicit when-not-to-use guidance is provided, only the constraint that only SELECT is permitted.
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. Dates show when Glama detected each change.
v0.1.2describe_table3 fields changedInput schema / properties / db / descriptionAdded value: +"Database name as defined in infra-mcp.yaml"Input schema / properties / refresh / descriptionAdded value: +"Skip the in-memory cache and force a live re-read"Input schema / properties / table / descriptionAdded value: +"Table name; use schema.table to disambiguate across schemas"get_audit_log1 field changedInput schema / properties / lines / descriptionAdded value: +"Maximum entries to return; server-capped at 200"get_db_status1 field changedInput schema / properties / db / descriptionAdded value: +"Database name as defined in infra-mcp.yaml"get_infra_overview1 field changedInput schema / properties / vm / descriptionAdded value: +"VM name as defined in infra-mcp.yaml"get_log_file4 fields changedInput schema / properties / lines / descriptionAdded value: +"Maximum lines to return; server-capped at 200"Input schema / properties / path / descriptionAdded value: +"Absolute path to the log file; must be under a configured log_dirs entry"Input schema / properties / pattern / descriptionAdded value: +"Extended regex applied on the VM before transmission (grep -E)"Input schema / properties / vm / descriptionAdded value: +"VM name as defined in infra-mcp.yaml"get_service_logs4 fields changedInput schema / properties / level / descriptionAdded value: +"Minimum severity to include: error | warning | info | debug"Input schema / properties / lines / descriptionAdded value: +"Maximum lines to return; server-capped at 200"Input schema / properties / service / descriptionAdded value: +"systemd service name; must be in the VM's allowlist"Input schema / properties / vm / descriptionAdded value: +"VM name as defined in infra-mcp.yaml"get_service_status2 fields changedInput schema / properties / service / descriptionAdded value: +"systemd service name; must be in the VM's allowlist"Input schema / properties / vm / descriptionAdded value: +"VM name as defined in infra-mcp.yaml"list_tables2 fields changedInput schema / properties / db / descriptionAdded value: +"Database name as defined in infra-mcp.yaml"Input schema / properties / refresh / descriptionAdded value: +"Skip the in-memory cache and force a live re-read"query_db3 fields changedInput schema / properties / db / descriptionAdded value: +"Database name as defined in infra-mcp.yaml"Input schema / properties / limit / descriptionAdded value: +"Maximum rows to return; server-capped at 100"Input schema / properties / sql / descriptionAdded value: +"SELECT statement to execute; non-SELECT statements are rejected"describe_tableget_audit_logget_db_statusget_infra_overviewget_log_fileget_service_logsget_service_statuslist_tableslist_vmsquery_dbEach tool targets a distinct resource or action: tables (list, describe, query), VMs (list, overview), services (status, logs), logs (file, service), database health, audit log. No overlap in purpose.
All tool names follow a consistent verb_noun pattern (describe_table, get_audit_log, list_vms, etc.), making it easy to infer functionality.
10 tools is appropriate for infrastructure diagnostics, covering VMs, databases, services, logs, and audit without being excessive or sparse.
The tool set provides complete coverage for read-only infrastructure diagnosis: discovering VMs, checking health, exploring database schemas, querying data, and retrieving logs. No obvious gaps for its diagnostic purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/esp4ce/infra-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
