Skip to main content
Glama

get_learning_metrics

Retrieve learning-outcome indicators for a session, covering immediate performance, delayed retention, transfer, attempts, hint dependency, misconception resolution, confidence calibration, and learning gain.

Instructions

Return the section 26.1 learning-outcome indicators.

Covers Immediate Performance, Delayed Retention, Transfer Performance, Time/Attempts to Target Evidence, Hint Dependency, Misconception Resolution, Confidence Calibration and Learning Gain.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It only says 'Return' and lists metric names; it does not disclose whether this is a pure read, whether the session must be completed, whether metrics are computed on demand, or what the response shape is. This is minimal behavioral context.

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 two sentences with no filler. The main action is front-loaded, and the list of covered indicators is compact and helpful.

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 tool has no output schema and no annotations, so the description should provide more context about return structure, parameter semantics, and usage conditions. An agent can guess the purpose but not confidently decide when to call this over a sibling or what to expect in the response.

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%, and the description never mentions session_id or explains its meaning or required format. The only parameter is self-evident from its name, but the description adds no value beyond the schema.

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 ('Return') and resource ('section 26.1 learning-outcome indicators') and enumerates the included indicator categories, which helps distinguish it from siblings like get_mastery_status or get_assessment_history. It does not explicitly name a sibling, so it is clear but not fully differentiated.

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?

There is no explicit when-to-use or when-not-to-use guidance. The description implies the tool is for retrieving learning-outcome indicators, but it does not mention prerequisites, what session state is required, or how it differs from related tools such as get_mastery_status or get_assessment_history.

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