Skip to main content
Glama

Get My Learning Path

me.learning_path
Read-onlyIdempotent

Authenticated: returns the caller's Blueprint learning-path state: current course slug, stage progress, certification status (Foundation, Practitioner, Capstone), Capstone track eligibility flags, and the next recommended stage. WHEN TO CALL: the user asks 'where am I', 'what's next', or 'am I Capstone-eligible'; before suggesting next-step coaching content. WHEN NOT TO CALL: as a heartbeat (state changes only when the user completes a stage); to read another user's progress. BEHAVIOR: read-only, idempotent. Auth: Bearer (any plan, including basic). Returns user_email, course_slug, stages list with completion timestamps, certification block, and a next_stage hint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "get_my_learning_pathDictOutput",
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "$defs": {
      -    "ErrorBody": {
      -      "description": "The body of `error_payload(code, message, details)` returns.",
      -      "properties": {
      -        "code": {
      -          "title": "Code",
      -          "type": "string"
      -        },
      -        "details": {
      -          "additionalProperties": true,
      -          "title": "Details",
      -          "type": "object"
      -        },
      -        "message": {
      -          "title": "Message",
      -          "type": "string"
      -        }
      -      },
      -      "title": "ErrorBody",
      -      "type": "object"
      -    }
      -  },
      -  "properties": {
      -    "error": {
      -      "$ref": "#/$defs/ErrorBody",
      -      "default": null
      -    },
      -    "next_step": {
      -      "anyOf": [
      -        {
      -          "additionalProperties": true,
      -          "type": "object"
      -        },
      -        {
      -          "type": "null"
      -        }
      -      ],
      -      "default": null,
      -      "title": "Next Step"
      -    },
      -    "plan": {
      -      "default": null,
      -      "title": "Plan",
      -      "type": "string"
      -    },
      -    "recommendations": {
      -      "default": null,
      -      "items": {
      -        "additionalProperties": true,
      -        "type": "object"
      -      },
      -      "title": "Recommendations",
      -      "type": "array"
      -    },
      -    "user_id": {
      -      "default": null,
      -      "title": "User Id",
      -      "type": "string"
      -    }
      -  },
      -  "title": "MeLearningPathResponse",
      -  "type": "object"
      -}New value: +null
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$defs": {
      +    "ErrorBody": {
      +      "description": "The body of `error_payload(code, message, details)` returns.",
      +      "properties": {
      +        "code": {
      +          "title": "Code",
      +          "type": "string"
      +        },
      +        "details": {
      +          "additionalProperties": true,
      +          "title": "Details",
      +          "type": "object"
      +        },
      +        "message": {
      +          "title": "Message",
      +          "type": "string"
      +        }
      +      },
      +      "title": "ErrorBody",
      +      "type": "object"
      +    }
      +  },
      +  "properties": {
      +    "error": {
      +      "$ref": "#/$defs/ErrorBody",
      +      "default": null
      +    },
      +    "next_step": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": true,
      +          "type": "object"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "title": "Next Step"
      +    },
      +    "plan": {
      +      "default": null,
      +      "title": "Plan",
      +      "type": "string"
      +    },
      +    "recommendations": {
      +      "default": null,
      +      "items": {
      +        "additionalProperties": true,
      +        "type": "object"
      +      },
      +      "title": "Recommendations",
      +      "type": "array"
      +    },
      +    "user_id": {
      +      "default": null,
      +      "title": "User Id",
      +      "type": "string"
      +    }
      +  },
      +  "title": "MeLearningPathResponse",
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces these while adding valuable context beyond annotations: auth requirement ('Bearer <token>'), plan availability ('any plan, including basic'), and the state-change semantics ('state changes only when the user completes a stage'). This fully discloses the operational behavior an agent needs.

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 front-loaded with the core purpose, then organized into clear WHEN TO CALL, WHEN NOT TO CALL, BEHAVIOR, and Auth sections. Every sentence adds operational value, and the structure makes it easy for an agent to scan and extract the relevant decision criteria.

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?

For a zero-parameter, read-only tool with an output schema, the description is fully complete: it covers auth, scope, return fields, eligibility semantics, usage timing, and exclusions. There are no missing details an agent would need to invoke this tool correctly.

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 input schema has zero parameters, so there is no parameter semantics to document. The description correctly focuses on the returned state rather than inputs, and the 100% schema description coverage means nothing is left undocumented. Baseline 4 is appropriate for a zero-parameter tool.

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 opens with a specific verb and resource: 'returns the caller's Blueprint learning-path state' and enumerates the exact data returned (current course slug, stage progress, certification status, Capstone eligibility, next recommended stage). It also clearly scopes the tool to the caller's own path, distinguishing it from any tool that might read another user's progress.

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?

The description provides explicit WHEN TO CALL triggers ('where am I', 'what's next', 'am I Capstone-eligible') and equally explicit WHEN NOT TO CALL exclusions (not a heartbeat, not for reading another user's progress). This gives an agent unambiguous decision rules with no need to infer usage.

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.

Resources