How do I use Loopy MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Loopy MCP Server Search for loops related to automated testing" 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.

Loopy MCP Server

by hotkid61

Overview Schema Related Servers Score Discussions

TypeScript

Local

Loopy MCP Server

A Model Context Protocol (MCP) server that brings Loopy functionality to LM Studio and other MCP-compatible clients.

What is Loopy?

Loopy is a library of practical AI-agent loops and tools for discovering, adapting, crafting, and running repeatable agent workflows. A loop is a bounded, feedback-driven workflow that helps agents learn from results and take the next useful step.

From Forward Future: https://signals.forwardfuture.com/loop-library/

Related MCP server: agent-orchestrator

Why Loopy MCP Server?

LM Studio doesn't have a skill system (yet), so this MCP server bridges the gap by exposing Loopy's core functionality through the MCP protocol. Now you can use Loopy directly in LM Studio to:

Search and discover published loops from the Loop Library
Get recommendations for your specific tasks
Analyze loops for weaknesses and improvements
Craft new custom loops through guided questions
Save loops to your project for reuse
Discover repeated patterns in your codebase
Execute loops with bounded passes and track results

Features

✅ Search the Loop Library - Find published loops by keyword
✅ Get Recommendations - Discover loops for your specific task
✅ Analyze Loops - Audit for weaknesses, stopping conditions, verification
✅ Craft Loops - Interactive questions to design custom loops
✅ Save Loops - Store loops in project's LOOPS.md
✅ Load Project Loops - Reuse saved loops
✅ Discover Patterns - Find repeated patterns in your codebase
✅ Run Loops - Execute with bounded passes and get receipts
✅ Live Catalog - Connects to the latest Loop Library

Installation

Prerequisites

Node.js 20+
npm or yarn

Setup

git clone https://github.com/hotkid61/Loopy-MCP-Server.git
cd Loopy-MCP-Server
npm install

Usage

Start the Server

npm run server

The server will start listening for JSON-RPC requests on stdin/stdout.

For LM Studio

Add this to your LM Studio MCP configuration:

{
  "mcpServers": {
    "loopy": {
      "command": "npm",
      "args": [
        "--prefix",
        "/path/to/Loopy-MCP-Server",
        "run",
        "server"
      ]
    }
  }
}

Replace /path/to/Loopy-MCP-Server with your actual installation path.

Available Tools

search_loops

Search the Loop Library catalog for loops by keyword

query: string (required) - Search keywords
limit: number (optional) - Max results (default: 5)

get_loop_recommendations

Get loop recommendations based on your task

task: string (required) - Describe what you want to accomplish

get_loop_details

Get full details of a specific loop

loop_id: string (required) - Loop ID or name

analyze_loop

Audit a loop for weaknesses and get suggestions

loop_prompt: string (required) - The loop instructions to analyze

craft_loop

Get interview questions to help design a custom loop

save_loop

Save a loop to your project's LOOPS.md

name: string (required) - Loop name
description: string (required) - One-sentence description
prompt: string (required) - The loop instructions
source: string (optional) - Source URL if adapted from published loop

load_project_loops

Load all loops saved in your project's LOOPS.md

discover_patterns

Analyze your codebase for repeated patterns

run_loop

Execute a loop with bounded passes

loop_prompt: string (required) - The loop to execute
max_passes: number (optional) - Max passes (default: 10)
loop_name: string (optional) - Loop name for tracking

List all categories in the Loop Library

File Structure

Loopy-MCP-Server/
├── loopy-mcp-server.ts    # Main MCP server
├── catalog-client.ts      # Loop Library catalog integration
├── loopy-tools.ts         # Core Loopy functionality
├── loop-executor.ts       # Loop execution and tracking
├── package.json           # Dependencies
├── tsconfig.json          # TypeScript config
├── .gitignore             # Git ignore rules
└── README.md              # This file

Examples

Find a loop for your task

Request: "Find a loop for improving test coverage"

Searches the catalog
Returns top 3 recommendations
Shows use cases, prompts, verification steps

Analyze an existing loop

Request: "Audit this loop and suggest improvements: [paste loop]"

Checks for clear stopping conditions
Verifies acceptance criteria
Identifies gaps
Suggests improvements

Save and reuse project loops

Request: "Save this loop to the project"

Saves to LOOPS.md
Available in future sessions
Can be exported to Loop Library

Run a loop with tracking

Request: "Run the Improve Test Coverage loop in this project"

Executes in bounded passes
Tracks actions and evidence
Provides receipt with outcome
Suggests improvements via debrief

How Loops Work

A good loop answers four questions:

What are you trying to accomplish? - Clear goal
How will you know it worked? - Acceptance criteria
What should you do with what you learn? - Feedback cycle
When should you stop? - Exit condition

Example:

