Skip to main content
Glama
GoCoder7

Coolify MCP Server

by GoCoder7
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Coolify MCP Server

A 4-tool unified Model Context Protocol (MCP) server for Coolify deployment platform integration. This server enables AI assistants to interact with Coolify Self-hosted instances for application deployment, management, and monitoring.

🎯 Optimized for VS Code's 128-tool limit with 87% reduction (19→4 tools)

Features

🚀 Application Management

  • Deploy applications with optional force deployment and branch selection

  • Get detailed application information and status

  • List applications with filtering capabilities

  • Start, stop, and restart applications

  • Monitor deployment status and health

  • Create new applications

🔧 Environment & Configuration

  • Update and retrieve environment variables

  • Configure domains and SSL certificates

  • Retrieve application logs for debugging

  • Manage sensitive and build-time variables

🖥️ System Management

  • List and monitor servers

  • Manage teams and permissions

  • View deployed services (databases, caches, etc.)

  • Test API connectivity and system health

📚 Built-in Documentation

  • Search Documentation: Find relevant Coolify guides and references

  • API Reference: Access comprehensive API documentation with examples

  • Troubleshooting Guides: Get help for common deployment and configuration issues

  • Topic-specific Help: Get targeted documentation for specific features

Perfect for AI agents without Context7 MCP access - no external documentation dependencies required!

🧪 Complete Testing Suite

  • 100% Test Success Rate: Comprehensive integration tests

  • Demo Environment: Full Coolify setup with Docker Compose

  • Browser Automation: MCP Playwright integration

  • Real API Testing: Direct Coolify instance validation

Related MCP server: Coolify MCP Tools

Prerequisites

  • Node.js 18+

  • A running Coolify Self-hosted instance

  • Coolify API token with appropriate permissions

Installation

  1. Clone or download this repository

    git clone <repository-url>
cd coolify-mcp-server

  2. Install dependencies

    npm install

  3. Configure environment variables

    cp .env.example .env
# Edit .env with your Coolify instance details

  4. Build the project

    npm run build

Configuration

Environment Variables

Create a .env file with the following variables:

# Required: Your Coolify instance URL
COOLIFY_BASE_URL=https://your-coolify-instance.com

# Required: API token from Coolify
COOLIFY_API_TOKEN=your-api-token-here

# Optional: Team ID for scoped access
COOLIFY_TEAM_ID=your-team-id

Getting Your API Token

  1. Log into your Coolify dashboard

  2. Go to Settings → Keys & Tokens → API Tokens

  3. Click Create New Token

  4. Choose permissions:

    • read-only: View data only

    • read:sensitive: View sensitive data

    • *: Full access (recommended for automation)

  5. Copy the generated token to your .env file

⚠️ Security Note: API tokens are shown only once. Store them securely and never commit them to version control.

Usage

Development Mode

npm run dev

Production Mode

npm start

Integration with AI Assistants

This MCP server provides 4 unified tools for AI assistants, optimized for the 128-tool limit in VS Code:

📱 Application Management (coolify_application_management)

Unified tool with 8 actions:

  • deploy - Deploy an application with optional force deployment and branch selection

  • get - Get detailed application information

  • list - List all applications with filtering capabilities

  • status - Get deployment status and health

  • start - Start an application

  • stop - Stop an application

  • restart - Restart an application

  • create - Create a new application

⚙️ Environment Configuration (coolify_environment_configuration)

Unified tool for environment and domain management:

  • env_vars - Update and retrieve environment variables

  • domains - Configure domains and SSL certificates

  • logs - Retrieve application logs for debugging

🖥️ System Management (coolify_system_management)

Unified tool for server and infrastructure:

  • servers - List and monitor servers

  • teams - Manage teams and permissions

  • services - View deployed services (databases, caches, etc.)

  • health_check - Test API connectivity and system health

📚 Documentation (coolify_documentation)

Unified documentation tool with 6 actions:

  • search - Search built-in Coolify documentation

  • get - Get documentation for specific topics

  • api_reference - Get API reference documentation with examples

  • troubleshooting - Get troubleshooting guides for common issues

  • topics - List available documentation topics

  • api - Get API endpoint documentation

Perfect for AI agents without Context7 MCP access - no external documentation dependencies required!

Example Usage

Here are some example commands you can use with AI assistants using the unified tools:

Application Management:

"Deploy my application with ID 'app-123' using force deployment"
"Get details for application 'my-web-app'"
"List all running applications"
"Check the status of application 'app-456'"
"Start application 'my-backend'"
"Restart application 'frontend-app'"

