Config MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 3/5 across 5 of 5 tools scored.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Config-MCP-Server MCP server](https://glama.ai/mcp/servers/cloud-aspect/Config-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/cloud-aspect/Config-MCP-Server)

Score Badge

Copy to your README.md:

[![Config-MCP-Server MCP server](https://glama.ai/mcp/servers/cloud-aspect/Config-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/cloud-aspect/Config-MCP-Server)

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

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