Skip to main content
Glama
cloud-aspect

Config MCP Server

by cloud-aspect
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Config MCP Server

An MCP (Model Context Protocol) server providing developer documentation search, configuration helpers, and settings search tools for AI assistants and development workflows.

Features

šŸ” Documentation Search

  • searchDocs: Search markdown, MDX, and text files in your workspace

  • Supports custom glob patterns for targeted searches

  • Perfect for finding documentation, README files, and guides

āš™ļø Configuration Management

  • getConfig: Read configuration files (JSON/JSONC/YAML/TOML)

  • setConfig: Update configuration files safely with dot-notation key paths

  • listConfigs: Discover all configuration files in your workspace

šŸŽ›ļø Settings Search

  • searchSettings: Search through JSON/JSONC settings files

  • Ideal for VS Code settings, application configs, and more

  • Customizable file patterns for different types of settings

Requirements

  • Node.js 18.17+ (20+ recommended)

  • MCP-compatible client (Claude Desktop, Continue.dev, etc.)

Installation & Setup

1. Install Dependencies

npm install

2. Build the Server

npm run build

3. Install VS Code MCP Extension (Recommended)

For the best experience with GitHub Copilot, install the MCP extension for VS Code:

  1. Open VS Code

  2. Go to Extensions (Ctrl/Cmd + Shift + X)

  3. Search for "Model Context Protocol" or "MCP"

  4. Install the official MCP extension

  5. Reload VS Code

4. Configure Your MCP Client

Add to your MCP client configuration:

VS Code with GitHub Copilot (.vscode/settings.json):

{
  "mcp.servers": {
    "config-mcp-server": {
      "command": "node",
      "args": ["${workspaceFolder}/path/to/Config-MCP-Server/dist/index.js"],
      "cwd": "${workspaceFolder}",
      "env": {
        "NODE_ENV": "production"
      }
    }
  },
  "github.copilot.advanced": {
    "mcp.enabled": true,
    "mcp.servers": ["config-mcp-server"]
  }
}

VS Code User Settings (settings.json):

{
  "mcp.global.servers": {
    "config-mcp-server": {
      "command": "node",
      "args": ["path/to/Config-MCP-Server/dist/index.js"],
      "autoStart": true,
      "workspaceRelative": true
    }
  }
}

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "config-mcp-server": {
      "command": "node",
      "args": ["path/to/Config-MCP-Server/dist/index.js"],
      "cwd": "path/to/your/workspace"
    }
  }
}

Continue.dev (.continue/config.json):

{
  "experimental": {
    "modelContextProtocolServers": [
      {
        "transport": {
          "type": "stdio",
          "command": "node",
          "args": ["path/to/Config-MCP-Server/dist/index.js"]
        }
      }
    ]
  }
}

Development Scripts

  • npm run dev ā€” Start in watch mode (supports .ts imports)

  • npm run build ā€” Compile TypeScript to dist/

  • npm start ā€” Run compiled server

  • npm run lint ā€” Check code style

  • npm run format ā€” Format code with Prettier

Tool Reference

searchDocs

Search developer documentation and markdown files.

// Parameters:
{
  query: string,           // Search term or phrase
  include?: string[]       // Custom glob patterns (optional)
}

// Example usage by AI:
// "Search for authentication setup instructions"
// Uses: searchDocs({ query: "authentication setup" })

searchSettings

Search configuration and settings files for specific keys or values.

// Parameters:
{
  query: string,           // Search term
  include?: string[]       // Custom patterns (optional)
}

// Example usage by AI:
// "Find VS Code Python interpreter settings"
// Uses: searchSettings({ query: "python.defaultInterpreterPath" })

getConfig

Read and parse configuration files with optional key extraction.

// Parameters:
{
  file: string,           // Path to config file
  key?: string           // Dot-separated key path (optional)
}

// Example usage by AI:
// "Get the database host from config.json"
// Uses: getConfig({ file: "config.json", key: "database.host" })

setConfig

Update configuration files safely with automatic format detection.

// Parameters:
{
  file: string,           // Path to config file
  key: string,           // Dot-separated key path
  value: string          // JSON-encoded value
}

// Example usage by AI:
// "Set the API timeout to 30000 in config.json"
// Uses: setConfig({ file: "config.json", key: "api.timeout", value: "30000" })

