How do I use Synlake MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Synlake MCP Server find cheapest 4 vCPU 16GB RAM instance in us-east-1 under $120/month" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Synlake MCP Server

Official

by Synlake-ai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Synlake MCP Server

npm MCP Registry License: MIT

The MCP connector for Synlake — B2AI infrastructure for autonomous agents. Synlake normalizes AWS, GCP, and Azure into one schema, generates ready-to-run execution kits (Terraform HCL + CLI), and prices them before deploy — so an AI agent can discover, evaluate, and provision cloud infrastructure with zero human intervention.

This repository is the open-source MCP server (a thin stdio ↔ HTTP proxy). The infrastructure intelligence — cross-cloud normalization, the cost engine, and execution-kit generation — runs as a hosted service at api.synlake.ai.

🌐 synlake.ai · 📖 Docs · 🔌 MCP: ai.synlake/synlake

An agent deploys infrastructure — no human in the loop

A coding agent needs a Kubernetes node pool. It doesn't open a cloud console, compare pricing pages, or hand-write Terraform. It asks Synlake, and gets back a deployable answer:

Agent → Synlake:  "compute, 4 vCPUs, 16 GB RAM, us-east-1, budget $100/mo"

Synlake → Agent:  best:  gcp · e2-standard-4 · $97.82/mo   (19.5% cheaper than the priciest)
                  also:  aws t3.xlarge $121.47 · azure Standard_B4ms $121.18
                  kit:   { terraform: "resource \"google_compute_instance\"…",
                           cli: "gcloud compute instances create…" }
                  ✓ validated: no public ingress, encryption on, within budget

