devsync-mcp

by troylar

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: pulling profiles, detecting configs, previewing merges, applying merges, listing status, backups, etc. No two tools overlap in functionality; sync_all is explicitly a convenience wrapper.
Naming Consistency4/5
All tool names use snake_case and imperative verbs (apply, detect, get, list, preview, pull, restore, sync). The naming patterns are mostly verb_noun, though 'list_profile_configs' and 'list_backups' mix noun sequences. Overall consistent and readable.
Tool Count5/5
With 9 tools, the server covers the config synchronization workflow without unnecessary bloat. Each tool serves a specific, non-redundant role in the lifecycle of pulling, merging, and restoring configs.
Completeness4/5
The tool surface covers the full lifecycle: pulling profiles, detecting local configs, previewing merges, applying merges, managing backups, and checking status. A minor gap is the lack of a tool to explicitly update a profile (e.g., re-pull), but the workflow is tightly scoped and functional.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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 must fully disclose behavior. It mentions 'clone or pull' implying an update operation but does not clarify if existing local changes are overwritten, whether authentication is required, or what happens on conflict. The return type is briefly described but lacks details like error handling or rate limits.
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 with a clear header sentence, followed by structured Args and Returns sections. Every sentence adds value without redundancy. It is appropriately front-loaded.
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 two parameters and a provided output schema, the description covers the basics. However, it lacks usage guidelines and behavioral details (e.g., whether the tool updates existing repos or always clones anew). For a moderate-complexity tool, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: git_url is described as 'Git repository URL or local path containing team configs' and namespace as 'Override namespace (auto-derived from URL if not provided)'. Since schema description coverage is 0%, the description fully compensates by explaining both parameters clearly.
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 action: 'Clone or pull a team config profile repository into the local devsync library.' This provides a specific verb and resource, and while it distinguishes from sibling tools like list_profile_configs, it could be more precise about the 'clone or pull' ambiguity.
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?
No explicit guidance on when to use this tool versus alternatives. The description lists parameters and return values but does not mention typical use cases, preconditions, or when to prefer pull_team_profile over sync_all or restore_backup.
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 indicates a write operation but does not disclose potential destructive behavior (e.g., overwriting target), permission requirements, or side effects.
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 well-structured, using clear headers for args and returns. Every sentence adds value without 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?
The description is adequate for a simple two-parameter tool with an output schema, but leaves gaps such as safety considerations and preconditions for usage.
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 coverage is 0%, so the description must compensate. It adds meaning by describing backup_path as coming from list_backups and target_path as the restore location, but lacks details like file format or constraints.
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: restoring a config file from a backup. It uses a specific verb and resource, and distinguishes from siblings like list_backups (listing) and preview_merge (previewing).
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 provides implicit usage context (e.g., backup_path comes from list_backups) but lacks explicit guidance on when to use this tool versus alternatives, such as when to avoid it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the transparency burden. It discloses the return structure (paths, sizes, timestamps) and implies read-only behavior via 'list,' but does not mention permissions, side effects, or limitations beyond merge origin.
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?
Concise with a clear purpose line and structured Args/Returns sections. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema issues), the description sufficiently covers purpose, parameter, and return. However, lacking usage guidelines reduces completeness for an agent choosing among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Filter backups by profile (all if not specified)' to the single parameter profile_name, which is absent in the schema (only type and default). This provides clear meaning and usage context.
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 'List backup files from previous merge operations,' specifying the verb (list) and resource (backup files). This distinguishes it from siblings like restore_backup and apply_merge, which have different actions.
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?
No guidance on when to use this tool versus alternatives (e.g., restore_backup, list_profile_configs). The description does not provide context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It indicates the tool is read-only by saying 'show', but does not disclose permissions, side effects, or error scenarios. It describes output statuses but is vague on non-existent namespace behavior.
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, with a clear one-line summary, bullet list of possible statuses, and separate Args and Returns sections. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (implied by 'Returns: List of config statuses'), the description adequately covers the output with example statuses. It explains the two parameters and their purpose, making it sufficiently complete for a simple status-check 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?
The input schema has 0% description coverage, but the description's Args section adds meaningful context for both parameters ('namespace: Profile namespace', 'project_root: Project root for project-relative targets'). This adds value beyond the schema's basic type information.
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 shows merge status for all configs in a profile. It uses a specific verb ('show') and resource, distinguishing it from siblings like 'apply_merge' and 'preview_merge'.
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 explains what the tool reports (pending, merged, changed) and lists required args, but does not provide explicit guidance on when to use it versus alternatives like 'detect_current_configs' or 'preview_merge'. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns a merge plan with status of each config, but does not mention behavioral traits like read-only nature, side effects, permissions, or rate limits. Since no annotations are provided, the description carries full burden for transparency but falls short on these aspects.
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 highly concise, beginning with a clear one-line purpose, then a brief explanation, followed by structured Args and Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown, but indicated), the description provides adequate return information ('Merge plan with status of each config'). It could mention that the output schema details the plan structure, but overall it's complete for a combined tool. Minor gap: no mention of when to use this vs the individual sibling tools.
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?
With schema description coverage at 0%, the description compensates by explaining each parameter in the Args section: 'namespace: Profile namespace' and 'project_root: Project root for project-relative targets'. This adds meaningful context beyond the schema's type-only definitions.
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 function: 'Pull latest profile, detect changes, and present a merge plan.' It also explains it's a convenience tool combining pull and status check. This distinguishes it from siblings like pull_team_profile (pull only) and get_merge_status (status only).
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 when wanting both pull and status in one call ('convenience tool that combines'), but does not explicitly state when to use vs alternatives or when not to use. It could provide more guidance on choosing between this and the individual sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only scan ('detects', 'returns list') but does not explicitly state it is non-destructive. Given no annotations, the agent must assume safety. It adds return format but lacks details on side effects or permissions.
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 brief, with a lead sentence and clear Args/Returns sections. Every sentence adds value, no fluff, and it is well-structured for quick parsing.
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?
For a simple detection tool with one parameter and an output schema (though not shown), the description covers the necessary aspects: what it detects, the optional path, and the return format. No gaps are apparent given the tool's complexity.
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?
The description explains the single parameter 'project_root' with default behavior ('defaults to cwd'), adding meaning beyond the schema which has no descriptions. This compensates for 0% schema coverage, though could be slightly more detailed (e.g., relative vs absolute).
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 scans for existing configuration files, listing types (shell profiles, git configs, etc.). It distinguishes from siblings like 'list_profile_configs' which focus on profile configs only, and 'apply_merge' which applies changes. The verb 'detect' and noun 'configs' are specific.
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 tells what the tool does but does not explicitly state when to use it versus alternatives like 'list_profile_configs'. No guidance on when not to use or prerequisites is provided, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that a backup is created, which is a key behavioral trait. However, it does not disclose other potential side effects (e.g., overwriting, error conditions) or required permissions, leaving some 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 concise with a clear action statement, usage note, and parameter list. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the main purpose, input parameters, and return type. It does not elaborate on prerequisites or edge cases, but it is reasonably complete for a merge-apply 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?
Schema description coverage is 0%, but the description includes meaningful parameter explanations (namespace, config_name, merged_content, target_path) that add clarity beyond the schema. Each parameter is briefly but adequately described.
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 action: 'Write LLM-merged content to the target path, creating a backup of the original.' It is a specific verb+resource and distinguishes itself from sibling tools by specifying it should be called after preview_merge, fitting uniquely into the merge workflow.
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?
The description explicitly says 'Call this AFTER the LLM has produced the merged content from preview_merge output,' providing clear usage context. It does not mention when not to use or alternatives, but the sequencing is sufficient for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It discloses the return shape (name, type, target path, description) and that it lists configs, which implies a read-only operation. However, it omits potential side effects or permissions.
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?
Three sentences: purpose, parameter, return. No wasted words, front-loaded with main action.
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 the presence of an output schema, the description adds sufficient context (return fields) and parameter guidance, leaving no obvious gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema parameter description coverage, the description fully compensates by explaining the 'namespace' parameter as 'Profile namespace (as returned by pull_team_profile)', providing crucial context beyond the bare schema.
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 verb 'list' and resource 'config files in a pulled team profile', and it distinguishes from siblings like 'list_backups' and 'pull_team_profile'.
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 after pull_team_profile via the arg clarification, but does not explicitly state when to use vs. alternatives or provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool does not perform the merge and returns both contents. It also describes the return structure. Without annotations, this is good transparency, though it could mention any side effects or permissions.
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 well-structured with a clear summary, a note on behavior, and an Args section. It is not overly verbose, though the Args section could be more integrated. Front-loaded with the main purpose.
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?
The description covers purpose, behavior, parameters, and return values. It differentiates from siblings (e.g., apply_merge) and includes all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's 'Args' section thoroughly explains each parameter's meaning, including origins (e.g., 'from list_profile_configs' for config_name). This fully compensates for the missing schema descriptions.
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 that the tool returns source and target content for merging, and explicitly notes that the MCP server does not perform the merge. This distinguishes it from siblings like apply_merge, making the purpose specific and unambiguous.
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?
The description explains that the tool is used to return contents for the LLM to intelligently merge, implying it is for previewing. It does not explicitly state when not to use it, but the context of sibling tools (e.g., apply_merge) provides implicit guidance.
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:

[![devsync-mcp MCP server](https://glama.ai/mcp/servers/troylar/devsync-mcp/badges/card.svg)](https://glama.ai/mcp/servers/troylar/devsync-mcp)

Score Badge

Copy to your README.md:

[![devsync-mcp MCP server](https://glama.ai/mcp/servers/troylar/devsync-mcp/badges/score.svg)](https://glama.ai/mcp/servers/troylar/devsync-mcp)

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/troylar/devsync-mcp'

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