Skip to main content
Glama

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_loops inspects README, .github/copilot-instructions.md, .github/objectives.md, specialist agents, insights, and inferred repo profile.

  • improve_loop creates missing .github structure and installs a coordinator-worker loop. A loop-director routes 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 required continuation plan that tells the calling agent to dispatch loop-director and continue into repository work.

  • record_loop_insight overwrites 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, and tests experts, 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 modified timestamp 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 tools
compare_loopsC

Compare repositories against README/Copilot/objectives/agents/insights loop architecture.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathsYes

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness1/5

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.

Parameters2/5

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.

Purpose3/5

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.

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

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_pathYes
overwrite_managed_filesNo

TDQS

C2.4/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters1/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleYes
improvedYes
repo_pathYes
prune_candidatesNo
reusable_learningsNo
agent_self_improvementNo

TDQS

C2.6/5.0
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 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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv0.1.0
    • First observedcompare_loops
    • First observedimprove_loop
    • First observedrecord_loop_insight

TDQS

B3.1/5.0
Disambiguation5/5

Each tool has a distinct purpose: comparing repositories, installing/refreshing architecture, and recording insights. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (compare_loops, improve_loop, record_loop_insight).

Tool Count4/5

3 tools is on the lower end but well-scoped for the narrow domain of loop architecture management. Not too few to be useless.

Completeness4/5

Covers the core workflow of comparing, improving, and recording insights. Minor gaps like deletion or listing are not essential for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

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/Thor-DraperJr/loop-improver-mcp'

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