Environment Configuration:

"Update environment variables for 'app-789': set DATABASE_URL and REDIS_URL"
"Get current environment variables for 'my-app'"
"Set the domain 'example.com' for application 'app-456' with HTTPS enabled"
"Get the logs for application 'my-web-app'"

System Management:

"List all servers and their status"
"Get information about teams"
"Show all running services"
"Check system health and API connectivity"

Documentation:

"Search documentation for 'deployment failed'"
"Get troubleshooting help for SSL certificate issues"
"Show me API reference for environment variables"
"List all available documentation topics"
"Get API documentation for applications endpoint"

Documentation Features

The MCP server includes comprehensive built-in documentation accessed through the unified coolify_documentation tool:

// Search for deployment-related documentation
await callTool('coolify_documentation', { action: 'search', query: 'deployment failed' });

// Get API reference for applications endpoint
await callTool('coolify_documentation', { action: 'api_reference', endpoint: 'applications' });

// Get troubleshooting help for SSL issues
await callTool('coolify_documentation', { action: 'troubleshooting', issue: 'ssl certificate' });

// List all available topics
await callTool('coolify_documentation', { action: 'topics' });

// Get general documentation on environment variables
await callTool('coolify_documentation', { action: 'get', topic: 'environment variables' });

Built-in Documentation Covers:

  • API Reference with examples

  • Step-by-step deployment guides

  • Environment variable configuration

  • Domain and SSL setup

  • Common troubleshooting scenarios

API Reference

This MCP server interacts with the Coolify API. For detailed API documentation, visit:

Architecture

coolify-mcp-server/
├── src/
│   ├── index.ts              # Main MCP server (unified version)
│   ├── types/
│   │   ├── coolify.ts        # Coolify API types
│   │   └── mcp.ts           # MCP tool schemas
│   ├── utils/
│   │   └── coolify-client.ts # Coolify API client
│   └── tools/
│       ├── application-unified.ts    # Unified application management
│       ├── environment-unified.ts    # Unified environment & domain tools
│       ├── system-unified.ts        # Unified system management
│       └── documentation-unified.ts  # Unified documentation tools
├── demo-server/
│   ├── docker-compose.yml    # Complete Coolify demo environment
│   └── DEMO-SETUP.md        # Demo setup instructions
├── .env.example             # Environment configuration template
├── test-*.js               # Comprehensive test suites
├── tsconfig.json           # TypeScript configuration
└── package.json           # Project dependencies

Demo Environment

This project includes a complete Coolify demo environment for testing:

cd demo-server
docker compose up -d

Includes:

  • ✅ Coolify latest version

  • ✅ PostgreSQL database

  • ✅ Redis cache

  • ✅ Soketi WebSocket server

  • ✅ Pre-configured demo users

  • ✅ Web interface at http://localhost:8000

Demo Credentials:

  • Email: test@example.com

  • Password: password123

Development

Building

npm run build

Type Checking

npm run type-check

Testing Documentation Features

node test-docs.js

This will test all built-in documentation features without requiring a Coolify connection.

Testing with Demo Environment

# Start the demo environment
cd demo-server && docker compose up -d

# Run comprehensive tests
npm test

Test Suites:

  • test-integration.js - Docker environment and build tests

  • test-mcp-simple.js - MCP server functionality tests

  • test-web-interface.js - Playwright browser automation tests

  • test-real-coolify.js - Real Coolify integration tests

Expected Results: 100% test success rate

Cleaning

npm run clean

Supported Coolify Versions

This MCP server is designed to work with:

  • Coolify v4.x (Self-hosted)

  • API version: v1

Security Considerations

  • API Tokens: Store API tokens securely using environment variables

  • Network Access: Ensure your Coolify instance is accessible from where this MCP server runs

  • Permissions: Use appropriate API token permissions based on your use case

  • HTTPS: Always use HTTPS for production Coolify instances

Troubleshooting

Common Issues

  1. Connection Failed

    • Verify COOLIFY_BASE_URL is correct and accessible

    • Check that API token has proper permissions

    • Ensure Coolify instance is running

  2. Permission Denied

    • Verify API token has sufficient permissions

    • Check if team ID is required for your setup

  3. Application Not Found

    • Verify application ID is correct

    • Ensure you have access to the application

Debug Mode

Enable debug logging by setting:

NODE_ENV=development npm run dev

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

License

MIT License - see LICENSE file for details

Support

Changelog

