back_office_ops · saas · workflow

CloudQuery builds MCP server connecting Claude and Cursor to cloud infrastructure database: lessons learned on tool descriptions, context windows, and LLM behavior

When CloudQuery wired Claude and Cursor into their cloud infrastructure database via an MCP server, sparse tool descriptions caused the LLM to hallucinate table schemas, ignore tools entirely, or misinterpret their purpose; a single schema dump could also consume nearly the entire context window.

How it works
Common implementation structure
How this type of workflow is generally built, generalized across documented cases — not tied to any one vendor's stack. Click any stage to read what happens there. Specific products that implement these stages appear in “Tools commonly seen” below.
Stage 1 · User queries via Claude or Cursor
Claude or Cursor receives direct access to the cloud infrastructure database through the MCP server.
Tools used
ClaudeCursorClickHouse
Outcome

After rewriting tool descriptions with domain-specific detail, embedding explicit workflow sequences, renaming tools, and filtering schema output, token usage dropped by about 90%, and Claude could handle over 20 table schemas simultaneously instead of choking after 3 to 4.

What failed first

Initial terse tool descriptions caused Claude to call tools sparingly or skip them; a tool named 'example_queries' was never invoked during two weeks of testing despite explicit prompting.

Results
Volume90%
Source

https://www.cloudquery.io/blog/mcp-server-gotchas-we-learned-the-hard-way

How we source this →

Grounding & classification
Source type: technical build writeup
23 fields verified against source quotes, 1 dropped as unverifiable.
agentic workflowai agentknowledge basebuilder submittedfailure mode describedmetric backednamed customersource backedtools describedworkflow describedsoftwareaccuracy improvementthroughput increasetechnical build writeupback office opsagentic task execution