Skip to main content

StackQL vs Custom MCP Servers

A custom MCP server wraps a specific API or workflow in hand-written tools for AI agents; StackQL's built-in MCP server exposes the entire surface of every supported cloud and SaaS provider through a small set of generic, self-describing tools plus SQL. The comparison is between curating tools per domain and giving the agent one queryable abstraction over all domains.

When to use which​

Build a custom MCP server when:

  • The domain is narrow and the operations are few - a dozen well-named tools with tight schemas can outperform a general interface on reliability for that specific workflow.
  • You need heavy business logic between the agent and the API: approvals, enrichment, multi-step transactions that should appear to the agent as one atomic tool.
  • The target API is internal or proprietary and not described by a public specification.

Use StackQL's MCP server when:

  • The domain is cloud and SaaS infrastructure - AWS, Azure, Google Cloud, GitHub, Databricks, Snowflake, Okta, and the rest of the provider registry - where the operation count makes per-operation tools impractical.
  • You want the agent to discover capability at runtime (list_providers -> list_services -> list_resources -> list_methods -> describe_method) instead of being limited to tools someone anticipated.
  • You need governed writes: the four-mode safety contract (read_only, safe, delete_safe, full_access) with elicitation-based human approval and an always-on audit log, rather than safety logic you write and maintain yourself.
  • You want one credential and policy surface for the whole estate instead of one bespoke server per provider.

The approaches compose: teams commonly run StackQL MCP for general infrastructure access alongside small custom MCP servers for proprietary internal systems.

The token economics​

The practical constraint on agent tooling is context. Tool definitions consume the agent's context window before any work happens, and tool-selection accuracy degrades as the tool count grows. Publishing AWS alone as per-operation tools would mean thousands of definitions. StackQL's design keeps the published tool set under fifteen (discovery, description, validation, execution, registry management) and moves the expressive power into SQL - a language every current model already writes fluently. The agent's per-task token cost is a short SQL string, not a tool schema negotiation. This argument is developed in Why SQL is a Strong Interface for Cloud APIs.

Example​

An agent session against StackQL's MCP server, after discovering required parameters with list_methods:

SELECT name, visibility, default_branch
FROM github.repos.repos
WHERE org = 'stackql';

The same tool (run_select_query) serves this query and any other read against any provider; mutation requests route through run_mutation_query, where the server mode decides whether they proceed, require approval, or are refused.