v1.0.0

  • ✅ 4 Unified Tools: Optimized for VS Code's 128-tool limit

  • ✅ Complete Demo Environment: Docker Compose setup with working Coolify instance

  • ✅ 100% Test Coverage: Comprehensive test suites with 100% success rate

  • ✅ Built-in Documentation: No external dependencies required

  • ✅ Browser Automation: MCP Playwright integration for testing

  • ✅ Application Management: Deploy, manage, and monitor applications

  • ✅ Environment Configuration: Manage env vars, domains, and logs

  • ✅ System Management: Server, team, and service management

  • ✅ Full TypeScript Support: Complete type safety with Zod validation

Available Tools

4 tools
coolify_application_managementC

Comprehensive application management: deploy, get info, list, check status, start/stop/restart, or create applications

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform on applications
applicationIdNoApplication ID (required for most actions except list/create)
forceNoForce deployment even if another is in progress
branchNoGit branch to deploy
serverIdNoFilter applications by server ID
statusNoFilter by application status
nameNoApplication name (for create action)
descriptionNoApplication description (for create action)
git_repositoryNoGit repository URL (for create action)
git_branchNoGit branch (for create action)
build_packNoBuild pack to use (for create action)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it lists actions, it doesn't explain what each action actually does, their side effects, authentication requirements, rate limits, or error conditions. For example, it doesn't clarify whether 'deploy' overwrites existing deployments or what 'force' actually forces. This is inadequate for a multi-action mutation tool with 11 parameters.

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 efficiently structured as a single sentence listing all available actions. It's appropriately sized for a multi-function tool, though it could be more front-loaded by grouping related actions (e.g., 'deploy and manage applications: create, list, get info, check status, start/stop/restart'). Every word earns its place.

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?

For a complex tool with 11 parameters, multiple actions (including mutations like deploy, create, stop), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, prerequisites, or the relationships between actions and parameters. The agent would struggle to use this tool correctly without trial and error.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters (e.g., which parameters apply to which actions) or provide usage examples. The baseline of 3 is appropriate when the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs comprehensive application management with specific verbs (deploy, get info, list, check status, start/stop/restart, create). It distinguishes itself from sibling tools by focusing specifically on applications rather than documentation, environment configuration, or system management. However, it doesn't explicitly differentiate between the various actions within the tool itself.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings (coolify_documentation, coolify_environment_configuration, coolify_system_management). It also doesn't indicate when to use specific actions within the tool (e.g., when to use 'deploy' vs 'create', or when 'force' parameter is appropriate). The agent must infer usage from parameter descriptions alone.

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

coolify_documentationB

Access Coolify documentation: search docs, get topic info, API reference, or troubleshooting guides

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: search docs, get topic docs, get API reference, get troubleshooting, list topics, or get API reference
queryYesSearch query, topic name, API endpoint, or issue description
categoryNoOptional category filter (api, guide, configuration, troubleshooting)
limitNoMaximum number of results to return

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions actions like 'search docs' and 'get topic info' but doesn't describe behavioral traits such as rate limits, authentication needs, response formats, or error handling. For a tool with 4 parameters and no annotations, this leaves significant gaps in understanding how it behaves.

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 concise and front-loaded: a single sentence that efficiently states the tool's purpose and key actions. Every word earns its place without redundancy or unnecessary elaboration, making it easy to scan and understand quickly.

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?

Given the complexity (4 parameters, no output schema, no annotations), the description is moderately complete. It covers the high-level purpose and actions but lacks details on behavioral traits, usage context, and output expectations. Without an output schema, it should ideally hint at return values, but it doesn't. It's adequate but has clear gaps for effective tool selection.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing actions (search, get, api, troubleshoot, topics, api_reference) and hinting at query usage, but it doesn't provide additional semantics beyond what's in the schema. With high schema coverage, the baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Access Coolify documentation' with specific actions like search, get topic info, API reference, and troubleshooting guides. It uses specific verbs (search, get) and identifies the resource (Coolify documentation). However, it doesn't explicitly differentiate from sibling tools like coolify_application_management, which likely handle different aspects of Coolify.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings (coolify_application_management, coolify_environment_configuration, coolify_system_management). It lists actions but doesn't specify contexts, prerequisites, or exclusions. Usage is implied through the action list but lacks explicit when/when-not instructions.

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

coolify_environment_configurationC

