@first-ch/tools-mcp
OfficialThis MCP server exposes First CH Tools' web-tool logic as AI-agent-callable tools for web development, accessibility, content, and document tasks.
contrast_check: Calculate WCAG 2.1 contrast ratios and check AA/AAA compliance for text and UI components.count_chars: Count Japanese text (graphemes), break down into full/half-width, count lines, and compute X (Twitter) post weight (zenkaku=2, hankaku=1, URL=23, limit 280).webp_convert: Convert PNG/JPEG images (absolute paths) to WebP using libwebp WASM (default quality 80), optionally specifying output directory.jsonld_generate: Generate schema.org JSON-LD for types: organization, FAQPage, service, breadcrumb, with empty fields omitted; returns both JSON and a script snippet.llmstxt_generate: Generate an llms.txt file per the llmstxt.org format, summarizing a site for AI crawlers/agents.encoding_convert: Detect character encoding (UTF-8/Shift_JIS), BOM, and line endings (CRLF/LF/CR); convert to UTF-8 (analyze or convert mode; Unicode output only).marp_render: Render Marp Markdown to slides, producing a self-contained HTML (one slide per page) and optionally PDF (requires local Chrome/Chromium; falls back to HTML-only with pdf_skipped).
Converts JPEG images to WebP format using libwebp, with configurable quality and output directory.
Renders Marp Markdown to self-contained HTML slide decks and optionally PDF, with support for custom themes.
Encodes SVG files as Base64 or percent-encoded data URIs for direct embedding in HTML and CSS, selecting the shorter form.
Converts YAML to JSON and JSON to YAML, enabling bidirectional data transformation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@@first-ch/tools-mcpCheck WCAG contrast for #333 on #fff"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@first-ch/tools-mcp
MCP server exposing First CH Tools' free web-tool logic — WCAG contrast, JP character/X-weight counting, WebP conversion, JSON-LD generation, llms.txt generation, encoding/line-ending conversion, Marp Markdown→slide rendering, Japanese/English test-data generation, text/code diffing, cron-expression explanation, Base64/data-URI encoding, URL query-parameter editing, HTML entity escaping/unescaping, JSON⇄YAML conversion, px ⇄ rem/em unit conversion, colour-code conversion with alpha compositing, MD5/SHA-1/SHA-256/SHA-384/SHA-512 hashing, JWT decoding with expiry and signature checks, User-Agent parsing with device/bot detection, bulk UUID v4 / ULID generation, aspect-ratio calculation with responsive sizing, case conversion between camelCase, snake_case and kebab-case, and CSV/TSV ⇄ JSON conversion — to AI agents such as Claude Code.
日本語版は 後半セクション を参照してください。
Install
Three ways to add this server, pick whichever fits your client.
Requires Node.js >=18.14.1 (all three methods below run the server via npx, so Node must be installed even when the MCP client itself — e.g. Claude Code's native, no-Node install — doesn't strictly require it).
1. npm, via the Claude Code CLI
claude mcp add firstch-tools -- npx -y @first-ch/tools-mcp2. Claude Code plugin (also installs the same MCP server)
/plugin marketplace add First-CH/firstch-tools-mcp
/plugin install firstch-tools@first-ch3. Any other MCP client (generic JSON config)
Add to your client's server config (e.g. mcp.json / claude_desktop_config.json):
{
"mcpServers": {
"firstch-tools": {
"command": "npx",
"args": ["-y", "@first-ch/tools-mcp"]
}
}
}This server is also registered in the MCP Registry as io.github.First-CH/tools-mcp (see server.json), so registry-aware clients can discover and install it by that name too.
Related MCP server: OpenAI-Compatible MCP Gateway
Tools
Tool | What it does | Main input |
| Computes the WCAG 2.1 contrast ratio between a foreground and background color and returns AA/AAA pass/fail (normal text, large text, UI components) |
|
| Counts Japanese text by grapheme, breaks it down into zenkaku/hankaku, counts lines, and computes the X (Twitter) post weight (zenkaku=2, hankaku=1, URL=23 flat, limit 280) |
|
| Converts PNG/JPEG files (absolute paths) to WebP using the same libwebp WASM encoder (default quality 80) as the browser tool at tools.first-ch.com/webp/. Output defaults to the same directory as each input with a |
|
| Generates schema.org JSON-LD for |
|
| Generates an |
|
| Detects the character encoding (UTF-8 / Shift_JIS), BOM and line endings (CRLF / LF / CR) of a file or text and converts it to UTF-8. Useful for diagnosing garbled Japanese CSVs and for normalising line endings. Output is UTF-8 only — encoding to Shift_JIS is not supported (no standard API, and a mapping table would be required). |
|
| Renders Marp Markdown to slides. Emits a self-contained HTML file (theme CSS inlined; opens in a browser and prints one-slide-per-page) and optionally PDF. Ships a bundled Japanese theme |
|
| Generates dummy data for form / CSV-import testing. |
|
| Compares two texts (or two files) and returns the added/removed/changed line counts plus a unified diff ( |
|
| Explains a cron expression in plain language and returns the upcoming run times — the same logic as the browser tool at tools.first-ch.com/cron/. Parsing follows Vixie cron ( |
|
| Encodes text or a file as Base64 and a |
|
| Breaks a URL's query string into keys and values, edits it ( |
|
| Escapes |
|
| Converts JSON to formatted YAML, and |
|
| Converts YAML to JSON — useful for turning docker-compose, GitHub Actions, Kubernetes and CI config into something a program can handle, and for checking that a file parses at all. A syntax error is returned as an error naming the line, the column, the cause and the fix, with the two surrounding lines quoted and a |
|
| Converts CSS lengths between px, rem, em and pt — the same logic as the browser tool at tools.first-ch.com/px-rem/. Pass |
|
| Converts a colour between HEX, RGB, HSL and OKLCH and builds the |
|
| Computes the MD5, SHA-1, SHA-256, SHA-384 and SHA-512 digests of a string or a file in one call — the same logic as the browser tool at tools.first-ch.com/hash/. Pass |
|
| Decodes a JWT (JSON Web Token) into its header and payload and reports on the expiry — the same logic as the browser tool at tools.first-ch.com/jwt/. |
|
| Parses a User-Agent string into browser name and version, rendering engine, OS and version, device type ( |
|
| Generates 1-100 UUID v4 or ULID values at once — the same logic as the browser tool at tools.first-ch.com/uuid/. A UUID v4 is 128 bits of which 122 are random (the other 6 carry the version and variant); a ULID is 26 characters where the first 10 encode the creation time (Unix milliseconds, 48 bits) and the last 16 are random (80 bits), written in Crockford's Base32. Because a ULID leads with the time, sorting the strings lexicographically sorts them chronologically, and |
|
| Calculates between an aspect ratio and a size — the same logic as the browser tool at tools.first-ch.com/aspect-ratio/. Pass |
|
| Turns TSV or CSV copied from a spreadsheet into a Markdown table, and converts a Markdown table back to CSV, TSV, HTML or JSON — the same logic as the browser tool at tools.first-ch.com/markdown-table/. Copying a range in Excel, Google Sheets or Numbers puts tab-separated text on the clipboard, not comma-separated, so the delimiter is detected by parsing with tabs, commas and semicolons in turn and keeping whichever gives the most consistent column count — thousands separators (1,200) never split a column. CSV input follows RFC 4180 quoting (commas, newlines and doubled quotes inside a quoted field). When padding cells, full-width characters are counted as two columns following the Unicode East Asian Width property, so the pipes line up in a monospaced editor. Columns whose non-empty cells are all numeric (thousands separators, decimals, currency symbols, percent signs, units) are right-aligned with |
|
| Formats a SQL query that has been squashed onto a single line — uppercase keywords, a line break per clause and real indentation — the same logic as the browser tool at tools.first-ch.com/sql-format/. |
|
| Turns a URL or any text into a QR code and returns it as SVG (vector), PNG or terminal-friendly text art — the same logic as the browser tool at tools.first-ch.com/qr/. Encoding (numeric, alphanumeric or UTF-8 byte mode, picked automatically from the input), Reed–Solomon error correction, the layout of finder, timing and alignment patterns, version information and the choice between the eight mask patterns are all implemented here (JIS X 0510 / ISO 18004, versions 1–40); there is no external API or image service. |
|
| Converts Unix seconds, milliseconds, microseconds and nanoseconds to and from ISO 8601 and ordinary date strings — the same logic as the browser tool at tools.first-ch.com/unixtime/. The unit of a plain number is detected from its digit count (up to 10 digits seconds, up to 13 milliseconds, up to 16 microseconds, longer nanoseconds); |
|
| Assembles a robots.txt from crawl rules, sitemap declarations and a preset for AI crawlers — the same logic as the browser tool at tools.first-ch.com/robots-txt/. |
|
| Converts identifiers between eleven cases — camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, Train-Case, dot.case, Title Case, Sentence case, lower case and UPPER CASE — the same logic as the browser tool at tools.first-ch.com/case/. Built for the mechanical jobs at the boundary between layers: renaming variables in bulk, moving between |
|
| Converts CSV/TSV into a JSON array and back — the same logic as the browser tool at tools.first-ch.com/csv-json/. For moving data you already have between a spreadsheet and an API: turning an exported table into JSON a request body can carry, or an API response into something Excel opens. With |
|
| Converts letters and digits, katakana, symbols and spaces between their full-width and half-width forms with a direction chosen per kind, and cleans up the whitespace in the same pass — the same logic as the browser tool at tools.first-ch.com/zenkaku/. For normalising Japanese copy supplied by a client, cleaning a file before an import, and tidying form input. Each of |
|
See server.mjs for the exact Zod input schemas.
PDF output (marp_render) needs a local Chrome/Chromium. marp-core renders the HTML with no browser dependency (so the package stays light for npx); PDF is produced by driving a locally-installed Chrome/Chromium in headless mode. It is auto-detected on common paths, or set MARP_CHROME_PATH to the executable. If none is found, marp_render returns the HTML only and reports pdf_skipped — you can still open that HTML and print → PDF yourself (one slide per page).
Telemetry
Nothing is logged by default. Usage is recorded only when you set the FIRSTCH_TOOLS_USAGE_LOG environment variable to a file path — each tool call then appends one JSON line ({ ts, tool, source }) to that local file. There is no network transmission of any kind; if the variable is unset, no file is written and no data leaves your machine.
Web version
The same algorithms are also available as a free, no-install browser tool at tools.first-ch.com — useful when you want a UI instead of an MCP call, or want to hand a link to someone without an MCP client.
Vendor sync (WebP codec)
webp_convert bundles a vendored, unmodified subset of @jsquash/webp v1.5.0 under vendor/jsquash-webp/. The web version at tools.first-ch.com vendors the exact same v1.5.0 subset, so both surfaces produce identical output. Each side's CI independently verifies its vendored files against vendor/jsquash-webp/CHECKSUMS.sha256 (see .github/workflows/ci.yml), so a silent, unnoticed drift between the two copies isn't possible.
License
The package itself is licensed under MIT.
It bundles a subset of jSquash's WebP codec under vendor/jsquash-webp/ to power webp_convert, which carries its own licenses:
The jSquash wrapper code is licensed under Apache-2.0 — see
vendor/jsquash-webp/LICENSE.The underlying libwebp codec (WASM binary and its JS glue) is licensed under BSD-3-Clause, Copyright (c) 2010 Google Inc. — see
vendor/jsquash-webp/codec/LICENSE.codec.md.
Both license files are included verbatim in the published npm package, as required by their respective terms (BSD-3-Clause in particular requires the copyright notice, condition list, and disclaimer to be reproduced in binary redistributions).
Development
npm ci
npm test # unit tests (lib.mjs / webp.mjs / marp.mjs / testdata.mjs / diff.mjs / cron.mjs), see test.mjs
node e2e.mjs # stdio smoke test: spawns server.mjs, lists tools, calls a couple of handlersCI runs both across Node 18.14.1 / 20 / 22, plus a vendor checksum check and a published-tarball content check — see .github/workflows/ci.yml.
Release rule: a push to main automatically publishes a new package version through npm Trusted Publishing (OIDC) after every CI gate passes. No NPM_TOKEN, npm login, OTP, or manual approval is used. The workflow verifies npm propagation and creates the matching vX.Y.Z tag. Package changes must bump every synchronized version field; if a version already exists with different package contents, CI fails instead of overwriting it. CI-only changes with identical package contents safely skip publishing.
日本語
@first-ch/tools-mcp は、First CH Tools(無料Webツール集)の計算ロジック — WCAGコントラスト比・日本語文字数/Xウェイト計測・WebP変換・JSON-LD生成・llms.txt生成・文字コード/改行コード変換・Marp Markdown→スライド レンダリング・テストデータ生成・テキスト/コード差分・Cron式の解説・Base64/Data URI変換・URLパラメータの分解/編集/再構築・HTML特殊文字のエスケープ/エンティティのデコード・JSON⇄YAMLの相互変換・px⇄rem/emの単位換算とCSSの一括変換・カラーコードの相互変換とアルファ透過の合成・MD5/SHA-1/SHA-256/SHA-384/SHA-512のハッシュ生成と照合・JWTのデコードと有効期限/署名の検証・User-Agent文字列の解析とデバイス判定・UUID v4 / ULIDの一括生成・アスペクト比の計算とレスポンシブサイズの算出・camelCase / snake_case / kebab-case などの文字列ケース変換・CSV/TSV ⇄ JSON の相互変換 — をAIエージェント(Claude Code等)向けMCPツールとして提供するサーバーです。
インストール
導入経路は3通りあります。使っているクライアントに合わせて選んでください。
Node.js >=18.14.1 が必要です(以下いずれの方法も npx 経由でサーバーを起動するため。Claude Code本体はNode不要のnativeインストールもありますが、その場合でもNodeは別途必要です)。
1. npm(Claude Code CLI)
claude mcp add firstch-tools -- npx -y @first-ch/tools-mcp2. Claude Code plugin(同じMCPサーバーを導入)
/plugin marketplace add First-CH/firstch-tools-mcp
/plugin install firstch-tools@first-ch3. その他のMCPクライアント(汎用JSON設定)
設定ファイル(mcp.json / claude_desktop_config.json 等)に以下を追加します。
{
"mcpServers": {
"firstch-tools": {
"command": "npx",
"args": ["-y", "@first-ch/tools-mcp"]
}
}
}本サーバーは MCP Registry にも io.github.First-CH/tools-mcp として登録済みです(server.json 参照)。レジストリ対応クライアントはこの名前からも発見・導入できます。
ツール一覧
ツール | 何をするか | 主な入力 |
| 文字色と背景色のWCAG 2.1コントラスト比を計算し、AA/AAA基準(通常テキスト・大テキスト・UI部品)の合否を返す |
|
| 日本語テキストを書記素単位で数え、全角/半角内訳・行数・X(Twitter)投稿ウェイト(全角=2・半角=1・URL=一律23・上限280)を返す |
|
| PNG/JPEG画像(絶対パス)をWebPへ変換する。tools.first-ch.com/webp/ と同一のlibwebp WASMエンコーダ(品質既定80)。出力先省略時は各入力と同じ場所に拡張子 |
|
| schema.org準拠のJSON-LDを生成する( |
|
| AI検索・生成AI向けにサイト概要を伝える |
|
| ファイル/テキストの文字コード(UTF-8 / Shift_JIS)・BOM有無・改行コード(CRLF / LF / CR)を判定し、UTF-8へ変換する。日本語CSVの文字化け調査、改行コードの統一に。出力はUTF-8のみ(Shift_JISへのエンコードは標準APIに無く変換表が必要なため非対応) |
|
| Marp Markdown をスライドへレンダリングする。テーマCSSをインラインした自己完結HTML(ブラウザで開けて、印刷すると1スライド=1ページ)と、任意でPDFを書き出す。和文テーマ |
|
| フォーム入力・CSV取り込みテスト用のダミーデータを生成する。 |
|
| 2つのテキスト(またはファイル)を比較し、追加/削除/変更の行数と unified diff( |
|
| Cron式を人間向けの文へ読み下し、次回からの発火日時を返す。tools.first-ch.com/cron/ と同一ロジック。解釈は Vixie cron( |
|
| テキストやファイルを Base64・ |
|
| URLのクエリ文字列をキーと値へ分解し、編集( |
|
| テキスト中の |
|
| JSONをYAMLへ変換して整形する(逆向きは |
|
| YAMLをJSONへ変換する。docker-compose・GitHub Actions・Kubernetes・CIの設定をプログラムから扱える形へ読み替えるときや、構文が通るかを確かめるときに使う。構文エラーは「何行何桁・原因・直し方」と前後2行の抜き出し(桁を指す |
|
| CSSの長さの単位を px ⇄ rem / em / pt で換算する。tools.first-ch.com/px-rem/ と同一ロジック。 |
|
| 色のコードを HEX / RGB / HSL / OKLCH で相互変換し、アルファ付きの |
|
| テキストまたはファイルの MD5・SHA-1・SHA-256・SHA-384・SHA-512 ハッシュ値を一度に算出する。tools.first-ch.com/hash/ と同一の仕様。 |
|
| JWT(JSON Web Token)をデコードしてヘッダーとペイロードを返し、有効期限を判定する。tools.first-ch.com/jwt/ と同一の仕様。 |
|
| User-Agent文字列から、ブラウザ名とバージョン・レンダリングエンジン・OSとそのバージョン・デバイス種別( |
|
| UUID v4 または ULID を1〜100件まとめて生成する。tools.first-ch.com/uuid/ と同一の仕様。UUID v4 は128bitのうち122bitが乱数(残る6bitがバージョンとバリアント)、ULID は26文字で先頭10文字が生成時刻(UNIX時間のミリ秒・48bit)・後ろ16文字が乱数(80bit)で、表記は Crockford's Base32(紛らわしい I・L・O・U を除く)。ULIDは時刻が先頭にあるため文字列の辞書順が生成順と一致し、 |
|
| アスペクト比と寸法を相互に計算する。tools.first-ch.com/aspect-ratio/ と同一の仕様。 |
|
| ExcelやスプレッドシートからコピーしたTSV/CSVをMarkdownの表へ整形し、逆にMarkdownの表をCSV/TSV/HTML/JSONへ書き出す。tools.first-ch.com/markdown-table/ と同一の仕様。表計算ソフトで範囲をコピーしたときのクリップボードはカンマ区切りではなくタブ区切りなので、タブ・カンマ・セミコロンのそれぞれで実際に読んでみて「列数がいちばん揃うもの」を選ぶ方式で自動判定する(金額の桁区切り 1,200 で列がずれない)。CSVはRFC 4180の引用符(セル内のカンマ・改行・二重引用符)に対応。桁揃えでは全角文字をUnicodeのEast Asian Widthに従って2桁として数えるので、等幅フォントで縦線が揃う。空でないセルがすべて数値(桁区切り・小数点・通貨記号・%・単位を含む)の列は自動で右寄せ( |
|
| 1行に固まったSQLを、予約語の大文字化・句ごとの改行・字下げの付いたクエリへ整形する。tools.first-ch.com/sql-format/ と同一の仕様。 |
|
| URL・テキストからQRコードを作り、SVG(ベクター)・PNG・端末に貼れる文字の図で返す。tools.first-ch.com/qr/ と同一の仕様。符号化(数字 / 英数字 / UTF-8のバイトモードを入力に応じて自動選択)・リード・ソロモン符号による誤り訂正・位置検出/タイミング/位置合わせパターンと型番情報の配置・8種類のマスクからの自動選択まで自前で実装しており(JIS X 0510 / ISO 18004・型番1〜40)、外部のAPIも画像生成サーバーも使わない。 |
|
| UNIX秒・ミリ秒・マイクロ秒・ナノ秒と、ISO 8601や日時文字列を相互に変換する。tools.first-ch.com/unixtime/ と同一の仕様。数値の単位は桁数から自動判定し(10桁までを秒 / 13桁までをミリ秒 / 16桁までをマイクロ秒 / それ以上をナノ秒)、 |
|
| クロールの許可/禁止ルール・サイトマップ宣言・AIクローラーの許可プリセットから robots.txt を組み立てる。tools.first-ch.com/robots-txt/ と同一の仕様。 |
|
| 識別子を camelCase / PascalCase / snake_case / CONSTANT_CASE / kebab-case・Train-Case・dot.case・Title Case・Sentence case・lower case・UPPER CASE の11形式へ相互変換する。tools.first-ch.com/case/ と同一ロジック。変数名の一括リネーム、 |
|
| CSV/TSVとJSON配列を相互変換する。tools.first-ch.com/csv-json/ と同一ロジック。表計算ソフトから書き出した表をAPIに渡せるJSONにする、逆にAPIの応答をExcelで開ける表にする、という手持ちのデータを形式だけ移し替えるための道具。 |
|
| 英数字・カタカナ・記号・スペースを文字種ごとに向きを選んで全角⇄半角へ変換し、あわせて空白まわりを掃除する。tools.first-ch.com/zenkaku/ と同一ロジック。顧客支給原稿の表記統一、CSV取り込み前の正規化、フォーム入力値の掃除のための道具。 |
|
正確な入力スキーマ(Zod定義)は server.mjs を参照してください。
marp_render のPDF出力にはローカルの Chrome/Chromium が必要です。 marp-core によるHTML生成はブラウザ非依存(npx 導入を軽く保つため)で、PDFはローカルインストール済みの Chrome/Chromium を headless で駆動して生成します。定番パスから自動検出し、MARP_CHROME_PATH で実行ファイルを明示することもできます。見つからない場合は HTML のみを返し pdf_skipped を報告します(そのHTMLを開いて印刷→PDF保存でも1スライド=1ページで作成できます)。
計測(Telemetry)について
既定では何も記録しません。環境変数 FIRSTCH_TOOLS_USAGE_LOG にファイルパスを設定したときのみ、各ツール呼び出しごとに1行のJSON({ ts, tool, source })をそのローカルファイルへ追記します。ネットワーク送信は一切ありません(未設定であればファイルへの書き込み自体が発生せず、データが端末外に出ることはありません)。
Web版
同一アルゴリズムを、インストール不要の無料ブラウザツールとしても公開しています: tools.first-ch.com。UIで使いたいとき・MCPクライアントを持たない相手にリンクを共有したいときはこちらをどうぞ。
vendor同期(WebPコーデック)
webp_convert は @jsquash/webp v1.5.0 の無改変サブセットを vendor/jsquash-webp/ 配下に同梱しています。Web版(tools.first-ch.com)も同じv1.5.0サブセットを無改変で使っており、双方が同一の出力を返します。各リポジトリのCIが独立に、自身のvendorファイルを vendor/jsquash-webp/CHECKSUMS.sha256 に対して検証するため(.github/workflows/ci.yml 参照)、両者が気づかないうちに乖離することはありません。
ライセンス
本パッケージ自体は MIT です。
webp_convert のために jSquash のWebPコーデックの一部を vendor/jsquash-webp/ 配下に同梱しており、それぞれ別のライセンスが適用されます。
jSquashのラッパーコード部分は Apache-2.0 —
vendor/jsquash-webp/LICENSEを参照内部で使われるlibwebpコーデック本体(WASMバイナリとそのJSグルーコード)は BSD-3-Clause, Copyright (c) 2010 Google Inc. —
vendor/jsquash-webp/codec/LICENSE.codec.mdを参照
いずれのライセンスファイルも公開npmパッケージに原文のまま同梱しています(BSD-3-Clauseはバイナリ再配布時にも著作権表示・条件・免責事項の再掲を求めるため)。
開発者向け
npm ci
npm test # ユニットテスト(lib.mjs / webp.mjs / marp.mjs)。詳細は test.mjs
node e2e.mjs # stdio smokeテスト: server.mjsを子プロセス起動しツール一覧取得・実行を検証CIはNode 18.14.1 / 20 / 22 の3系統に加え、vendorチェックサム検証・公開tarball内容検査を実行します(.github/workflows/ci.yml 参照)。
Available Tools
6 toolscontrast_checkWCAGコントラスト比チェックA
文字色と背景色のWCAG 2.1コントラスト比を計算し、AA/AAA基準(通常/大テキスト・UI部品)の合否を返す。Webデザインの配色検証・アクセシビリティチェックに使う。
| Name | Required | Description | Default |
|---|---|---|---|
| bg | Yes | 背景色(hex。例: #ffffff) | |
| fg | Yes | 文字色(hex。例: #333333 / 333 / fff) |
TDQS
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.
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.
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.
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.
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.
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.
count_chars文字数カウント(Xウェイト対応)A
日本語テキストの文字数(書記素単位)・全角/半角内訳・行数と、X(Twitter)の投稿ウェイト(全角=2・半角=1・URL=一律23、上限280)を返す。SNS投稿や文字数制限のあるフォーム入力の検証に使う。
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | カウント対象のテキスト |
TDQS
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.
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.
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.
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.
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.
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.
encoding_convert文字コード・改行コード変換A
CSV/テキストの文字コード(UTF-8 / Shift_JIS)・BOM有無・改行コード(CRLF/LF/CR)を判定し、UTF-8へ変換する。顧客から受け取ったCSVの文字化け調査、フォーム取り込みデータの前処理、リポジトリ内ファイルの改行コード事故(CRLFがLFに書き換わる等)の確認に使う。mode=analyze なら判定のみ、mode=convert なら変換後のテキストとbase64を返す。
| Name | Required | Description | Default |
|---|---|---|---|
| bom | No | 変換後にUTF-8 BOMを付けるか(既定 false) | |
| mode | No | 既定 analyze。convert で変換結果を返す | |
| text | No | base64の代わりにテキストを直接渡す場合(UTF-8として扱う) | |
| base64 | Yes | 対象ファイルの内容(base64)。テキストを直接渡す場合は text を使う | |
| newline | No | 変換後の改行コード(mode=convert のとき) | |
| encoding | No | 入力の文字コード。省略時は自動判定 |
TDQS
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.
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.
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.
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.
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.
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.
jsonld_generateJSON-LD構造化データ生成A
schema.org準拠のJSON-LD構造化データを生成する(tools.first-ch.com/jsonld/ と同一ロジック)。対応タイプ: organization(会社情報)/ faqpage(よくある質問)/ service(提供サービス)/ breadcrumb(パンくず)。空の項目は出力から自動で省略される。返り値は json オブジェクトと スニペット。
| Name | Required | Description | Default |
|---|---|---|---|
| faq | No | type=faqpage のときのQ&Aリスト | |
| type | Yes | スキーマタイプ | |
| service | No | type=service のときの項目 | |
| breadcrumb | No | type=breadcrumb のときの階層リスト(上から position 1,2,3…) | |
| organization | No | type=organization のときの項目 |
TDQS
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.
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.
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.
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.
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.
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.
llmstxt_generatellms.txt 生成A
生成AI・AI検索にサイト概要を伝える llms.txt(llmstxt.org 提案フォーマット準拠)を生成する(tools.first-ch.com/llms-txt/ と同一ロジック)。生成テキストをサイトのルート(/llms.txt)に設置して使う。
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | 補足説明(自由記述の段落) | |
| summary | No | サイト概要(引用ブロックになる・改行可) | |
| sections | No | リンクセクション(順に出力される) | |
| siteName | Yes | サイト名(H1になる) |
TDQS
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.
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.
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.
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.
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.
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.
webp_convert画像→WebP変換A
PNG/JPEG画像ファイルをWebPへ変換して保存する。エンコーダは tools.first-ch.com/webp/ と同一のlibwebp WASM(品質既定80)。Web制作の画像最適化・納品前の軽量化に使う。入力は絶対パス。出力先を省略すると入力と同じ場所に拡張子.webpで保存する。
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | 変換するPNG/JPEGファイルの絶対パスの配列 | |
| quality | No | 品質1-100(既定80) | |
| outputDir | No | 出力先ディレクトリ(省略時は各入力と同じ場所) |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
6 tool updates
v0.5.0- First observed
contrast_check - First observed
count_chars - First observed
encoding_convert - First observed
jsonld_generate - First observed
llmstxt_generate - First observed
webp_convert
TDQS
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.
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.
With 6 tools, the server is well-scoped for a utility toolkit, providing a focused yet sufficient set without being sparse or overwhelming.
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.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables deployment of MCP servers over HTTP, providing ready-to-use tools for text processing, math calculations, and social media content generation, accessible to AI assistants like GitHub Copilot and Claude.-
- FlicenseNot gradedqualityDmaintenanceLocal MCP server that exposes fixed tools for GPT, Claude, and Gemini while routing to any OpenAI-compatible chat completions backend with independent configuration per target.1-
- AlicenseNot gradedqualityBmaintenanceMCP server exposing Generative Engine Optimization tools to any AI agent, enabling checking of llms.txt, auditing robots.txt for AI crawlers, and validating JSON-LD schema.MIT
- AlicenseBqualityDmaintenanceMCP server exposing all major Swiss official public APIs as native tools for any MCP-compatible AI agent.3416MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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