Skip to main content
Glama
paultaki

AI Loop Library MCP

by paultaki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

pick_loop_for_goal

Read-onlyIdempotent

Shortlist matching work loops for a stated goal, with confidence signal, returning candidates and match reasons so you can judge and then render an executable protocol.

Instructions

Shortlist the best-matching loops for a stated goal (lexical ranking with an honest confidence signal) — you make the final call. Returns 5 candidates with use_when, verification, and why-matched so you can judge against operator context the server can't see. When confidence is low, trust your own read of browse_catalog over this ranking. Follow with render_run_protocol for the executable version.

Input Schema

NameRequiredDescriptionDefault
goalYesThe outcome the operator wants, in plain words
limitNo
constraintsNoOptional constraints, e.g. 'read-only', 'no production access'

Output Schema

NameRequiredDescriptionDefault
goalYes
shortlistYes
confidenceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.0
    • addedInput schema / additionalProperties
      Added value: +false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "confidence": {
+      "enum": [
+        "none",
+        "low",
+        "medium",
+        "high"
+      ],
+      "type": "string"
+    },
+    "goal": {
+      "type": "string"
+    },
+    "shortlist": {
+      "items": {
+        "properties": {
+          "category": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "title",
+          "category",
+          "url",
+          "summary"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "goal",
+    "shortlist",
+    "confidence"
+  ],
+  "type": "object"
+}
  2. Addedv2.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds genuinely non-structured behavior: lexical ranking, an honest confidence signal, and a candidate payload of use_when/verification/why-matched. It stops short of rate limits or failure modes, so 4 rather than 5.

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?

Front-loads the verb and resource, then layers the caveat and the follow-up. Dense but every clause carries routing or behavioral information; the em-dash aside is slightly compressed but not wasteful.

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?

Output schema exists, so return values needn't be enumerated, yet the description still tells the agent what the candidates contain and when to distrust the ranking. Nothing needed to call it correctly is missing.

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 67%, so the schema already documents goal, limit, and constraints reasonably. The description clarifies that goal is an operator outcome and that constraints capture operator context the server can't see, but it omits the constraints parameter by name and the configurable limit ('Returns 5 candidates' only reflects the default). Baseline 3 fits.

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?

States a specific verb+resource ('shortlist the best-matching loops') scoped to a stated goal, and distinguishes itself from siblings by naming browse_catalog and render_run_protocol. An agent can tell it apart from search_loops without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the fallback ('When confidence is low, trust your own read of browse_catalog') and the required follow-up ('Follow with render_run_protocol for the executable version'). This is a clear when-to-use plus named alternatives, not mere implication.

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

Deploy Server

Other Tools