Skip to main content
Glama
opsmill

infrahub-mcp

Official
by opsmill
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get Schema

get_schema
Read-only

Discover Infrahub schema kinds, attributes, relationships, and filter keys before querying nodes. Omit kind to list all kinds or specify one for details.

Instructions

Discover available schema kinds — call this first when you don't know what kinds or filters exist.

Without a kind, returns the catalog of all kinds (compact JSON). With a kind, returns its attributes, relationships, and the full set of filter keys accepted by get_nodes (TOON-encoded for token efficiency). Each relationship inlines one level of its peer schema unless expand is False (or the server default disables it).

Prefer reading the infrahub://schema resource if your client supports MCP resources — this tool provides the same data for clients that don't.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoKind to get detail for. Omit to list all available kinds.
branchNoBranch to query. Defaults to the default branch.
expandNoInline one level of each relationship's peer schema. Defaults to the server's INFRAHUB_MCP_SCHEMA_EXPAND_PEERS setting when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Changed1 schema field changedv1.1.7
    • addedInput schema / properties / expand
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Inline one level of each relationship's peer schema. Defaults to the server's INFRAHUB_MCP_SCHEMA_EXPAND_PEERS setting when omitted."
+}
  3. First observedv1.1.5

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only readOnlyHint=true in annotations, the description carries real behavioral weight: it explains the two output modes (catalog vs. per-kind detail with attributes, relationships, and get_nodes filter keys), flags TOON encoding for token efficiency, and documents that expand inlines one peer-schema level subject to a server default. That is far beyond what the annotation declares.

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?

Front-loaded with purpose and the 'call this first' rule, then behavior, then the resource alternative. Every sentence does work; the parenthetical and TOON note are informative rather than filler.

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?

No output schema exists, so the description must explain return values — and it does, distinguishing the two response shapes and their encoding. For a zero-required-parameter discovery tool, nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds output-level meaning: omitting kind yields the full kind catalog while supplying it yields attributes/relationships/filter keys, and expand's effect is restated in terms of relationship inlining. The added value is real but partially overlaps the schema's own parameter descriptions.

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?

States a specific verb+resource ('Discover available schema kinds') and immediately scopes it against siblings: it's the thing you call to learn kinds and filter keys that get_nodes consumes. An agent can distinguish it from get_nodes/query_graphql without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing guidance: 'call this first when you don't know what kinds or filters exist', plus a named alternative for capable clients (the infrahub://schema resource) with the condition that selects the tool instead. Both when-to-use and when-not are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools