Building and Operating an MCP Server for LLM-Powered Cloud Infrastructure Queries

cloudquery · Tech · 2025 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: MCP cloud-infrastructure querying

CloudQuery wanted Claude and Cursor to query a cloud infrastructure database through an MCP server, but production use exposed brittle tool selection, context-window overload, and nondeterministic SQL/tool behavior.

Constraints:

LLMs choose tools based heavily on name and description semantics.
Cloud infrastructure schemas can exceed context windows.
Even temperature-zero calls can choose different tools or SQL.
The server had to expose complex database discovery safely through tool workflows.

Architecture

CloudQuery built a Go MCP server exposing cloud-infrastructure database tools to Claude and Cursor. They expanded terse tool descriptions from about 50 to about 400 characters, renamed ambiguous tools, embedded multi-tool workflow instructions, filtered schema output with Go regexes and ranking heuristics, and reduced schema tokens so the model could follow a discovery-to-execution path.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  claude-or-cursor[Claude Or Cursor] --> mcp-server[MCP Server]
  mcp-server --> tool-descriptions[Tool Descriptions]
  tool-descriptions --> workflow-instructions[Workflow Instructions]
  workflow-instructions --> claude-or-cursor[Claude Or Cursor]
  mcp-server --> schema-filter[Schema Filter]
  schema-filter --> cloud-infrastructure-database[Cloud Infrastructure Database]
  mcp-server --> cloud-infrastructure-database[Cloud Infrastructure Database]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Claude Or Cursor`	LLM client that calls MCP tools to answer infrastructure questions.	`MCP Server`
`MCP Server`	Go server registering tools and handlers for infrastructure database access.	`Tool Descriptions`, `Workflow Instructions`, `Schema Filter`, `Cloud Infrastructure Database`
`Tool Descriptions`	Long domain-specific descriptions used by LLMs to choose the right tool.	`Claude Or Cursor`, `MCP Server`
`Workflow Instructions`	Embedded ordered steps for discovery-to-execution tool use.	`Tool Descriptions`, `Claude Or Cursor`
`Schema Filter`	Trims schema output before sending it to the LLM.	`MCP Server`, `Cloud Infrastructure Database`
`Cloud Infrastructure Database`	Cloud asset inventory tables queried by the LLM through MCP tools.	`MCP Server`, `Schema Filter`

Data flow

Claude or Cursor reads MCP tool schemas, starts with plugin discovery, searches for relevant tables, retrieves detailed schemas and columns, filters large schema output before context insertion, then executes SQL against CloudQuery infrastructure data.

“In the context of an MCP server and LLMs, a tool is a function or endpoint that the LLM can call explicitly during a session.”article, stated

“This explicit sequencing transformed everything. Instead of Claude making random tool calls or hallucinating table structures”article, stated

Why this architecture

CloudQuery found that software-engineer-style concise tool docs were invisible or ambiguous to LLMs. The MCP server needed verbose semantic descriptions, explicit workflows, and schema filtering so the LLM could discover data structures rather than hallucinate tables or drown in raw schemas.

“Initially, we wrote the descriptions as if another engineer would read them. Short and terse, in order to conserve the size of our context window”article, stated

“It seemed obvious: why waste words? But in practice, Claude would call this tool sparingly, misinterpret what it was for, or outright ignore it. Instead of exploring our data, it would hallucinate tables or query against nonexistent schemas.”article, stated

Models used: Claude · Cursor · GPT

Scale

Tool description length increased from about 50 to about 400 characters.
“The character count increased from ~50 to ~400, and response quality improved dramatically. Instead of guessing, Claude systematically queried the tool to understand the data structure before proceeding.”article, stated
A raw CloudQuery schema dump can exceed 50,000 tokens.
“We learned this the hard way: a single raw CloudQuery schema dump can easily exceed 50,000 tokens. Some of our more complex tables contain hundreds of columns and foreign keys.”article, stated
Schema filtering reduced token usage by about 90%.
“We observed on average about a 90% reduction in token usage after filtering, which allowed Claude to handle over 20 table schemas at once rather than choking after 3 to 4.”article, stated
Filtering let Claude handle over 20 table schemas instead of choking after 3 to 4.
“We observed on average about a 90% reduction in token usage after filtering, which allowed Claude to handle over 20 table schemas at once rather than choking after 3 to 4.”article, stated

Alternatives considered (roads not taken)

Concise engineer-style tool descriptions.

Rejected because: Claude ignored or misinterpreted terse descriptions and hallucinated alternatives.

Let the LLM infer tool order from individual descriptions.

Rejected because: Claude skipped steps, called tools out of order, or assumed data structure.

“A user asking "show me all AWS security groups with open ports" requires multiple coordinated tool calls, but Claude would often skip steps, call tools in the wrong order, or make assumptions about data structure.”article, stated

Send raw schemas to the model.

Rejected because: Large schemas consumed context and caused selective forgetting.

“Some of our more complex tables contain hundreds of columns and foreign keys. Feeding even a few of these tables into Claude consumed nearly its entire context window, leaving no room for query planning or instructions.”article, stated

Patterns

`tool-use-orchestration` (MCP)

The MCP server exposes Go functions with names, descriptions, parameters, and handlers for LLM calls.

“these are Go functions registered with the MCP server and exposed to Claude or Cursor through an OpenAI-style tool schema”article, stated

`prompt-versioning` (tool descriptions)

Tool descriptions are treated as prompt-like artifacts whose wording determines behavior.

“LLMs, especially Claude and GPT, rely heavily on the description field of a tool when ranking which tool to call.”article, stated

`context-compaction` (schema management)

Schema filtering trims irrelevant columns so tool output fits in context.

“We built a filtering mechanism into the MCP server that strategically trims schema output before handing it to the LLM.”article, stated

`query-rewriting` (tool workflow)

Recommended workflows rewrite broad user questions into a sequence of plugin, table, schema, column, and query steps.

“The breakthrough came when we embedded recommended workflows directly into each tool description.”article, stated

Tradeoffs

Tool documentation length

Chose Verbose semantic descriptions over Short context-saving descriptions.

Rationale: Longer descriptions improved tool selection even though they used more context.

“why waste words? But in practice, Claude would call this tool sparingly”article, stated

Schema exposure

Chose Filtered schema output over Full raw schema dumps.

Rationale: Filtering preserved enough context for query planning and more tables.

“By explicitly curating what went into the LLM, we freed up space in the context window for queries, instructions, and additional tables”article, stated

Workflow guidance

Chose Embedded multi-tool workflows over Assuming the model will infer tool order.

Rationale: Explicit steps stopped random calls and hallucinated table structures.

“Instead of Claude making random tool calls or hallucinating table structures, it now systematically follows this discovery-to-execution pipeline.”article, stated

Gotchas (what bit them)

Concise tool descriptions are often invisible to LLMs.

Root cause: LLMs rank tool choice semantically from names and descriptions, not from engineer intuition.

Resolution: Write long, domain-specific tool descriptions that explain when and why to call each tool.

“Sparse descriptions lead to ambiguous or no calls at all”article, stated

MCP tool chains need explicit sequencing.

Root cause: The LLM skipped discovery steps or hallucinated schema knowledge when asked broad questions.

Resolution: Embed the recommended workflow directly in the tool description.

“This explicit sequencing transformed everything.”article, stated

Raw schemas can saturate context windows.

Root cause: Cloud tables can have hundreds of columns and foreign keys.

Resolution: Filter and rank columns before handing schemas to the LLM.

“Some of our more complex tables contain hundreds of columns and foreign keys.”article, stated

Temperature zero does not guarantee deterministic tool behavior.

Root cause: Claude still chose different tools or SQL for the same input.

Resolution: Design for nondeterminism with stronger workflows and validation.

“Even when we set temperature=0, which is supposed to make the model always pick the most likely next word at every step”article, stated

Evaluation

CloudQuery evaluated behavior by observing tool invocation, hallucinated queries, workflow ordering, schema token reduction, number of schemas handled, and repeated nondeterministic outputs.

Metrics: Tool invocation rate · Description length · Token reduction · Number of schemas handled · Hallucinated table/query frequency

“The character count increased from ~50 to ~400, and response quality improved dramatically.”article, stated

“We observed on average about a 90% reduction in token usage after filtering”article, stated

Outcomes

Longer tool descriptions improved Claude's discovery behavior.
Workflow instructions turned random tool use into a discovery-to-execution pipeline.
Schema filtering reduced token use by about 90% and let Claude handle over 20 schemas at once.

The source reports ~50 to ~400 character description expansion, raw schema dumps above 50,000 tokens, ~90% token reduction, and support for 20+ schemas rather than 3 to 4.

“allowed Claude to handle over 20 table schemas at once rather than choking after 3 to 4.”article, stated