The agent reviews the kit, applies the Terraform, and moves on. Every response is dense, deterministic JSON — built for machine consumption, not dashboards. Synlake tools are read-only: they recommend, price, and validate. A human (or the agent's own policy) runs the execution kit.

Related MCP server: Cloud Pilot MCP

Architecture

flowchart LR
    A[AI Agent] -- MCP / REST --> B[Synlake API]
    B --> C[Normalizer]
    C --> D1[AWS adapter]
    C --> D2[Azure adapter]
    C --> D3[GCP adapter]
    C --> E[Ranking engine<br/>cost + constraints]
    E --> F[Execution-kit generator<br/>Terraform + CLI]
    F --> G[Guardrails & validation<br/>budget · region · security]
    G --> H[Audit log]
    H --> A

An agent sends an intent. Synlake normalizes options across clouds, ranks them by cost and constraints, generates a deploy-ready execution kit, runs guardrail checks, logs the call, and returns one machine-ready payload. This repo ships the open-source MCP connector (the AI Agent ↔ Synlake API edge); the boxes to the right of Synlake API run as the hosted service.

Quickstart

Hosted (recommended) — MCP over Streamable HTTP

Point any MCP client at the hosted server — three lines, nothing to install:

{
  "mcpServers": {
    "synlake": {
      "url": "https://api.synlake.ai/api/mcp",
      "headers": { "Authorization": "Bearer sk_synlake_YOUR_KEY" }
    }
  }
}

Local stdio wrapper (this package)

For clients that speak stdio (e.g. Claude Desktop), run the npm wrapper — it proxies to the same hosted server:

{
  "mcpServers": {
    "synlake": {
      "command": "npx",
      "args": ["-y", "@synlake-ai/mcp-server"],
      "env": { "SYNLAKE_API_KEY": "sk_synlake_YOUR_KEY" }
    }
  }
}

Get a free API key at synlake.ai (100 calls/month, no card required). The estimate endpoint is even callable without a key — zero friction to try.

Tools

Tool	REST endpoint	Description
`synlake_query`	`POST /v1/infrastructure/query`	Full recommendation + execution kit (Terraform + CLI)
`synlake_estimate`	`POST /v1/infrastructure/estimate`	Cross-cloud cost comparison — no API key required
`synlake_validate`	`POST /v1/execution/validate`	Dry-run an execution kit (security + budget checks)
`synlake_providers`	`GET /v1/providers`	List supported providers and services
`synlake_usage`	`GET /v1/agent/usage`	Your usage, costs, and spending cap

Full reference (OpenAPI 3.1, rendered): synlake.ai/docs. Local copy: docs/openapi.yaml. Machine-readable summary for agents: synlake.ai/llms.txt.

Why Synlake

Approach	Multi-cloud	Agent-ready JSON	Execution kit	Cost guardrails	Audit trail
DIY Terraform	Manual	No	You write it	No	No
Pulumi / Crossplane	Yes	No	Partial	No	Partial
Cloud provider SDKs	Single	Partial	No	No	Partial
Agent frameworks	Via tools	Partial	No	No	No
Synlake	3 clouds	100%	Full kit	Built-in	Every call

Use it from a Claude Managed Agent

Wire Synlake as an mcp_toolset — the agent gets all five tools natively, your key stays in an Anthropic vault:

{
  "type": "mcp_toolset",
  "name": "synlake",
  "server": {
    "url": "https://api.synlake.ai/api/mcp",
    "authorization_token": { "vault_secret": "synlake_api_key" }
  }
}

See the MCP quickstart for the Managed Agents API, ant CLI, and Agent SDK flows.

Build from source

npm install
npm run build       # tsc → dist/ (pure proxy)
SYNLAKE_API_KEY=sk_synlake_... node dist/bin.js

SYNLAKE_API_URL overrides the remote endpoint (default https://api.synlake.ai/api/mcp).

Pricing

Pay per call. No subscriptions, no commitments. Free tier: 100 calls/month, no card required.

Call type	Price
Estimate	$0.01 (free, no key, IP rate-limited)
Query (basic)	$0.05
Query (full + Terraform)	$0.10
Validate	$0.05

License

The MCP connector in this repository is MIT licensed (see LICENSE). The Synlake service (api.synlake.ai) — the cost engine, cross-cloud normalization, and execution-kit generation — is proprietary.

El conector MCP de este repo es MIT. El servicio Synlake (api.synlake.ai) es propietario.

Available Tools

5 tools

synlake_estimateEstimate Infrastructure CostsB

Read-only

Inspect

Get quick cost estimates across AWS, GCP, and Azure for your infrastructure needs. Returns the cheapest option and savings percentage.

ParametersJSON Schema

Name	Required	Description	Default
`intent`	Yes
`requirements`	Yes
`providers`	No

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already indicate read-only and non-destructive behavior. The description adds that the tool returns quick estimates and the cheapest option, which is consistent but does not elaborate on additional behavioral traits like rate limits or data freshness.

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?

The description is two short sentences, front-loaded with the core purpose, and contains no unnecessary words. It earns its place efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With three parameters, a nested object, and no output schema, the description is too brief. It does not explain parameter usage, optionality of 'providers', or the return format beyond 'cheapest option and savings percentage', leaving significant gaps for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any parameters. There is no mention of 'intent', 'requirements', or 'providers', leaving the agent with no semantic guidance beyond the schema structure.

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?

The title and description clearly state the tool's purpose: estimating infrastructure costs across AWS, GCP, and Azure. It is specific about returning the cheapest option and savings percentage, and distinguishes well from sibling tools like synlake_providers or synlake_usage.

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

Usage Guidelines3/5

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

The description implies usage for cost estimation but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or preconditions. The context is clear but lacks direct guidance.

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

synlake_providersList Cloud ProvidersA

Read-only

Inspect

Get the list of supported cloud providers (AWS, GCP, Azure) with available services, regions, and last pricing update.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context about return content (services, regions, last pricing update), which is valuable beyond annotations.

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?

Single sentence, 14 words, front-loaded verb 'Get'. No extraneous information.

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?

Given zero parameters, no output schema, and annotations covering safety, the description fully describes what the tool returns and its purpose. Complete for a listing tool.

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?

No parameters, so baseline is 4. Schema coverage is 100%. Description does not need to add param info; it is sufficient.

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?

Description clearly states 'Get the list of supported cloud providers' with specific providers (AWS, GCP, Azure) and details (services, regions, last pricing update). It distinguishes from siblings which are different operations (estimate, query, usage, validate).

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

Usage Guidelines3/5

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

No explicit guidance on when to use vs alternatives, but purpose is clear and tool is simple. Implicit usage context: use when you need provider list and details.

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

synlake_queryQuery Cloud InfrastructureA

Read-only

Inspect

Describe what infrastructure you need (compute, storage, database, networking) and get the best option across AWS, GCP, and Azure with Terraform code and CLI commands ready to execute.

ParametersJSON Schema

Name	Required	Description	Default
`intent`	Yes
`requirements`	Yes
`constraints`	No
`output`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations indicate read-only and non-destructive behavior. The description adds value by specifying that the tool returns 'Terraform code and CLI commands ready to execute,' which clarifies the output. It does not contradict annotations and provides sufficient behavioral context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that efficiently conveys the core action. It contains no extraneous information, though it is slightly dense. Could be improved by breaking into two sentences, but currently concise and informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (nested parameters, no output schema, 0% schema coverage), the description is incomplete. It does not explain how to structure requirements/constraints, what the return format looks like (e.g., multiple options, pricing details), or any pagination/limits. Additional detail is needed for the agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage and includes nested objects (requirements, constraints, output). The description only mentions 'compute, storage, database, networking' (mapping to intent) and vaguely 'Terraform code' (output). It fails to explain the meaning of requirements fields like vcpus, memory_gb, or constraints like max_monthly_budget, which are critical for correct usage.

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?

The description clearly states the tool's purpose: it queries cloud infrastructure needs and returns the best option across providers with Terraform code and CLI commands. It distinguishes from sibling tools like synlake_estimate (cost estimation) and synlake_providers (list providers) by focusing on querying specific infrastructure requirements.

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

Usage Guidelines3/5

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

The description implies usage for obtaining infrastructure options but does not explicitly state when to use this tool over siblings. It lacks guidance on prerequisites, limitations, or alternative scenarios where other tools would be more appropriate.

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

synlake_usageCheck API UsageA

Read-only

Inspect

Check your current API usage, rate limits, total infrastructure deployed, and remaining budget.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already indicate read-only and non-destructive behavior. The description adds specific context about what is checked (rate limits, budget), providing value beyond the annotations.

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?

Single sentence, front-loaded with the purpose, no wasted words. Efficient and clear.

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?

With no parameters, no output schema, and clear annotations, the description fully covers the tool's purpose and what information it retrieves.

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?

No parameters exist, so baseline is 4. The description correctly implies no input is needed, as it simply checks current usage.

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?

The description clearly states the tool checks API usage, rate limits, infrastructure, and budget. It uses a specific verb 'check' and distinguishes from sibling tools like synlake_estimate or synlake_query.

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

Usage Guidelines3/5

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

The description implies usage for checking current status but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.

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

synlake_validateValidate Execution KitA

Read-only

Inspect

Validate a Terraform or CLI execution kit before deploying. Checks budget limits, security configuration, and returns warnings.

ParametersJSON Schema

Name	Required	Description	Default
`provider`	Yes
`execution_type`	Yes
`code`	Yes
`agent_budget_limit`	No

TDQS

A4/5.0

Behavior4/5

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

Annotations already mark as read-only and non-destructive. Description adds specific behavioral details (budget, security checks, warnings), aligning with annotations.

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?

Single sentence with front-loaded purpose. Every word adds value; no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but mentions return type ('warnings'). Lacks details on error handling, full validation scope, or exact output format. Adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. Description only hints at 'budget limits' (maps to agent_budget_limit) and 'Terraform or CLI' (maps to execution_type), but does not explain the code parameter or provide full parameter meaning.

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?

Clearly states the verb 'Validate', the resource 'execution kit', and specific actions ('checks budget limits, security configuration, and returns warnings'). Differentiates from sibling tools like synlake_estimate which focuses on estimation.

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

Usage Guidelines4/5

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

Provides clear context 'before deploying' indicating appropriate timing. However, lacks explicit when-not-to-use or alternatives among siblings.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: cost estimation, provider listing, infrastructure query with code generation, usage checking, and pre-deployment validation. No overlap or ambiguity.

Naming Consistency4/5

All tools share the 'synlake_' prefix, but the second part mixes verbs (estimate, query, validate) and nouns (providers, usage). While readable and clear, a fully consistent verb pattern would be better.

Tool Count5/5

With 5 tools covering estimation, provider info, query, usage, and validation, the scope is well-scoped and each tool earns its place. Neither too few nor too many for the domain.

Completeness4/5

The set covers core workflows: cost estimation, provider discovery, full infrastructure query with code generation, usage monitoring, and pre-deployment validation. Missing a direct deployment execution tool is a minor gap, as the query tool provides ready-to-execute code but no deploy command.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Synlake
ai.synlake
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Cloud Platforms Developer Tools Agent Orchestration
2
Eyevinn Open Source Cloud
io.osaas.mcp
Your AI Agent's Infrastructure Layer. Connect Claude, Copilot, Codex, or ChatGPT to 200+ managed open source services. Start databases, pipelines, and applications through natural language.
Cloud Platforms Agent Orchestration Developer Tools
2
IntegrityPulse FinOps
io.github.maryadawson-code
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Cloud Platforms Finance AI & Machine Learning
2
OpenClaw FinOps
io.github.maryadawson-code
Verified cloud cost forecasting for AI agents. AWS, GCP, Azure pricing matrix.
Finance Cloud Platforms AI & Machine Learning
2

Related MCP Servers

MCP Cloud Services Server
Cloud Platforms Monitoring Security
code-alchemist01
A
license
C
quality
D
maintenance
Enables AI assistants to manage multi-cloud resources (AWS, Azure, GCP) including resource operations, cost analysis, monitoring metrics, and security compliance checks through natural language commands.
Updated 10 months ago (2025-11-15 11:44 UTC)
26
16
2
MIT
Cloud Pilot MCP
Cloud Platforms Agent Orchestration
vitalemazo
A
license
Not graded
quality
C
maintenance
Provides AI agents with natural language control over AWS, Azure, GCP, and Alibaba Cloud infrastructure through dynamic API discovery and execution. Supports 51,900+ cloud operations and includes OpenTofu integration for complete infrastructure lifecycle management.
Updated 5 months ago (2026-04-06 09:57 UTC)
3
MIT
CloudCost MCP Server
Cloud Platforms Finance
JadenRazo
A
license
Not graded
quality
A
maintenance
Enables AI agents to parse multi-cloud infrastructure-as-code files, query real-time pricing from AWS, Azure, and GCP, and generate cost estimates and comparison reports.
Updated 10 days ago (2026-08-24 12:20 UTC)
36
MIT
@eustore/mcp-server
Cloud Storage Vector Databases Autonomous Agents
AIBOLLINGMO
A
license
Not graded
quality
D
maintenance
Enables AI agents to autonomously provision, pay for, and manage S3-compatible storage and vector databases without human intervention.
Updated 5 months ago (2026-03-29 17:37 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Synlake-ai/synlake'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Synlake MCP Server

An agent deploys infrastructure — no human in the loop

Architecture

Quickstart

Hosted (recommended) — MCP over Streamable HTTP

Local stdio wrapper (this package)

Tools

Why Synlake

Use it from a Claude Managed Agent

Build from source

Pricing

Links

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API