listConfigs

Discover configuration files in the workspace.

// Parameters:
{
  include?: string[]      // Glob patterns (default: common config files)
}

// Example usage by AI:
// "Show me all configuration files"
// Uses: listConfigs({})

Supported File Formats

  • JSON (.json) - Standard JSON files

  • JSONC (.jsonc) - JSON with comments (VS Code style)

  • YAML (.yaml, .yml) - YAML configuration files

  • TOML (.toml) - TOML configuration files

  • Markdown (.md, .mdx) - Documentation files

  • Text (.txt) - Plain text files

Error Handling

All tools include comprehensive error handling and return user-friendly error messages when:

  • Files are not found or unreadable

  • Invalid JSON/YAML/TOML syntax

  • Permission issues

  • Invalid key paths or values

TypeScript Support

The server is built with TypeScript and supports:

  • Import resolution with .ts extensions in development

  • Path aliases (@/lib/...) for cleaner imports

  • Strict type checking for reliability

  • Source maps for debugging

GitHub Copilot Integration

Enhanced Copilot Experience

With this MCP server, GitHub Copilot gains powerful workspace awareness:

  • Context-Aware Suggestions: Copilot can reference your project's documentation and configuration

  • Smart Configuration: Automatically suggests configuration changes based on your project setup

  • Workspace Understanding: Better code completions using your project's README and docs

VS Code Features

  • Workspace Integration: Automatically detects when you're working in a configured workspace

  • Command Palette: Access MCP tools via VS Code Command Palette (Ctrl/Cmd + Shift + P)

  • Status Bar: Shows MCP server connection status

  • Output Panel: View MCP server logs in VS Code Output panel

Usage Examples

In VS Code with GitHub Copilot

Chat with Copilot:

  • "@workspace Search for authentication setup in our docs"

  • "Help me find where the API configuration is defined"

  • "What's the current database timeout setting?"

  • "Update the dev server port to 3001"

Command Palette Integration

  1. Press Ctrl/Cmd + Shift + P

  2. Type "MCP: Config" to see available commands:

    • MCP: Search Documentation

    • MCP: Find Settings

    • MCP: Read Configuration

    • MCP: Update Configuration

    • MCP: List Config Files

Traditional Examples

Finding Documentation

Ask your AI: "Search for Docker setup instructions" ā†’ Uses searchDocs to find relevant documentation

Managing Configuration

Ask your AI: "Update the database port to 5433 in my config file" ā†’ Uses getConfig to read current config, then setConfig to update it

Exploring Settings

Ask your AI: "Show me all my VS Code Python settings" ā†’ Uses searchSettings to find Python-related configuration

VS Code & Copilot Troubleshooting

Common Issues

MCP Server Not Starting:

  1. Check VS Code Output panel (View > Output > Model Context Protocol)

  2. Verify Node.js is installed and accessible in PATH

  3. Ensure the server path in settings.json is correct

  4. Try reloading VS Code (Ctrl/Cmd + Shift + P > Developer: Reload Window)

Copilot Not Using MCP Context:

  1. Verify GitHub Copilot extension is installed and active

  2. Check that github.copilot.advanced.mcp.enabled is set to true

  3. Restart VS Code after configuration changes

  4. Use @workspace prefix in Copilot chat for explicit context

Performance Optimization:

  1. Adjust maxResults in settings if searches are slow

  2. Use more specific glob patterns in include parameters

  3. Add common build directories to search exclusions

VS Code Tips

  • Quick Access: Use Ctrl/Cmd + Shift + P then type "MCP" to see all available commands

  • Status Monitoring: Check the status bar for MCP connection indicators

  • Workspace Templates: Copy .vscode/settings.json.template to your project's .vscode/settings.json

  • Global vs Workspace: Use User settings for global MCP config, Workspace settings for project-specific setup

GitHub Copilot Best Practices

  • Start questions with @workspace to engage MCP context

  • Be specific about file types: "search TypeScript configs" vs "search configs"

  • Use natural language: "What's my current database setup?" instead of technical queries

  • Leverage context: Copilot will automatically use your project's documentation in suggestions

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Run npm run lint and npm run format

  5. Test with VS Code MCP integration

  6. Submit a pull request

