#1 Product of the week · Launched August 18, 2026
gridctl

gridctl

One YAML file. One endpoint. Every MCP server plus the skills and agents you author alongside them

FreeMCP8,098 impressions#1 of its week6 comments

Comments

>log in to comment
  • William Collins[maker]· 1mo ago

    @Clemens - I added you on LinkedIn to discuss in DMs!

  • Clemens Losbichler· 1mo ago

    Hi William, I'm the maker of Context Goblin, the second placed tool on this weeks Devhunt. I was wondering how many conversions/visitors you got on your end through this promotion here? Best, Clemens

  • William Collins[maker]· 1mo ago

    @Zain Sheikh Great question, and yes! gridctl apply stack.yaml --watch diffs the YAML on save and applies adds/removes/edits without a restart. Policy blocks (skills exposure, limits, groups, clients) swap in memory; adding or removing an MCP server starts or stops that server. The grid changes still need a full apply. Skill files are a separate watcher: drop a SKILL.md in the registry and it shows up as a prompt even without --watch. You can also gridctl reload by hand.

  • Zain Sheikh· 2mo ago

    Serving MCP servers and your own Agent Skills from one local endpoint defined in a single YAML is a real config-sprawl fix, does it hot reload when the YAML changes?

  • William Collins[maker]· 2mo ago

    Agreed @Zain -> This was the whole reason behind the tool. Fun fact, I built this as a generic CLI tool on my own machine after MCP launched and didn't originally plan to open source it. Any good software out there usually comes from pain + friction.

  • Zain Sheikh· 2mo ago

    Keeping one declarative spec and writing the client configs out is the right shape for this, hand-editing the same server into three JSON files gets old fast.

gridctl is an open-source MCP gateway and skill library. It aggregates every MCP server you use behind a single local endpoint, and serves your Agent Skills to clients as MCP prompts - defined in one YAML file, applied with one command. Instead of maintaining a separate JSON config for Claude Desktop, another for Cursor, another for VS Code, and hand-editing all of them every time you add a server, gridctl holds one declarative spec and writes the client configs for you. HOW IT WORKS 1. Install the single Go binary (curl one-liner, Homebrew, or go install) 2. Declare your servers and skills in gridctl.yaml 3. Run "gridctl apply", then "gridctl link --all" - clients wired up, no manual JSON editing WHAT YOU GET - Stack as code: validate, plan, apply, export. Background drift detection flags when reality diverges from your spec. - 15 clients auto-linked: Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Gemini, Zed, and more. "gridctl import" runs it in reverse to adopt an existing setup. - Token control: per-server tool whitelists, cross-server groups, per-client scoping, and TOON/CSV output conversion that cuts 25-61% off tabular payloads. - Skill library and packs: author SKILL.md in the web UI, project skills and subagents onto disk for file-reading clients, or ship a whole team setup as one versioned git pack. - Visual stack canvas: every client, the gateway, and every server with live health, transport, and tool counts. SUPPLY CHAIN SECURITY gridctl treats every MCP server as untrusted input, because that is what it is. - Tool definition pinning: every tool description and schema is fingerprinted on first sight. A server that quietly rewrites a tool description surfaces as a reviewable diff instead of silently reaching your agent. - Skill document scanning: skills get the same treatment, plus injection heuristics for hidden instructions, zero-width characters, and Unicode homoglyphs. - Scoped exposure: clients only see the tools you grant them. A whitelist is a boundary, not a suggestion. TOKEN GUARDRAILS "gridctl optimize" reports projected weekly token impact per server and returns paste-ready remediation. Most stacks are paying for hundreds of tool definitions that no client ever calls. Single Go binary. Apache 2.0. No runtime dependency beyond a container engine, and only if your stack actually deploys containers.

gridctl is an open-source MCP gateway that consolidates multiple MCP servers into a single endpoint defined by one YAML file.

for
Developers building AI agents that need to manage many MCP servers and client configs.
pricing
open source
license
Apache-2.0
gridctl/gridctl 44 9Goupdated 10 days ago
works withClaude DesktopClaude CodeCursorVS CodeWindsurfGeminiZed

Key features

8 features of gridctl
  • Single binary install — Install via curl, Homebrew or go install a single Go binary.
  • Declarative YAML spec — Define all servers and skills in one gridctl.yaml file.
  • Auto client linking — One command links 15+ clients (Claude, Cursor, VS Code, etc.) without manual JSON edits.
  • Import/export — Import existing setups or export the stack as code with drift detection.
  • Token control — Per-server whitelists, cross-server groups, per-client scoping and payload compression.
  • Skill library & packs — Author skills in a web UI, version them as git packs, and ship whole team setups.
  • Visual stack canvas — Live view of clients, gateway, servers with health and tool counts.
  • Supply-chain security — Fingerprint tool schemas, detect hidden instructions and enforce scoped exposure.

Use cases

  • Synchronize configuration for Claude Desktop, Cursor and VS Code from a single source
  • Version and share a complete agent skill set across teams via git packs
  • Detect drift between declared MCP servers and actual runtime state
  • Limit tool access per client to enforce security policies
  • Compress large tabular payloads for faster agent communication

gridctl vs alternatives

gridctlUnified MCP ServerPipelexMetorialMCP Bridge by Appfactor
Best forUnified MCP server configurationAll-in-one MCP serverDeclarative AI workflow scriptingProduction MCP infrastructureAPI-to-agent bridging
PricingOpen sourceSubscriptionFreeFreeFree
DevHunt upvotes20294078
LaunchedAug 2026Jan 2026Oct 2025Oct 2025May 2026
  • gridctl vs Unified MCP Server: Provides a single MCP server with thousands of tools, whereas gridctl aggregates multiple existing servers.
  • gridctl vs Pipelex: Offers a declarative language for AI workflows, but not focused on MCP gateway aggregation.
  • gridctl vs Metorial: Acts as an integration layer for AI agents with many tools, while gridctl focuses on config management across servers.
  • gridctl vs MCP Bridge by Appfactor: Connects any API to an AI agent, whereas gridctl manages MCP server configurations and client linking.

gridctl FAQ

How do I install gridctl?+

Use the provided curl one-liner, Homebrew formula, or run go install to get the single Go binary.

What format do I use to declare servers and skills?+

All configuration is written in a gridctl.yaml file using a declarative YAML schema.

How does gridctl apply changes?+

Run gridctl apply to reconcile the spec, then gridctl link --all to auto-wire supported clients.

Can I import an existing setup?+

Yes, gridctl import reads current client configs and generates the corresponding YAML spec.

How does gridctl ensure security of MCP servers?+

It fingerprints tool definitions, scans skill documents for hidden instructions, and scopes exposure via whitelists.

What visual tools does gridctl provide?+

A stack canvas shows live health, transport, and tool counts for each client, gateway, and server.

Summarized by DevHunt from github.com · Sep 27, 2026. Details may change; check the official site.