loop-improver-mcp
The loop-improver-mcp server modernizes and manages agent/Copilot guidance architecture across repositories by inspecting, installing, and recording loop improvements.
compare_loops: Inspect one or more repositories against a loop architecture rubric — evaluating the README,.github/copilot-instructions.md,.github/objectives.md, specialist agents, and insights — to identify stale or missing collaboration surfaces.improve_loop: Install or refresh the foundational.githubloop structure in a target repository, including:Creating missing
.githubfolder structureInstalling/refreshing
objectives.md(shared repository mission)Adding specialist guidance files under
.github/agents/Creating/updating insight files under
.github/insights/Preserving user-authored content while updating managed files (marked
<!-- Managed by loop-improver-mcp -->)
record_loop_insight: Write a structured insight entry to.github/insights/loop-improver-mcp.md, capturing verified improvements, prune candidates, reusable learnings, and agent self-improvement notes.Every tool response includes
serverInfo.versionandserverInfo.sourcePathso clients can detect stale installations or confirm the correct workspace is loaded.
Inspects and improves GitHub repository guidance files, including README, copilot instructions, objectives, agents, and insights, to modernize collaboration surfaces for Copilot.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@loop-improver-mcpcompare and improve loops in the repo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
loop-improver-mcp
MCP server for modernizing agent guidance across repositories.
loop-improver-mcp inspects a repository, establishes its product mission in .github/objectives.md, and activates a managed Copilot team that continues into useful product work.
It handles repos that already have mature .github files and repos that have no .github folder at all. The MCP call owns the architecture pass; generated agents are only for recurring domain work that needs a dedicated instruction surface.
Tools
compare_loopsinspects README,.github/copilot-instructions.md,.github/objectives.md, specialist agents, insights, and inferred repo profile.improve_loopcreates missing.githubstructure and installs a coordinator-worker loop. Aloop-directorroutes bounded research to folder experts, a file-practices specialist, and a repository-cleanup expert. Folder and cleanup experts first propose a bounded edit, then implement only after the director approves the paths, actions, and checks. It also refreshes objectives, profile-specific implementation guidance, and current insight files while preserving durable user-authored instructions and agents. Its response always includes a requiredcontinuationplan that tells the calling agent to dispatchloop-directorand continue into repository work.record_loop_insightoverwrites the current architecture learning in.github/insights/loop-improver-mcp.md.
improve_loop also installs a /goal prompt. Run it with a specific outcome or with no argument for a general improvement pass. The director uses the canonical product mission, gathers bounded evidence, and completes safe local work autonomously. It asks only when destructive, external, publishing, secret-handling, materially ambiguous, or substantially expanded work needs a decision.
Every tool response includes serverInfo.version and serverInfo.sourcePath so clients can identify stale installations or confirm that a workspace checkout is loaded.
improve_loop also returns a report with a short outcome summary, one row per added, updated, or pruned managed file, the reason pruning was limited, Mermaid source for the installed agent flow, and a recommended presentation format. The separate continuation object sets workflowComplete to false, sets dispatchNow to true, names the director and available experts, and leads with the canonical productMission, its source, a product-first priority policy, the next prompt, risk policy, and completion criteria. An empty changed list means the architecture is ready. It does not mean the repository improvement pass is complete.
Related MCP server: AI Knowledge Center MCP
Repository Benefits
Predictable expertise: every repository gets the same director and
.github,src, andtestsexperts, with optional profile guidance for its technology.Better decisions: experts connect recommendations to controlling code, tests, user outcomes, and repository evidence before changes begin.
Product-first autonomy: the director completes safe local improvements and interrupts only for material risk or ambiguity.
Smaller codebases: cleanup is part of the normal loop, so dead code, duplication, generated output, stale guidance, and failed approaches become routine review targets.
Durable improvement: objectives and current insights preserve what worked, what was removed, and what the next pass should examine.
Outcome Rubric
The server evaluates canonical files against a desired shape:
README.md: names the repo, audience, capabilities, and durable entry points without becoming an operational runbook..github/copilot-instructions.md: holds durable rules, validation expectations, safety boundaries, and canonical file ownership..github/objectives.md: owns the canonical product mission, names repo-specific outcomes, maps active loops to those outcomes, and defines evidence for improvement.Last modified hygiene: surfaces text files missing a
Last modifiedtimestamp and files whose timestamp is older than 30 days by default, then suggests objective and folder focus for the next session..github/agents/: contains specialist guidance only for recurring domain work..github/insights/: records one current insight per MCP or specialist surface with verified improvements, prune candidates, reusable learnings, and self-improvement notes.
Generated specialists also audit changed and nearby symbols for duplicate helpers and unused code. In this repository, Ruff enforces source orientation and code-quality rules, the readability test checks every production module and symbol for concise descriptions, and Vulture reports high-confidence dead-code candidates for reference verification.
Usage Shape
Call compare_loops against older repos, then call improve_loop on repos missing the foundation or carrying stale guidance. Managed files are marked with <!-- Managed by loop-improver-mcp --> so later refreshes can update the loop without overwriting unrelated repo guidance.
Call improve_loop with its default refresh behavior. The calling Copilot agent should dispatch the generated loop-director immediately from the returned continuation plan and should not ask the user to choose preserve or overwrite mode unless the user explicitly requested preservation. In clients that cannot dispatch custom agents from an MCP response, select loop-director and run /goal as the compatibility path.
The director uses VS Code's coordinator-worker subagent pattern: folder and file specialists return independent evidence and a bounded edit plan, the director ties that evidence to controlling functions and tests, and the owning expert implements the approved scope. Every repository receives the same .github, src, and tests folder experts. When a standard folder is absent, its expert reports whether the repository needs that scope instead of creating the folder. Existing domain agents join the director's allowlist, while profile-specific fallback guidance is created only when the repository has no matching specialist.
The generated specialist guidance adapts to portable repository signals such as Python, Rust, TypeScript, content, documentation, or infrastructure files. Domain-specific context comes from the target repository's objectives and existing guidance, so the server can create useful loops without carrying assumptions from another project or machine.
Use With GitHub Copilot
Paste this into GitHub Copilot Chat after opening the repository:
Install and configure this repository's loop-improver MCP server for my VS Code GitHub Copilot environment. Follow .github/mcp-install.md, verify that the server starts, and keep the configuration portable for future updates.Available Tools
3 toolscompare_loopsC
Compare repositories against README/Copilot/objectives/agents/insights loop architecture.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_paths | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states 'compare', but does not disclose whether the operation is read-only, requires permissions, or produces any side effects. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action. No redundant information or filler, making it concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only one parameter, the description is severely incomplete. It fails to explain what the comparison produces (report, list, diff?), how results are presented, or how to interpret them, leaving an agent without enough information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'repo_paths' has no schema description (0% coverage). The description says 'Compare repositories', which implies the parameter contains repository paths, but this is already suggested by the parameter name. No additional constraints or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a comparison action against a specific architecture, but the relationship between 'repositories' and 'loops' is unclear. The sibling tools 'improve_loop' and 'record_loop_insight' suggest a focus on loops, yet the description mentions repositories, creating ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Implied usage is for comparing repos against the loop architecture, but no exclusions or context for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
improve_loopC
Install or refresh the foundational loop architecture in a target repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes | ||
| overwrite_managed_files | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies mutation ('install or refresh') but does not explain side effects, reversibility, or what 'refreshing' entails. The parameter overwrite_managed_files hints at overwriting, but the description offers no clarification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it is under-specified, sacrificing clarity for brevity. A balanced length would better serve the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description is incomplete. It fails to explain the 'loop architecture', the installation process, or how this tool relates to siblings, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does not mention repo_path or overwrite_managed_files at all, providing no value beyond the schema's names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Install or refresh' and the resource 'foundational loop architecture', clearly indicating the tool's action. It is somewhat distinguishable from siblings like compare_loops (comparison) and record_loop_insight (recording), though the exact nature of 'loop architecture' remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent to infer usage without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
record_loop_insightC
Write the current architecture insight to .github/insights/loop-improver-mcp.md.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| improved | Yes | ||
| repo_path | Yes | ||
| prune_candidates | No | ||
| reusable_learnings | No | ||
| agent_self_improvement | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that it writes to a file, but omits details like whether it overwrites or appends, required permissions, or side effects. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence, but it is too vague for the tool's complexity. It is front-loaded with the basic purpose, but lacks necessary details, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not mention return values, parameter meanings, or behavioral expectations, leaving the agent without enough information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to the six parameters. It does not explain what each parameter (e.g., title, improved, repo_path) represents or how they relate to the 'current architecture insight'. The agent would be confused about how to fill in fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and the resource 'current architecture insight' to a specific file path. This distinguishes the tool from siblings compare_loops and improve_loop, which likely have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool's name and purpose 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.
3 tool updates
v0.1.0- First observed
compare_loops - First observed
improve_loop - First observed
record_loop_insight
TDQS
Each tool has a distinct purpose: comparing repositories, installing/refreshing architecture, and recording insights. No overlap.
All tools follow a consistent verb_noun pattern (compare_loops, improve_loop, record_loop_insight).
3 tools is on the lower end but well-scoped for the narrow domain of loop architecture management. Not too few to be useless.
Covers the core workflow of comparing, improving, and recording insights. Minor gaps like deletion or listing are not essential for the stated purpose.
Maintenance
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
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
- RampifyOAuthdev.rampify
SEO MCP server: crawl your site, find AI-visibility gaps, and ship the fix from your coding agent.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceAn MCP server that gives your agent a persistent project brain: vision, architecture decisions, conventions, roadmaps, and automatic session handoff.126MIT
- AlicenseNot gradedqualityAmaintenanceLocal-first MCP server that provides project context, verification gates, and structured tools for coding agents to discover knowledge, run diagnostics, and execute allowlisted commands within a repository.35MIT
- AlicenseCqualityBmaintenanceA policy-aware MCP server for GitHub and GitHub Actions that enables safe AI-assisted infrastructure workflows—inspecting repositories, preparing branches and pull requests, and constrained remote mutations behind explicit preview-bound approval tokens.18MIT
- AlicenseNot gradedqualityCmaintenanceMCP server that enables AI agents to analyze legacy code, plan and execute software migrations, generate modern source code, and validate production-ready artifacts through a multi-agent pipeline.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Thor-DraperJr/loop-improver-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server