Skip to main content
Glama

get_skill

Read-onlyIdempotent

Returns the full script of one workflow: the tools to call, the order to call them in, what to look at in each result, and what to hand back at the end. Read it and then run it yourself with your own tools — these are instructions for you, not a job queued on our side. That is the whole design: the workflow costs the workspace nothing to hand you, and the thinking stays with you. The scripts encode things that are easy to get wrong here and expensive to get wrong twice: that a null figure in a report is missing and not zero, that hours are always logged for the token holder and always land unapproved, that the task hierarchy is a recommendation and never a rule to enforce, and that write steps are proposed to the person first and carried out after they agree. Call list_skills first if you do not know the names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoOptional, for plan_scope: what needs to be accomplished.
nameYesWhich skill to fetch. Call list_skills if you are unsure.
phaseNoOptional, for project_memory: "open" loads the memory at the start of a session, "close" writes back what you learned at the end. Defaults to open.
periodNoOptional, for period_report: the window in plain words, like "last week" or "the last 30 days".
work_dateNoOptional, for log_my_hours: the day the work happened, YYYY-MM-DD.
project_idNoOptional. When you already know the project, the script comes back with it filled in instead of opening with the step that resolves it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds valuable context beyond annotations by stating that this is 'instructions for you, not a job queued on our side' and by revealing domain-specific pitfalls encoded in the scripts, such as null meaning missing and write steps requiring prior approval.

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 description is somewhat long but each sentence earns its place: core purpose, how to use the result, design rationale, encoded pitfalls, and a pointer to list_skills. It is front-loaded with the most important information and has no filler, though it could be tightened slightly.

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 fully explains what is returned: the tools to call, order, what to inspect, and what to hand back. It also covers how to use the result, the read-only nature, and the initial lookup step, making it complete for an agent to invoke correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; it only mentions that list_skills should be called when names are unknown, which is usage guidance rather than parameter semantics.

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 states a specific verb and resource: 'Returns the full script of one workflow' and enumerates exactly what the script contains. It clearly distinguishes itself from sibling tools by emphasizing that this is an executable instruction set for the agent, not a data/document retrieval operation.

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?

It gives clear context: the result is meant to be read and then run by the agent itself, and it explicitly directs the agent to call list_skills first when names are unknown. It does not enumerate explicit when-not-to-use cases, but the purpose and workflow are clear enough to guide selection.

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.