Skip to main content
Glama
Sign In

skillcheck

by io.github.Noem836
OverviewDiscussionsAdmin

preflight_skill

Read-only

Call BEFORE installing a skill or skill pack from GitHub. Pass the repo and the skills the user already has (name + description, e.g. from your own skill listing). Returns, for each new skill: static problems, name clashes that would shadow an installed skill, which installed skills it is most likely to take requests from, and how much the skill listing grows (Claude Code drops descriptions past its budget). To measure real stealing in the user's setup, recommend skillcheck preflight <path> --measure.

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": {
      "github_url": "<github_url>",
      "installed": "<installed>"
    },
    "name": "preflight_skill"
  }
}

Input Schema

NameRequiredDescriptionDefault
installedYesskills already installed
github_urlYeshttps://github.com/<owner>/<repo> of the skill(s) to install

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish readOnlyHint and openWorldHint, so the bar is lower; the description still adds real context — it enumerates the exact outputs and warns that Claude Code drops descriptions past its budget, which explains why the growth metric matters. It could be stronger on what network access openWorldHint implies, but the added signal is substantive.

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 timing constraint and then the return payload; both the imperative and the output list earn their space. It is dense but not padded, though the final CLI-measurement sentence is arguably a separate concern.

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 read-only analysis tool with no output schema, the description conveys the return contents and the reasoning behind the listing-growth metric, which is what an agent needs to act on results. The only omission is the installed-array size limit and nothing about network/rate behavior for fetching a GitHub repo.

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, and the description adds genuine value by telling the agent where to source the `installed` array ('from your own skill listing') with name + description per entry. It does not mention the 80-item cap on that array, which is left 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: a pre-install check of skills from a GitHub repo, including what it returns (static problems, name clashes, likely request stealing, listing growth). It never mentions or distinguishes itself from the sibling check_skill_repo, so an agent can't tell the two apart with confidence.

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 says when to call it ('BEFORE installing a skill or skill pack from GitHub') and points to an alternative path for measurement (`skillcheck preflight <path> --measure`). It stops short of saying when NOT to use it or how it differs from check_skill_repo.

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

All skillcheck toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources