@first-ch/tools-mcp

Official

by First-CH

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation5/5
Each tool has a uniquely defined purpose—contrast checking, character counting, image conversion, JSON-LD generation, llms.txt generation, and encoding conversion—with no functional overlap.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., contrast_check, webp_convert), making them predictable and easy to understand.
Tool Count5/5
With 6 tools, the server is well-scoped for a utility toolkit, providing a focused yet sufficient set without being sparse or overwhelming.
Completeness3/5
The tools cover several common web development tasks but lack obvious utilities like HTML/CSS validation or sitemap generation, making the set feel somewhat arbitrary.
Average 4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It describes the tool as generating text with no side effects mentioned, but lacks information on permissions, rate limits, or whether the generation is read-only. Adequate but incomplete.
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 concise, fitting into a few sentences with no redundant words. However, it could be slightly more structured (e.g., separating purpose from usage). It earns a 4 for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., the generated text content). It only mentions the output's purpose (placement at /llms.txt) but not the response format. This is a significant gap for a generation tool.
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?
100% of parameters have descriptions in the schema, so the description adds little beyond what the schema already provides. The description restates the free-text nature of parameters but does not add deeper semantics or examples.
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 that the tool generates an llms.txt file following the llmstxt.org proposal, for conveying site overviews to AI/AI search. It also mentions the same logic as an external site, distinguishing it from the unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the generated text should be placed at /llms.txt, but it does not explicitly specify when to use this tool versus alternatives or mention any exclusions. Sibling tools are distinct, so confusion is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses encoder source, default quality, input absolute path requirement, and output location behavior. Lacks details on overwriting behavior, error handling, or other side effects.
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?
Three concise sentences, front-loaded with action, no redundancy. Every sentence adds unique value.
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?
Describes core conversion and basic parameters, but lacks return value specification (no output schema). Adequate for a simple conversion tool but omits details like success/error reporting.
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 coverage is 100%, so description adds limited value beyond schema. It reinforces input path requirement and default output behavior, but does not provide essential additional meaning.
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 converts PNG/JPEG to WebP and saves, with specific encoder details. It is unique among siblings (contrast_check, count_chars, etc.) and distinct in purpose.
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 mentions usage for web image optimization and pre-delivery weight reduction, providing context. Does not explicitly mention when not to use or alternatives, but no similar sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses WCAG 2.1 computation for AA/AAA (normal/large text, UI components). Does not mention edge cases (e.g., alpha, invalid colors) but adequate for a straightforward tool.
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?
Two sentences, zero waste. First sentence defines core functionality, second provides usage context. Well front-loaded.
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, so description should clarify return structure. It says '合否を返す' (returns pass/fail) but not whether it's a boolean or object with details. For a simple tool, it's adequate but could be more precise.
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 baseline is 3. Description reinforces '文字色' and '背景色' but adds little beyond schema. Schema already describes hex format and examples, so minimal added value.
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?
Description clearly states the tool computes WCAG 2.1 contrast ratio and returns pass/fail for AA/AAA standards. Verb '計算する' and resource 'コントラスト比' are specific. Siblings are unrelated (e.g., count_chars, webp_convert), so no confusion.
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?
Description explicitly states use cases: Web design color verification and accessibility checking. No alternatives mentioned, but siblings are semantically distant, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that empty items are automatically omitted from output and that the return value is a JSON object and a <script> snippet. This adds value beyond the input schema, though it could mention safety (read-only) or authentication requirements.
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 composed of four concise sentences, each providing essential information: purpose, supported types, output behavior, and return value structure. No filler or redundancy; it is efficiently front-loaded with critical details.
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?
Given no output schema and no annotations, the description partially compensates by describing the output format and empty omission behavior. However, it lacks usage examples, error handling notes, or explanation of how the 'type' parameter determines which input properties are required. For a tool with nested objects (5 parameters, 1 required), the description could be more 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 100%, so the baseline is 3. The description adds overall context (empty omission, output format) but does not per-parameter details beyond what the schema already provides. No additional semantic clarification for individual parameters is given.
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 it generates schema.org compliant JSON-LD structured data, listing the supported types (organization, faqpage, service, breadcrumb). The verb '生成する' (generate) and resource are specific, and it distinguishes itself from unrelated sibling tools (e.g., contrast_check, webp_convert).
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?
The description lists the four supported schema types, implying when to use this tool (e.g., for generating company info or FAQ structured data). It does not explicitly state when not to use it or provide alternative tools, but sibling tools are dissimilar, so exclusion is not critical. The guidance is clear but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly states that mode=analyze only judges encoding/line endings, while mode=convert returns converted text and base64. This discloses the tool's primary behavioral characteristics without contradictions.
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 a single, well-structured paragraph. It leads with the core purpose, lists concrete use cases, and then explains the modal behavior. Every sentence earns its place with no redundancy.
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?
Given the tool's moderate complexity (6 parameters, no output schema), the description covers the key aspects: purpose, use cases, modes, and return values for convert. It lacks mention of error handling or performance for large files, but these are not critical gaps.
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 coverage is 100%, so baseline is 3. The description adds context about the purpose of the tool and the difference between modes, but it does not add significant parameter-level details beyond what the schema already provides (e.g., enum values, defaults).
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's purpose: detect and convert character encoding (UTF-8, Shift_JIS), BOM, and line endings of CSV/text. It distinguishes itself from sibling tools like contrast_check or webp_convert, which address different tasks.
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?
The description provides concrete usage examples (investigating garbled CSV from clients, preprocessing form data, checking accidental line-ending changes in repositories) and explains the two modes (analyze vs convert). It does not explicitly state when not to use, but the examples are sufficiently contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: returns grapheme count, full/half-width breakdown, line count, and X weight with specific weight rules. Does not cover edge cases like emoji, but is sufficiently transparent for typical use.
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?
Two sentences: first explains functionality with specific outputs, second gives use cases. No wasted words, front-loaded with key information.
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?
Despite no output schema, the description explains the return values adequately for an AI agent to understand the tool's purpose. Usage guidance is provided, and the single parameter makes the tool simple to invoke.
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 coverage is 100%, so the baseline is 3. The description adds context about what the tool outputs but does not elaborate on the 'text' parameter beyond what the schema states. The parameter is simple and self-documenting.
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 counts characters in Japanese text, including grapheme units, full/half-width breakdown, line count, and X weight. It distinguishes itself from sibling tools like contrast_check or webp_convert, which are unrelated utilities.
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 mentions usage for SNS posts and form input validation with character limits. Provides clear context but does not include when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![firstch-tools-mcp MCP server](https://glama.ai/mcp/servers/First-CH/firstch-tools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/First-CH/firstch-tools-mcp)

Score Badge

Copy to your README.md:

[![firstch-tools-mcp MCP server](https://glama.ai/mcp/servers/First-CH/firstch-tools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/First-CH/firstch-tools-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/First-CH/firstch-tools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server