License

MIT - See LICENSE file for details

Available Tools

5 tools
getConfigB

Read a configuration file (JSON/JSONC/YAML/TOML) and optionally extract a specific key

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesPath to the configuration file
keyNoOptional dot-separated key path (e.g., 'database.host')

TDQS

B3.2/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. It mentions reading and optional extraction, but fails to disclose critical behavioral traits such as error handling (e.g., if the file doesn't exist or key is invalid), permissions required, or output format details. This is inadequate for a tool with no annotation coverage.

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 a single, efficient sentence that front-loads the core action ('Read a configuration file') and includes essential details (formats, optional extraction). Every word earns its place with zero waste, making it highly concise and well-structured.

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 no annotations, no output schema, and a tool that reads files (potentially with errors or permissions issues), the description is incomplete. It lacks information on return values, error conditions, or behavioral constraints, leaving significant gaps for an AI agent to use it correctly in 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?

Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds minimal value beyond the schema by hinting at the key path format ('dot-separated'), but does not elaborate on semantics like file path resolution or key extraction behavior. Baseline 3 is appropriate as 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 verb ('Read') and resource ('configuration file'), specifying the supported file formats (JSON/JSONC/YAML/TOML) and the optional extraction capability. It distinguishes from sibling 'listConfigs' (which likely lists files) and 'setConfig' (which writes), though not explicitly. The purpose is specific but lacks explicit sibling differentiation.

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 reading configuration files with optional key extraction, but does not explicitly state when to use this tool versus alternatives like 'searchSettings' or 'searchDocs'. No guidance on prerequisites or exclusions is provided, leaving usage context partially inferred.

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

listConfigsB

List configuration files in the workspace matching specified patterns

ParametersJSON Schema
NameRequiredDescriptionDefault
includeNoGlob patterns for config files

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 full burden. It mentions 'list' and 'matching specified patterns', which implies a read-only operation, but doesn't disclose behavioral traits like whether it returns file contents or just names, pagination, rate limits, permissions required, or error conditions. The description is minimal and leaves key behaviors unspecified.

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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for a simple tool, with zero waste or 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?

Given the tool's low complexity (1 optional parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format, which are needed for effective agent use. The simplicity of the tool prevents a lower score, but gaps remain.

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%, with the parameter 'include' documented as 'Glob patterns for config files'. The description adds marginal value by mentioning 'specified patterns', which aligns with the schema but doesn't provide additional semantics like examples of patterns or how matching works. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate beyond the schema.

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 action ('List') and resource ('configuration files in the workspace'), and specifies the scope ('matching specified patterns'). It distinguishes from 'getConfig' (likely retrieves a single config) and 'setConfig' (writes configs), but doesn't explicitly differentiate from 'searchDocs' or 'searchSettings' which might also list files. The purpose is specific but sibling differentiation is incomplete.

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 like 'searchDocs' or 'searchSettings', nor does it mention prerequisites or constraints. It implies usage when needing to list config files with patterns, but lacks explicit when/when-not instructions or named alternatives beyond what can be inferred from sibling names.

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

searchDocsC

Search developer documentation files (Markdown, MDX, text) in the workspace

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term or phrase to find in documentation
includeNoCustom glob patterns to include (default: markdown and docs files)

TDQS

C2.9/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 full burden. It states the action ('Search') but doesn't disclose behavioral traits like whether it's read-only, what permissions are needed, how results are returned (e.g., pagination, format), or any rate limits. This is a significant gap for a search tool with no annotation coverage.

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 a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration. 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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., search results format), potential errors, or behavioral aspects like search scope or limitations. For a search tool with 2 parameters and no structured output information, this leaves significant gaps.

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 both parameters ('query' and 'include') with descriptions. The description adds minimal value beyond the schema by implying the scope ('developer documentation files') but doesn't provide additional syntax or format details. Baseline 3 is appropriate when 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 verb ('Search') and resource ('developer documentation files') with specific file types mentioned (Markdown, MDX, text). It distinguishes from siblings by focusing on documentation files rather than configuration or settings. However, it doesn't explicitly contrast with sibling tools like 'searchSettings' which might search different content.

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 doesn't mention when to prefer this over 'searchSettings' or other siblings, nor does it specify prerequisites or constraints. The only contextual hint is 'in the workspace' which is minimal.

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

