Skip to main content
Glama
Sign In
lightbulb-mcp

lightbulb-mcp

by RPasquale
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_project_learning_runs

Read-onlyIdempotent

Retrieve learning run records for a specified project, including their durable receipt status.

Instructions

Read the Project Training Quest and its durable-run receipts.

This is last-observed receipt state, not live worker telemetry. Only a sanitized Memory execution receipt may show a fenced claim, checkpoint, or terminal runtime result. A result does not prove independent evaluation, learner/model/policy change, business causality, promotion, action, or write authority. Raw Memory lease credentials never belong on MCP.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>"
    },
    "name": "list_project_learning_runs"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
project_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A3.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds significant context beyond that: data is last-observed receipt state, not live telemetry; only sanitized Memory execution receipts may show fenced claims/checkpoints; a result does not prove causality or write authority; and raw lease credentials must never be placed on MCP.

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 opening sentence is a clear, front-loaded statement of the operation and resource. The following caveats are substantive and each carries important behavioral meaning, though the long disclaimer about what a result does not prove is somewhat dense.

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 simple two-parameter read-only list tool with annotations and an output schema, the description covers data freshness, evidential limitations, and a security warning. It does not explain when to choose this over closely related project-learning siblings, but the core calling context is adequately addressed.

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 compensate for the lack of parameter documentation. It does not mention project_id or limit at all, adding no semantic meaning beyond what the parameter names and default already convey.

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 a specific verb ('Read') and a specific resource ('Project Training Quest and its durable-run receipts'), which distinguishes it from evaluation/review sibling tools. It does not explicitly frame the operation as 'listing' all runs despite the tool name, so it falls just short of a 5.

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

Usage Guidelines3/5

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

The description implies use when the agent needs durable-run receipt state for a project, and it usefully contrasts this with live worker telemetry. However, it does not name alternative tools such as list_project_learning_result_evaluations or list_project_learning_reviews, nor does it state when not to use this tool.

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