Skip to main content
Glama

learn_workflow

Unlocks a stored skill or how-to for the current session so an agent can follow the right workflow; call start_session first for automatic setup.

Instructions

Unlock a skill (how-to) for this session — the OpenPortable gate. Prefer start_session which does this automatically. Day one seed: bootstrap; later: resume-work.

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": {
      "skill": "<skill>"
    },
    "name": "learn_workflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoAlways return full body
localNoOptional local context id for this run
skillYesSkill id stored via update_skill
knownHashNoPrior skillHash — if it matches, body is omitted
session_idNosession_id returned by start_session. If missing/expired, call start_session and follow next_action before retrying.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A3.7/5.0
Behavior3/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 does disclose session scoping ('for this session'), which is real behavioral context. But it says nothing about side effects, idempotency, whether the unlock persists beyond the session, or what happens if the skill id is unknown — gaps that matter for a state-changing tool with zero annotation coverage.

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-loaded with the action and the sibling redirect, three short sentences with no filler. The jargon ('OpenPortable gate', 'Day one seed') makes it slightly less scannable than it could be, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter, session-aware tool with no output schema and no annotations, the description covers the action and the preferred alternative but not the result shape (that a skill body/how-to is returned, conditionally omitted on matching knownHash) or failure modes. Adequate to select the tool, thin for invoking it confidently.

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, but the description adds genuine meaning by giving concrete skill id values ('Day one seed: bootstrap; later: resume-work') where the schema only says 'stored via update_skill'. The force/local/knownHash parameters are left entirely to 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?

States a specific verb and resource ('unlock a skill (how-to) for this session') and names the preferred sibling that subsumes it (start_session). It does not distinguish itself from get_skill, which appears to read the same skill content, so the tool's unique role is only partially clear.

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

Usage Guidelines4/5

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

Explicitly routes the agent away from this tool ('Prefer start_session which does this automatically') and gives day-one vs. later-session guidance on which skill id to pass. It never states the condition under which direct use IS correct (e.g., start_session already ran but a skill was never unlocked), leaving that to inference.

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