searchSettingsB

Search configuration and settings files (JSON/JSONC) for keys or values

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term to find in settings files
includeNoCustom glob patterns for settings files

TDQS

B3.1/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 what files are searched (JSON/JSONC settings files) but doesn't describe important behaviors: whether this is read-only (implied but not stated), what happens with no matches, if search is case-sensitive, performance characteristics, or error conditions. For a search tool with zero annotation coverage, this leaves significant gaps.

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 a single, efficient sentence that clearly states the tool's core function. It's appropriately sized and front-loaded with the essential information - no wasted words or unnecessary elaboration.

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?

For a search tool with 2 parameters (100% schema coverage) and no annotations, the description provides basic context about file types and search targets. However, without an output schema, it doesn't describe what results look like (structure, format, pagination). The description is adequate but has clear gaps in behavioral transparency and usage guidance.

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 fully documents both parameters ('query' and 'include'). The description adds minimal value beyond the schema - it implies the query searches 'keys or values' in settings files, but doesn't provide additional syntax, format details, or examples. Baseline 3 is appropriate when 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: searching configuration and settings files for keys or values, specifying the file formats (JSON/JSONC). It distinguishes from 'searchDocs' by focusing on settings files rather than general documentation, but doesn't explicitly differentiate from 'getConfig' or 'listConfigs' which might also access configuration data.

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 like 'searchDocs' (for documentation), 'getConfig' (to retrieve specific config), or 'listConfigs' (to enumerate configs). It mentions the tool's scope (settings files) but gives no explicit when/when-not rules or comparison with sibling tools.

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

setConfigC

Update a configuration file by setting a value at a specific key path

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesPath to the configuration file
keyYesDot-separated key path to update (e.g., 'database.host')
valueYesJSON-encoded value to set

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 states this is an update operation, implying mutation, but doesn't cover critical aspects like whether the file must exist, if changes are permanent, error handling for invalid paths, or authentication needs. This is a significant gap for a mutation tool without annotation support.

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 a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It's appropriately sized and front-loaded, with every word contributing to understanding the core purpose, making it highly concise and well-structured.

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 tool's complexity as a mutation operation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., side effects, error cases), output format, or usage context relative to siblings. For a tool that modifies files, this leaves significant gaps for an AI agent to operate safely and 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 input schema already fully documents all three parameters (file, key, value) with clear descriptions. The description adds no additional semantic information beyond what's in the schema, such as examples for 'value' beyond 'JSON-encoded' or constraints on 'key' format. 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 action ('Update'), resource ('configuration file'), and specific operation ('setting a value at a specific key path'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'getConfig' or 'listConfigs', but the verb 'Update' implies a write operation versus their likely read operations, providing some implicit differentiation.

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 like 'searchSettings' or 'searchDocs', nor does it mention prerequisites such as file existence or permissions. It implies usage for modifying configuration files but lacks explicit context or exclusions, leaving the agent to infer based on tool names alone.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 5 tool updates
    • First observedgetConfig
    • First observedlistConfigs
    • First observedsearchDocs
    • First observedsearchSettings
    • First observedsetConfig
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: getConfig reads and extracts from config files, listConfigs lists files, searchDocs searches documentation, searchSettings searches config files for keys/values, and setConfig updates config files. There is no overlap or ambiguity between these functions.

Naming Consistency4/5

The naming is mostly consistent with a verb_noun pattern (getConfig, listConfigs, setConfig), but searchDocs and searchSettings deviate slightly by using 'search' instead of a more specific verb like 'find' or 'query'. However, the pattern remains readable and coherent.

Tool Count5/5

With 5 tools, the server is well-scoped for configuration management. Each tool serves a distinct and necessary function in the domain, such as reading, listing, searching, and updating configurations, without being overly sparse or bloated.

Completeness4/5

The tool surface covers core CRUD-like operations for configuration files (get, list, set) and includes useful search capabilities. A minor gap is the lack of a deleteConfig tool for removing keys or files, but agents can likely work around this by using setConfig to clear values.

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

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/cloud-aspect/Config-MCP-Server'

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