Skip to main content
Glama

List learning candidates

swarm_list_learning_candidates
Read-onlyIdempotent

Review learning candidates before reusing proposed knowledge. Omit status for all lifecycle states; combine it with family to narrow results. Inspect acceptance evidence with swarm_list_promotion_gates. Use swarm_list_learning_queue for pending work. Listing never promotes knowledge.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "swarm_list_learning_candidates"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size; follow next_cursor for more.
orderNoasc or desc; retain the same order across pages.
cursorNoPrevious next_cursor; keep filters and order.
familyNoExisting knowledge-family key filter.
statusNoStatus filter; use values returned for this resource.
space_idNoSpace ID from swarm_list_spaces; omit if sole.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / cursor / description
      Previous value: -"Previous next_cursor; same filters and order."New value: +"Previous next_cursor; keep filters and order."
    • addedInput schema / properties / family / description
      Added value: +"Existing knowledge-family key filter."
    • changedInput schema / properties / limit / description
      Previous value: -"Page size."New value: +"Page size; follow next_cursor for more."
    • changedInput schema / properties / order / description
      Previous value: -"Paging order."New value: +"asc or desc; retain the same order across pages."
    • changedInput schema / properties / space_id / description
      Previous value: -"Omit for a single approved Space."New value: +"Space ID from swarm_list_spaces; omit if sole."
    • addedInput schema / properties / status / description
      Added value: +"Status filter; use values returned for this resource."
  2. Changed4 schema fields changed
    • addedInput schema / properties / cursor / description
      Added value: +"Previous next_cursor; same filters and order."
    • addedInput schema / properties / limit / description
      Added value: +"Page size."
    • addedInput schema / properties / order / description
      Added value: +"Paging order."
    • addedInput schema / properties / space_id / description
      Added value: +"Omit for a single approved Space."
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral guarantee beyond them — 'Listing never promotes knowledge' — which reassures an agent this is non-mutating with respect to knowledge state. It stops short of describing pagination behavior, but the schema covers that.

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?

Four short sentences, front-loaded with purpose and followed by filtering rules, sibling routing, and the non-mutation guarantee. No redundancy with the schema or annotations.

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?

For a six-parameter, fully documented, output-schema-backed read tool with annotations, the description covers purpose, filtering, and sibling routing adequately. Return-value and pagination details are correctly left to the schema/output schema, leaving only minor room for extra context.

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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining that an omitted status returns all lifecycle states and that status can be combined with family to narrow results — filter interaction semantics the schema does not state.

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 concrete resource and intent ('Review learning candidates before reusing proposed knowledge'), and the name supplies the list verb. It clearly separates itself from swarm_list_learning_queue and swarm_list_promotion_gates, though the first sentence frames the goal (review) rather than the operation (listing) itself.

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?

Explicit routing rules: omit status to get all lifecycle states, combine with family to narrow, use swarm_list_promotion_gates for acceptance evidence, and swarm_list_learning_queue for pending work. Each alternative names the condition that selects it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.