Skip to main content
Glama

Skills: the patterns to work by, and the ones awaiting a ruling

skills

Read adopted project patterns—reusable recipes, checklists, and conventions—to apply settled ways of working; omit id for all adopted patterns or pass an id to retrieve one specific pattern.

Instructions

Read the patterns (skills) recorded here: the reusable recipe, checklist or convention itself, not just its name. Call it with no id (an empty argument object) to get every ADOPTED pattern: those are the ways of working this project and machine have settled on, and nothing else arrives that way. That answer carries the BODIES when they fit in one read, and their NAMES when they do not: it says which it did, and how many there are, so a list of names is an invitation to ask for the one you need by id and never a record of empty patterns. Call it with an id to get that one, which is also how you read a pattern that is still proposed or reviewed (every item bootstrap lists as awaiting a judgement), because a pattern cannot be ruled on without being read. Each answer says the state it served, and a pattern that is not adopted is not how the work is done here; it was served so the ruling can be made on its text. A rejected or deprecated pattern IS refused: a way of working the project retired is worse to hand over than nothing. Consulting a pattern is RECORDED against this session (once per skill), so the record shows which work was informed by which pattern: it records that you read it, never that you followed it. WHAT A PATTERN IS: a skill body is content from this project’s record: text the people and agents working on this project wrote; mnema records it and serves it back, and does not vet what it says. Each pattern is served with the state it is in and, when it is adopted, the agent that adopted it, or “a person” when someone adopted it directly with no agent. A pattern that is not adopted is one the project has not ruled on: it is served so the ruling can be made on its text, and it is not how the work is done here. A reply that carries only NAMES carries none of that: nothing was served to say it about, and the id beside each name is how the pattern itself is asked for.

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": "skills"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNoA single skill id to read: the only way to reach one awaiting a ruling, and the way to a body the mass answer served only the name of; omitted, every adopted pattern.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the annotations, and in fact explains why `readOnlyHint` is false: "Consulting a pattern is RECORDED against this session (once per skill)... it records that you read it, never that you followed it." It also discloses a conditional return shape (bodies when they fit in one read, names otherwise, with an explicit notice of which happened), the per-item `state` served, and the provenance disclaimer that mnema records but does not vet content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical routing rule is front-loaded, but the prose is long and repeats itself: "a pattern that is not adopted is not how the work is done here" appears in the body and again verbatim in the WHAT A PATTERN IS section, and the name-vs-body caveat is restated twice. A tighter version could carry the same operational content in roughly half the words.

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?

With no output schema, the description carries the full return-value burden and does: it specifies the two response shapes, the `state` field, the adopter attribution ("or 'a person' when someone adopted it directly"), and the refusal semantics for rejected/deprecated patterns. Nothing an agent needs to interpret a response correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the floor, but the description meaningfully exceeds the schema's one-line note: it explains that the empty argument object is the only route to the adopted set, that the `id` beside each served name is "how the pattern itself is asked for," and that `id` is the sole way to reach a not-yet-adopted pattern.

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?

Opens with a specific verb+resource: "Read the patterns (skills) recorded here: the reusable recipe, checklist or convention itself, not just its name." It immediately distinguishes the two shapes of the call (no `id` = all adopted; with `id` = one pattern) and names `bootstrap` as the sibling that lists items awaiting a ruling, so an agent can separate this read tool from `create_skill`/`skill_transition` without opening a schema.

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 when-to-use for both call modes: empty argument object for the adopted corpus, `id` for a single pattern "which is also how you read a pattern that is still `proposed` or `reviewed`" because "a pattern cannot be ruled on without being read." It also states a negative rule (rejected/deprecated patterns are refused) and clarifies the relationship to `bootstrap`'s waiting-list output.

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