Find the slowest page, make one focused improvement, and measure again. Keep the change only if it helps. Repeat until every page meets the target or another pass stops producing improvement.

Integration with Forward Future

This server connects to the official Loop Library maintained by Forward Future:

Catalog: https://signals.forwardfuture.com/loop-library/
Repository: https://github.com/Forward-Future/loopy
License: MIT

Loops are published with quality checks and can be submitted to the catalog from your project.

Features in Detail

Loop Discovery

Analyzes your codebase for repeated engineering patterns and turns strong candidates into bounded loops.

Loop Adaptation

Takes a published loop and tailors it to your tools, limits, schedule, and definition of success.

Loop Execution

Runs loops in bounded passes, applies acceptance checks, and returns evidence-backed receipts.

Loop Debrief

Analyzes run results and recommends the smallest justified improvement.

Publication

Validates, checks catalog overlap, and prepares loops for publication in Loop Library.

Notes

Catalogs are cached for 1 hour to reduce network requests
Loop execution is simulated in basic mode (can be extended with real execution)
LOOPS.md stores project-local loops for reuse
LOOPS_RUNS.md tracks execution receipts for analysis
All operations are non-destructive unless explicitly requested

License

MIT

Built With

TypeScript
Node.js
MCP Protocol
Loop Library (Forward Future)

Support

For issues with Loopy itself: https://github.com/Forward-Future/loopy For MCP server issues: Create an issue in this repository

Ready to bring Loopy to LM Studio! 🚀

Available Tools

10 tools

analyze_loopC

Audit a loop for weaknesses, check stopping conditions, and suggest improvements

ParametersJSON Schema

Name	Required	Description	Default
`loop_prompt`	Yes	The loop prompt/instructions to analyze

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It mentions audit and suggestions but does not state whether the tool modifies any data, whether it requires an existing loop, or what the output format is. The verb 'audit' implies read-only but is not explicit.

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 a single 13-word sentence, clear and front-loaded. It conveys essential actions without waste, though it could benefit from additional structure.

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 simple tool with one parameter and no output schema, the description is moderately complete. It lacks details about what the tool returns or whether it requires the loop to be saved, but the core function is clear.

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 100% with a description for loop_prompt. The description adds context that analysis covers weaknesses, stopping conditions, and improvements, but does not elaborate on expected format or constraints of the prompt parameter.

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 specifies auditing a loop for weaknesses, checking stopping conditions, and suggesting improvements. It distinguishes from sibling tools like craft_loop, run_loop, and discover_patterns by focusing on analysis rather than creation or execution.

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 such as get_loop_recommendations or get_loop_details. Does not specify prerequisites or context for use.

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

craft_loopB

Get interview questions to help craft a custom loop for your needs

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Get interview questions' without detailing return format, side effects (though likely none), or any constraints. This is insufficient for an agent to understand the tool's behavior.

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 a single 14-word sentence, which is concise and front-loaded. However, its brevity sacrifices some clarity; a slightly more informative structure could improve understanding without adding much length.

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 no parameters, no output schema, and no annotations, the description is minimal. It provides the basic purpose but lacks details like what kind of interview questions, their number, or how they relate to the loop crafting process. It is adequate for a very simple tool but leaves gaps.

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?

There are no parameters, so schema coverage is trivially 100%. The baseline for zero parameters is 4, and the description adds no parameter info because none exist. This score reflects that the absence of parameters is handled adequately.

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 provides interview questions for crafting a custom loop. It uses a specific verb ('Get') and resource ('interview questions'), and the purpose is distinct from siblings like 'get_loop_details' or 'analyze_loop', though explicit differentiation is missing.

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 alternatives. There is no mention of prerequisites, typical scenarios, or when not to use it, leaving the agent to infer context from the sibling list alone.

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

discover_patternsB

Analyze the codebase for repeated patterns that could become loops

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description only says 'analyze', implying a read-only operation but lacks details on scope, permissions, or side effects. Ambiguity around 'repeated patterns'.

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?

Single sentence, very concise. Front-loaded with action. However, it could include more context without increasing length significantly.

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?

The description is minimal for a tool with no annotations, no output schema, and no parameters. It does not explain the scope (e.g., entire project or current file) or what the output looks like, leaving the agent underinformed.

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?

No parameters exist, and the schema coverage is trivially 100%. The description does not need to add parameter info. Baseline for 0 parameters is 4.

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 analyzes the codebase for repeated patterns that could become loops. It distinguishes from siblings like 'analyze_loop' which likely focuses on existing loops.

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 like 'analyze_loop' or 'get_loop_recommendations'. The agent must infer from the name and description.

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

get_loop_detailsB

Get full details of a specific loop from the catalog

ParametersJSON Schema

Name	Required	Description	Default
`loop_id`	Yes	Loop ID or name

