Skip to main content
Glama
Sign In

Spaces by Peakflo

by ai.peakflo
OverviewDiscussionsAdmin

skill_list

Read-only

List skills that the agent can read. Use when you need an improvement-recipe for a failing node pattern. Do not use when you need to copy tenant case data into a skill. Next step: call skill_apply for a matching recipe, then workflow_apply_edits. Limits: system skills cannot be changed by an agent. Example: {"kind":"improvement-recipe"}.

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

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum skills to return (1-200). External clients default to 50.
offsetNoSkills to skip, from a previous nextOffset (default 0)
searchNoSearch in name, description, tags
statusNoFilter by status (default: active)
categoryNoFilter by category
includeSystemNoInclude read-only system skills (default: true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Maximum skills to return (1-200). External clients default to 50.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Skills to skip, from a previous nextOffset (default 0)",
+  "minimum": 0,
+  "type": "integer"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description earns credit for adding the governance detail that system skills are read-only and cannot be changed by an agent. It does not describe ordering, pagination traversal, or what a result item looks like, but that is secondary given the safety profile is already covered.

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 dense and front-loaded: purpose first, then when/when-not, then next steps, then limits. The telegraphic, colon-separated style wastes few words, though the trailing example sentence is the least informative part and borders on noise.

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

Completeness4/5

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

For a six-parameter, entirely optional list tool with no output schema, the description covers the purpose, the routing decision, the follow-up chain, and a governance constraint. The only real gap is what a returned skill record contains, which would have been worth one clause given the missing output schema.

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 limit, offset, search, status, category, and includeSystem are already fully documented, making the baseline a 3. The example filter {"kind":"improvement-recipe"} slightly muddies things because no 'kind' property exists in a schema with additionalProperties=false, so it adds ambiguity rather than meaning.

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 ('List skills') plus a scope restriction ('that the agent can read'), which tells an agent exactly what comes back. It partially distinguishes itself from siblings by naming skill_apply as the follow-up for applying a recipe, but never contrasts with skill_get, which also retrieves a single skill.

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?

Gives an explicit when ('when you need an improvement-recipe for a failing node pattern'), an explicit when-not ('Do not use when you need to copy tenant case data into a skill'), and a concrete next-step chain (skill_apply, then workflow_apply_edits). An agent has everything needed to route to or away from this tool.

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

All Spaces by Peakflo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources