Skip to main content
Glama
Sign In
Skill Quality MCP

Skill Quality MCP

by LoveMuZiLi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

inspect_skill

Read-only

Validates an Agent Skill's structure by checking frontmatter, body length, broken links/anchors, and referenced files to catch documentation defects before use.

Instructions

检查一个 Agent Skill 的结构：frontmatter、正文长度、失效链接/锚点、文中引用的文件。skill：技能名或路径。

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

Input Schema

NameRequiredDescriptionDefault
skillYes
detailNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.0

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality are covered. The description adds what gets examined but says nothing about output shape, error behavior for missing skills, or how 'detail' changes results. Adequate but thin for a multi-check inspection tool.

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?

One front-loaded sentence with the verb first, then a compact parameter note. Every clause earns its place by naming a concrete check; minor run-on but no filler.

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?

No output schema exists, so the description should help an agent anticipate results, yet it never says what the inspection returns or how `detail` affects verbosity. For a read-only checker with only two parameters, this is minimum viable rather than complete.

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 0%, so the description must compensate. It meaningfully explains the required `skill` parameter as a name or path, but the optional `detail` boolean is left entirely undefined in both schema and description, leaving an unresolved gap.

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?

The description opens with a specific verb (检查/inspect) and resource (Agent Skill 的结构), then enumerates exactly what is examined: frontmatter, body length, broken links/anchors, and referenced files. This clearly separates it from list_skills, though the sibling is never named explicitly.

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

Usage Guidelines2/5

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

Usage is only implied by the checked aspects; there is no statement of when to call this versus list_skills or analyze_dependencies, nor any prerequisites (e.g., skill must exist locally). The trailing 'skill：技能名或路径' is parameter guidance, not usage guidance.

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

Deploy Server

Other Tools