Hosted MCP server to lint SKILL.md files: packaging checks, regex tests, JSON validation, diffs.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 6 of 6 tools scored.
Each tool targets a unique resource/action: cron expressions, text diffs, JSON validation, SKILL.md linting, packaging layout, and regex testing. There is no overlap in purpose, so an agent can easily select the right tool.
All names use lowercase with underscores, but the verb position is inconsistent: cron_explain, json_validate, packaging_check, and regex_test are noun-first, while diff_texts and lint_skill are verb-first. This mixed pattern makes the convention less predictable.
Six tools is within the ideal range for a utility server, but four of them are generic helpers (cron, diff, json, regex) that could belong to a separate toolkit. The count is reasonable, though slightly unfocused for a dedicated SKILL.md linting server.
The core linting workflows are covered (lint_skill, packaging_check), and the generic tools support related activities like comparing versions, testing regex rules, and interpreting cron fields. A dedicated YAML validator is missing (json_validate only handles JSON), but this is a minor gap.
cron_explainCron ExplainAExplain a 5-field cron expression in plain English and flag mistakes. FREE.
Typical input {"expression": "0 9 * * 1-5"} returns {"expression": "0 9 * * 1-5", "meaning": "at minute 0; at hour 9; every day of month; every month; day of week 1-5", "issues": ["none"]}; out-of-range fields are listed in "issues". Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "expected 5 fields, got "}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | A standard 5-field cron string (minute hour day-of-month month day-of-week), e.g. "0 9 * * 1-5"; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is pre-covered. The description adds valuable behavioral context beyond that: it clarifies that the tool never raises protocol errors but instead returns a structured error object, and it details what 'issues' contains. The note 'read-only and idempotent... safe to retry' reinforces but does not contradict the annotations. This goes beyond a bare repeat of annotation data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, then a concrete example, error behavior, and a safety note. Most sentences earn their place, but the standalone 'FREE.' is extraneous to the tool's operation and does not help the agent invoke it. This minor fluff prevents a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only tool, the description is complete: it covers expected input, example output, the meaning of the 'issues' field, error handling, and the read-only/idempotent nature. The presence of an output schema means return values are already structured, so the description does not need to explain them further. No gaps remain for an agent to successfully select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter with 100% coverage, so the baseline is 3. The description exceeds that baseline by providing a concrete example of a valid expression, the exact output shape, and how errors are represented. This adds real semantic meaning that helps an agent construct valid input and interpret responses, moving the score to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Explain a 5-field cron expression in plain English and flag mistakes.' This clearly distinguishes the tool from siblings like json_validate or regex_test, which handle different formats. The purpose is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by showing a typical input and what output to expect, and the sibling list makes it clear this is the cron-specific tool. However, it does not explicitly state when NOT to use it or name alternative tools, so it falls just short of a 5. The provided example and error-handling details give enough guidance for an agent to know when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diff_textsDiff TextsAProduce a unified diff between two texts. FREE.
Useful for comparing two SKILL.md versions. Typical input {"a": "", "b": ""} returns {"changed_lines": N, "diff": "--- \n+++ \n@@ ... @@\n-old line\n+new line"}; identical inputs return {"changed_lines": 0, "diff": "(identical)"}. The diff is capped at 400 lines. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "each text must be at most 500000 characters"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | The original text (left side of the diff); at most 500000 characters. | |
| b | Yes | The revised text (right side of the diff); at most 500000 characters. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that the diff is capped at 400 lines, that errors return an error object rather than raising a protocol error, and that every call is read-only and idempotent. It explains the exact error format and provides an example, giving the agent a thorough understanding of the tool's behavior in all cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the purpose and FREE tag, followed by usage, output examples, limits, and error handling. Each sentence adds useful information, though the 'FREE.' is slightly extraneous. It is compact but comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's return value (including identical-input case), truncation limit, error responses, and retry safety. Given the output schema exists and the tool is simple, this description leaves no gaps for an agent to misuse the tool. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides detailed descriptions for both parameters (original text vs revised text, max length 500000). The description adds a typical input example but doesn't introduce new semantics beyond what the schema already states. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Produce a unified diff between two texts' with a specific verb and resource, and it distinguishes itself from sibling tools by its function. It also gives a concrete use case (comparing SKILL.md versions) that adds clarity. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful for comparing two SKILL.md versions' and provides a typical input example, which gives clear context for when to use. It does not explicitly mention when not to use or name alternatives, but its use case is distinct enough that no exclusions are necessary. The guidance is clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
json_validateJson ValidateAValidate JSON text and summarize its structure. FREE.
Typical input {"text": "{"a": [1, 2]}"} returns {"valid": true, "structure": {"a": ["array[2]", "int"]}}; invalid JSON returns {"valid": false, "error": "", "line": N, "column": N} instead. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "text is empty — pass the JSON document as a raw string"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The JSON document to validate, as a raw string; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral detail beyond annotations: the tool never raises a protocol error; it returns an error object with a fix hint. It also documents the distinct return shapes for valid vs. invalid JSON, which is not captured by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. It packs a typical usage example, valid/invalid return shapes, error behavior, and safety guarantees into three sentences. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter, an output schema is present, and annotations cover safety. The description fully covers input format, output shapes for valid and invalid cases, error handling, and idempotency/retry safety. This is complete guidance for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, so the schema already documents that 'text' must be a non-empty raw string. The description adds a concrete example of how to pass the parameter ('Typical input {"text": "{\"a\": [1, 2]}"}') and reiterates the raw-string expectation in the error message. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Validate JSON text and summarize its structure.' This clearly distinguishes it from all sibling tools (cron_explain, diff_texts, lint_skill, packaging_check, regex_test), none of which perform JSON validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case via its purpose ('Validate JSON text') and adds retry guidance ('after correcting the input it is always safe to retry'). It does not name alternatives, but the sibling tools are so dissimilar that no exclusion is necessary. Clear context is provided, though no explicit when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lint_skillLint SkillALint 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}}. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The complete SKILL.md file text, frontmatter included; must be non-empty. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint and idempotentHint, the description adds substantial behavioral context: it guarantees 'never raises a protocol error' and returns a structured error object instead, explains the idempotent/retry-safety behavior, and notes the tool is free. These details go well beyond the annotation hints and help an agent anticipate edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, check list, input/output example, error behavior, and safety note. It is front-loaded with the core purpose and avoids redundancy with the schema/annotations. The mention of 'FREE' is a concise cost signal. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and rich annotations, the description is fully complete: it explains what the tool does, what inputs to pass, what outputs to expect (both success and error cases), and the safety semantics. The output schema is also effectively summarized in text, so an agent can invoke and interpret results without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'content' parameter completely (100% coverage), so baseline is 3. The description goes further by showing a 'Typical input' example and explaining how invalid input is handled, adding practical meaning beyond the schema's bare description. It does not repeat the schema verbatim but enhances it with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Lint one SKILL.md file the way marketplaces and agents parse it.' It comprehensively lists what the lint checks cover (frontmatter, body structure, secrets leakage, injection phrasing, size budget), clearly distinguishing it from sibling tools like json_validate or packaging_check. The purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what input to provide ('the complete SKILL.md file text, frontmatter included') and the expected output shape, giving an agent solid context for when to invoke it. It does not explicitly name alternatives or provide exclusion criteria, but the tool's specific scope (SKILL.md linting) is evident, so the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
packaging_checkPackaging CheckAValidate a zip layout plan for a skill marketplace before packaging. FREE.
Checks SKILL.md placement rules and flags junk files. Typical input {"file_paths": ["my-skill/SKILL.md", "my-skill/examples.md"], "marketplace": "agensi"} returns {"verdict": "pass" | "fail", "issues": ["..."], "skill_files_found": ["my-skill/SKILL.md"]}. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "file_paths is empty — list every file that will be inside the zip"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| file_paths | Yes | Every file path that will be inside the zip, relative to the zip root, e.g. ["my-skill/SKILL.md"]; at least 1 entry. | |
| marketplace | No | Rule set to apply: "agensi" (SKILL.md at root or one folder deep) or "generic" (junk-file checks only). Default "agensi". | agensi |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds crucial behavioral details: it never raises protocol errors but returns an error object with fix guidance, and it is explicitly read-only and idempotent, making retries safe. These traits are not fully captured by the annotations alone and significantly aid the agent in anticipating edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but packed with useful information: purpose, example, error behavior, and safety. It is front-loaded with the main purpose. Minor extraneous content like 'FREE' could be trimmed, but overall each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's complexity: it states what it does, when to use it, input/output format, error handling, and retry safety. Even though an output schema exists but is not shown, the description explicitly details the return fields (verdict, issues, skill_files_found) and error shape, making the tool's behavior fully predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with descriptions, so baseline is 3. The description adds value by showing a concrete example of how file_paths and marketplace work together, including output mapping. It also clarifies error scenarios (e.g., empty file_paths) that directly relate to parameter usage, exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Validate a zip layout plan for a skill marketplace before packaging.' It clearly distinguishes from siblings (e.g., lint_skill, json_validate) by focusing on SKILL.md placement and junk-file checks. The purpose is unambiguous and directly actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'before packaging' provides clear context for when to use the tool. It does not explicitly name alternatives or exclusions, but the sibling tools serve different functions (e.g., regex_test, cron_explain), so the usage context is sufficient. The description also includes a typical input/output example, reinforcing the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
regex_testRegex TestATest a regular expression against sample strings. FREE.
Typical input {"pattern": "v(\d+)", "samples": ["v12", "beta"]} returns {"pattern": ..., "results": [{"sample": "v12", "match": true, "matched_text": "v12", "groups": ["12"]}, {"sample": "beta", "match": false, ...}], "match_count": 1}. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "invalid regex: "}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | A Python-flavor regular expression as a string, e.g. "v(\\d+)". | |
| samples | Yes | Strings to test the pattern against; only the first 50 are evaluated. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral context: it never raises protocol errors, returns a structured error object with fix suggestions, and is always safe to retry after correcting input. This goes beyond the annotation hints and informs the agent of the tool's error-handling model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose and contains useful sections: example, error behavior, and safety note. However, the stray 'FREE.' adds no value and the example is somewhat verbose, though informative. Overall it is well-structured with minimal fluff, but the 'FREE.' prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema and safety annotations, the description is highly complete. It covers purpose, input/output structure, error behavior, retry safety, and idempotency. The error-handling and retry notes are particularly important for an agent interacting with the tool. The output schema handles return values, so no further description is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description includes a typical input example ('pattern': 'v(\\d+)', 'samples': ['v12', 'beta']) which demonstrates usage but does not add meaning beyond what the schema already provides. The schema already documents the semantics of pattern and samples, including the 'first 50' limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Test a regular expression against sample strings.' This clearly distinguishes regex_test from sibling tools like json_validate or lint_skill by focusing on regex testing. The typical input/output example further reinforces the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose but does not explicitly state when to use it over alternatives or provide exclusions. There is no mention of when not to use this tool, such as for validation of other formats. The context is clear but not as explicit as the 4 or 5 scale requires.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
