SKILL.md Lint by Moltline

Lint Skill

lint_skill

Read-onlyIdempotent

Lint one SKILL.md file the way marketplaces and agents parse it. FREE.

Checks YAML frontmatter presence and required fields (name, description), description quality, body structure (procedure steps, rules, degradation), secret/credential leakage, injection-style phrasing, and size budget. Typical input {"content": ""} returns {"verdict": "pass" | "pass-with-warnings" | "fail", "errors": ["..."], "warnings": ["..."], "stats": {"body_words": N, "has_frontmatter": bool}}.

Use on the full text of one SKILL.md. Not for the surrounding archive layout (packaging_check). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "content is empty — pass the full SKILL.md text including frontmatter"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`content`	Yes	The complete SKILL.md file text, frontmatter included; must be non-empty.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as true, false, false respectively. The description reinforces this by stating 'Every call is read-only and idempotent' and explicitly describes error-returning behavior instead of protocol errors. It adds detail about how errors are returned as structured JSON with fix instructions.

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

Conciseness5/5

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

The description is efficiently structured: a one-liner purpose, bulleted checklist of lint operations, typical input/output format, usage note, and error behavior. Every sentence serves a clear purpose without redundancy.

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?

Given the tool has an output schema (handling return values), the description covers all needed context: input format, use case boundaries, error handling, and safety guarantees. It is fully complete for a lint tool with good annotations.

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% with a clear description for the single 'content' parameter. The description adds value by explaining the input format ('full SKILL.md text including frontmatter') and typical retrieval from the tool's response, which slightly exceeds what the schema provides.

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 clearly states the tool lints one SKILL.md file, contrasting it with the sibling 'packaging_check' tool for archive layout. It specifies the exact checks performed (YAML frontmatter, required fields, description quality, etc.), making the purpose unambiguous.

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?

The description explicitly says 'Use on the full text of one SKILL.md. Not for the surrounding archive layout (packaging_check).' It provides typical input/output examples and error behavior, including that it is safe to retry after correcting input. This gives clear when-to-use and when-not-to-use guidance.

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

All SKILL.md Lint by Moltline tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool addresses a distinct concern: cron expressions, text diffs, JSON validation, SKILL.md linting, zip packaging, and regex testing. There is no overlap in purpose or output, so an agent can unambiguously select the right tool for a given task.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (cron_explain, diff_texts, json_validate, lint_skill, packaging_check, regex_test). The pattern is uniform and predictable, making the API easy to navigate.

Tool Count5/5

Six tools is well within the ideal 3-15 range for a focused server. Each tool serves a clear purpose, and the count feels neither bloated nor sparse for a linting and validation toolkit.

Completeness4/5

The core domain of validating SKILL.md files is well covered by lint_skill and packaging_check, and the generic utilities (cron, diff, JSON, regex) support auxiliary validation needs. A minor gap is the lack of a tool to fetch or write files directly, but the read-only linting workflow is complete.

Resources

Need Help?