TDQS

B3.3/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 bear full responsibility for disclosing behavior. It implies read-only access ('Get full details ... from the catalog') but does not explicitly state it is non-destructive or idempotent, nor address auth, rate limits, or side effects. This is insufficient for a tool with no annotation safety net.

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, front-loaded sentence with zero wasted words. Every word earns its place by clearly communicating the action, resource, and scope. Ideal conciseness for a simple retrieval tool.

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 simplicity (1 param, no output schema, no nested objects), the description is minimally adequate but lacks specificity. It says 'full details' without hinting at the return structure or fields. For an agent to decide if this tool meets its needs, more context about what 'details' entails would be helpful.

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 100% and the schema already describes the single parameter as 'Loop ID or name'. The description adds no additional meaning beyond restating it as 'specific loop'. With high coverage, a baseline of 3 is appropriate; no extra value is provided.

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 it retrieves 'full details of a specific loop from the catalog', using a specific verb and resource. This distinguishes it from sibling tools like analyze_loop (analysis) or craft_loop (creation), so an agent can easily identify its purpose.

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. Siblings like get_loop_recommendations or analyze_loop could be confused, and there is no mention of prerequisites or exclusions. The agent must infer usage from the name alone.

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

get_loop_recommendationsC

Get loop recommendations based on what you're trying to accomplish

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	Describe what you want to accomplish

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, or what the output format is. It fails to compensate for the absence of annotations.

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 and concise, but it lacks detail. It is appropriately sized for the tool's simplicity but could be more informative.

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 single parameter and no output schema, the description is incomplete. It does not explain what constitutes a recommendation or how to use the results.

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 100% with a description for the 'task' parameter, but the tool description adds no additional meaning beyond the schema's 'Describe what you want to accomplish'.

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 provides loop recommendations based on a task. It differentiates from siblings like get_loop_details or search_loops by focusing on recommendations, but the phrasing 'based on what you're trying to accomplish' is somewhat 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 on when to use this tool versus alternatives like search_loops or discover_patterns. The description does not specify prerequisites or context.

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

list_categoriesB

List all loop categories in the catalog

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/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 only states the basic action. It does not mention read-only nature, authentication requirements, or any 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 a single concise sentence with no unnecessary words. Every part is essential.

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 output schema and no behavioral context, the description is insufficient for a complete understanding. Missing details such as whether results are sorted, paginated, or if there are any filters.

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?

There are no parameters, so baseline is 4. The description adds no parameter information, but none is needed.

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 'List all loop categories in the catalog' clearly states the verb (list) and resource (loop categories). It is unambiguous and provides the scope ('all in the catalog'). However, it does not differentiate from sibling tools, though none appear to list categories specifically.

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 usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention prerequisites or exclusions.

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

load_project_loopsB

Load loops saved in the project's LOOPS.md file

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description should disclose behavioral aspects like file existence requirements or data format. It merely says 'load loops' without explaining how the file is parsed or whether it modifies state.

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, concise sentence that directly states the tool's purpose with no extraneous information.

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 output schema and no annotations, the description is incomplete. It fails to explain what 'loops' are, how the data is structured, or any prerequisites (e.g., file must exist).

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 tool has zero parameters and schema coverage is 100%. The description adds no parameter info because none exist, and the baseline of 4 is appropriate.

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 ('load loops') and the specific source ('project's LOOPS.md file'), distinguishing it from siblings like save_loop or search_loops. However, it does not specify the return format or scope.

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 get_loop_details or search_loops. The context is implied but not explicit.

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

run_loopB

Execute a loop with bounded passes and get a receipt

ParametersJSON Schema

Name	Required	Description
`loop_name`	No	Name of the loop for tracking
`max_passes`	No	Maximum number of passes (default: 10)
`loop_prompt`	Yes	The loop prompt to execute

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description only mentions execution and receipt but does not disclose side effects, safety, or whether the loop execution is destructive or idempotent.

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?

Single sentence with no redundancy; front-loaded essential action and outcome.

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?

Simple tool with few params; description covers core purpose but lacks behavioral context that would be expected without annotations.

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 provides 100% param descriptions; description adds 'bounded passes' and 'receipt' but does not significantly extend beyond schema defaults.

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?

Description clearly states the tool executes a loop with bounded passes and returns a receipt, distinguishing it from sibling tools that analyze, craft, or retrieve loop details.

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 siblings like analyze_loop or craft_loop; misses explicit context for selection.

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

save_loopC

Save a loop to the project's LOOPS.md file

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Loop name
`prompt`	Yes	The loop prompt/instructions
`source`	No	Optional source URL if adapted from published loop
`description`	Yes	One-sentence description

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavioral traits, but it only states the basic action. It does not mention whether saving overwrites or appends, what permissions are needed, or any side effects like modifying existing files.

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 very concise at one sentence, but it is too minimal to be considered efficient. It lacks useful detail that could be added without significant length.

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 has 4 parameters, no output schema, and no annotations, the description is incomplete. It does not address important behaviors like duplicate handling, validation, or file state, leaving significant gaps for an agent.

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 100%, so each parameter is described in the schema. The description adds no extra meaning beyond what the schema provides, earning the baseline score of 3.

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 'Save' and the resource 'a loop to the project's LOOPS.md file', indicating a write operation. It distinguishes from siblings like 'craft_loop' (creation) and 'run_loop' (execution), though it does not explicitly differentiate.

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, no prerequisites, and no conditions for appropriate use. It merely states the action without context.

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

search_loopsB

Search the Loop Library catalog for published loops by keyword

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results to return (default: 5)
`query`	Yes	Search keywords (e.g., 'test', 'documentation')

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. Description lacks behavioral details such as pagination, rate limits, or behavior for empty results. As a search tool, it implies no destructive actions but doesn't confirm.

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?

Single sentence is concise and front-loaded with verb and object. However, it is so brief that it omits potentially valuable context, balancing efficiency with completeness.

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?

With no output schema or annotations, the description does not explain return format, empty query behavior, or scope of catalog. Incomplete for an agent to use 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 coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond what schema already provides, so baseline 3 is appropriate.

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?

Description clearly states the tool searches for published loops by keyword. It distinguishes from siblings like get_loop_details (specific loop retrieval) and list_categories (listing categories).

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 siblings like get_loop_recommendations or discover_patterns. No explicit when-not or alternative recommendations.

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.

10 tool updatesv1.0.0Jul 4, 2026
- First observedanalyze_loop
- First observedcraft_loop
- First observeddiscover_patterns
- First observedget_loop_details
- First observedget_loop_recommendations
- First observedlist_categories
- First observedload_project_loops
- First observedrun_loop
- First observedsave_loop
- First observedsearch_loops

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, from analyzing loops to running them, with no overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, making them predictable and easy to understand.

Tool Count5/5

With 10 tools, the set is well-scoped for a loop management server, covering creation, execution, analysis, and search without being too many or too few.

Completeness4/5

The tool set covers most lifecycle operations (create, read, execute, search, analyze), though explicit update or delete tools are missing, but these are handled via file editing.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

secureflows-mcp A
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
Workflow A
io.github.Jonnyton
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Autonomous Agents App Automation Workplace & Productivity
21
Agent Router C
io.github.Tim-Projekt
Discover and call AI agents via MCP. Supports A2A agents and platform agents with async tasks.
Agent Orchestration Autonomous Agents
252
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

LM Studio MCP Bridge
AI & Machine Learning RAG Systems
ozwei
F
license
C
quality
D
maintenance
Enables MCP clients to interact with local LLMs via LM Studio, supporting dynamic chat, vision, RAG, file interaction, and model orchestration.
Updated 5 months ago (2026-04-09 00:46 UTC)
28
-
agent-orchestrator
Agent Orchestration Autonomous Agents Developer Tools
vndmea
A
license
Not graded
quality
B
maintenance
Enables multi-model leader-worker agent orchestration, workflow execution, and deterministic validation via structured MCP tools.
Updated 2 months ago (2026-07-06 14:14 UTC)
16
Apache 2.0
Loop Skills MCPofficial
Design Tools Marketing Developer Tools
lendingloop
F
license
Not graded
quality
C
maintenance
Serves Loop's design & brand skills as an MCP server, enabling AI agents to execute on-brand tasks using markdown playbooks and assets.
Updated 2 months ago (2026-07-15 16:32 UTC)
-
llmstudio-mcp
AI & Machine Learning Agent Orchestration
dam2452
F
license
A
quality
C
maintenance
MCP server that connects LLM agents to a local LM Studio instance, enabling model management, OpenAI-compatible chat completions, text completions, and embeddings through a set of tools.
Updated 2 months ago (2026-07-15 17:43 UTC)
9
1
-

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/hotkid61/Loopy-MCP-Server'

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

Loopy MCP Server

What is Loopy?

Why Loopy MCP Server?

Features

Installation

Prerequisites

Setup

Usage

Start the Server

For LM Studio

Available Tools

search_loops

get_loop_recommendations

get_loop_details

analyze_loop

craft_loop

save_loop

load_project_loops

discover_patterns

run_loop

list_categories

File Structure

Examples

Find a loop for your task

Analyze an existing loop

Save and reuse project loops

Run a loop with tracking

How Loops Work

Integration with Forward Future

Features in Detail

Loop Discovery

Loop Adaptation

Loop Execution

Loop Debrief

Publication

Notes

License

Built With

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Loop Skills MCPofficial

Latest Blog Posts

MCP directory API