Manage environment variables, configure domains, and retrieve application logs

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: update env vars, get env vars, set domain, or get logs
applicationIdYesApplication ID (required for all actions)
variablesNoArray of environment variables to set (for update_env)
domainNoDomain name to set (for set_domain action)
enableHttpsNoWhether to enable HTTPS/SSL (for set_domain action)
linesNoNumber of log lines to retrieve (for get_logs action)
sinceNoRetrieve logs since this timestamp (ISO format, for get_logs action)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'manage', 'configure', and 'retrieve' but doesn't clarify permissions needed, whether operations are destructive, rate limits, or what happens during failures. For a multi-action tool with potential mutations (update_env, set_domain), this is inadequate.

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 extremely concise (8 words) and front-loaded with all key functionality. Every word earns its place by listing the three core capabilities without redundancy or fluff. It's appropriately sized for a multi-action tool.

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?

For a complex tool with 7 parameters, multiple actions (including mutations), no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects, output format, error handling, or usage context. The agent lacks critical information to use this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain relationships between actions and parameters). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 with specific verbs ('manage', 'configure', 'retrieve') and resources ('environment variables', 'domains', 'application logs'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'coolify_application_management' or 'coolify_system_management', which might have overlapping functionality.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when to choose this over sibling tools, or any contextual constraints. The agent must infer usage solely from the action parameter enum.

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

coolify_system_managementC

System management: list servers, teams, services, or test connectivity

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesAction to perform: get servers, teams, services, or test connection

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies read-only operations for listing and testing, but doesn't specify if these actions require authentication, have rate limits, or what the output format might be. For a system management tool, this lack of detail is a significant gap.

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 extremely concise and front-loaded, using a single sentence with zero waste. It efficiently communicates the core functionality without unnecessary words, making it easy for an agent to parse quickly.

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 of system management and the lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like authentication needs, error handling, or return values, which are crucial for an agent to use the tool effectively in a real-world context.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting the single 'action' parameter with an enum. The description adds minimal value by listing the actions in a more readable format ('list servers, teams, services, or test connectivity'), but doesn't provide additional context or syntax details beyond what the schema already specifies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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 with specific verbs ('list', 'test') and resources ('servers', 'teams', 'services', 'connectivity'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'coolify_application_management' or 'coolify_environment_configuration', which might have overlapping functions.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It lists possible actions but doesn't specify contexts, prerequisites, or exclusions, leaving the agent to infer usage from the action names alone without reference to sibling tools.

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.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: application management, documentation access, environment configuration, and system management. The descriptions specify unique scopes (e.g., deploy apps vs. manage environment variables vs. system-level operations), making it easy for an agent to select the correct tool without confusion.

Naming Consistency5/5

All tool names follow a consistent 'coolify_*' prefix with descriptive noun phrases (e.g., 'application_management', 'documentation', 'environment_configuration', 'system_management'). This uniform pattern enhances readability and predictability, with no deviations in style or convention across the set.

Tool Count5/5

With 4 tools, the count is well-scoped for a Coolify management server, covering core domains like applications, documentation, environment, and system. Each tool earns its place by addressing a distinct aspect of the platform, avoiding bloat or thin coverage, which is typical for a focused set of 3-15 tools.

Completeness4/5

The tool set provides comprehensive coverage for key Coolify operations, including CRUD-like actions for applications (deploy, manage), environment configuration, system management, and documentation access. A minor gap exists in not explicitly covering update or delete for non-application resources (e.g., servers or teams), but agents can likely work around this with the available tools.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Coolify MCP Server

    HowieDuhzit
    A
    license
    B
    quality
    F
    maintenance
    Enables AI assistants to interact with Coolify for complete infrastructure management including applications, databases, servers, deployments, and team operations. Provides 100% API coverage with 64 tools for managing the entire Coolify ecosystem through natural language.
    18
    25
    6
    MIT

  • Coolify MCP Tools

    jplansink
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to manage Coolify infrastructure including servers, applications, databases, deployments, and 80+ one-click services through 98 comprehensive tools for both cloud and self-hosted instances.
    MIT

  • Coolify MCP Server

    kof70
    A
    license
    B
    quality
    C
    maintenance
    Enables control and management of Coolify self-hosted PaaS instances, allowing you to deploy applications, manage databases, monitor servers, and execute operations directly from AI assistants.
    89
    32
    28
    MIT

  • Coolify MCP Server

    JoshuaRileyDev
    A
    license
    B
    quality
    D
    maintenance
    Enables management of Coolify instances to control applications, databases, and servers through the Model Context Protocol. It provides a comprehensive set of tools for deploying services and monitoring self-hosted infrastructure using natural language.
    18
    21
    3
    MIT

Latest Blog Posts

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/GoCoder7/coolify-mcp-server'

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