Skip to main content
Glama
icck

Toy MCP Server

by icck
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Toy

概要

FastMCPを利用した、単語内の特定文字の出現回数をカウントするツールと、UUIDv7を生成するツールを提供するシンプルなMCPサーバーです。 count_letters ツールは、大文字・小文字を区別せずに文字をカウントします。

Related MCP server: simple-mcp-server

提供ツール

count_letters

  • 機能: 指定された単語 (word) の中に、指定された文字 (letter) が何回出現するかを返します。

  • 入力:

    • word (文字列): カウント対象の単語。

    • letter (文字列): カウントする文字。

  • 出力:

    • result (数値): 文字の出現回数。

リクエスト例 (MCPクライアントから送信される想定):

{
  "tool_name": "count_letters",
  "tool_args": {
    "word": "Programming",
    "letter": "m"
  }
}

レスポンス例 (MCPサーバーから返される想定):

{
  "result": 2
}

generate_uuid7s

  • 機能: 指定された数のUUIDv7を生成します。デフォルトは1つです。

  • 入力:

    • count (数値, オプション): 生成するUUIDの数。デフォルトは1。1以上の整数である必要があります。

  • 出力:

    • result (文字列のリスト): 生成されたUUIDv7のリスト。

リクエスト例 (MCPクライアントから送信される想定):

{
  "tool_name": "generate_uuid7s",
  "tool_args": {
    "count": 3
  }
}

レスポンス例 (MCPサーバーから返される想定):

{
  "result": [
    "018fa9e7-7d8a-7b9c-8000-000000000001",
    "018fa9e7-7d8a-7b9c-8000-000000000002",
    "018fa9e7-7d8a-7b9c-8000-000000000003"
  ]
}

セットアップ

前提条件

  • Python 3.13.1

  • Make

  • uv (Pythonパッケージ管理ツール)

手順

  1. 仮想環境の作成と依存関係のインストール: pyproject.toml にプロジェクトの依存関係が定義されています。以下のコマンドを実行すると、uv が仮想環境を作成（存在しない場合）し、依存関係を同期します。

    uv sync

使用方法

このMCPサーバー (server.py) は、標準入出力（stdio）を介してMCPクライアントと通信します。

サーバーを起動するには、プロジェクトのルートディレクトリで以下のコマンドを実行します。

uv run python server.py

または、仮想環境を有効化 (source .venv/bin/activate) している場合は、以下でも起動できます。

python server.py

起動後、MCPクライアントは上記「提供ツール」セクションに記載されたJSON形式でリクエストを標準入力に送信し、結果を標準出力から受け取ります。

Cursor / Windsurf での使用方法

Cursor / Windsurf の設定ファイル (mcp_config.json など) に以下のように追記することで、このMCPサーバーを利用できます。

{
  "mcpServers": {
    "letter-counter": {
      "command": "uv",
      "args": [
        "--directory",
        "<your_project_directory>",
        "run",
        "server.py"
      ]
    }
  }
}

注意: args 内の --directory のパスは、この README.md があるディレクトリ (プロジェクトのルートディレクトリ) を指すように、ご自身の環境に合わせて適宜修正してください。

開発コマンド (Makefile)

プロジェクトのルートディレクトリで以下の make コマンドを実行できます。

  • フォーマットと静的解析、テストの実行:

    make test

    このコマンドは、Ruffによるコードフォーマットとチェック、Mypyによる型チェック、Pytestによる単体テスト（カバレッジレポート生成を含む）を一括で実行します。

  • コードフォーマットとチェック:

    make format

    このコマンドは、Ruffを使用してコードのフォーマットとチェック（自動修正含む）を実行します。

ディレクトリ構成

.
├── .venv/                           # 仮想環境
├── htmlcov/                         # カバレッジレポート (pytest実行後に生成)
├── tests/
│   ├── __init__.py
│   ├── test_count_letters.py        # count_lettersツールのテスト
│   └── test_generate_uuid7s.py      # generate_uuid7sツールのテスト
├── tools/
│   ├── __init__.py
│   ├── count_letters_tool.py        # count_lettersツールの実装
│   └── generate_uuid_tool.py        # generate_uuid7sツールの実装
├── pyproject.toml                   # プロジェクト設定と依存関係
├── server.py                        # メインのサーバーアプリケーション
├── Makefile                         # 開発用コマンド定義
└── README.md

Available Tools

2 tools
count_lettersB

Count the number of times a letter appears in a word

ParametersJSON Schema
NameRequiredDescriptionDefault
wordYesThe word to count letters in
letterYesThe letter to count

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the basic function but lacks information about error handling, case sensitivity, performance characteristics, or what happens with invalid inputs. This is inadequate for a tool with no annotation coverage.

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, clear sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized and front-loaded, making it highly efficient.

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 simplicity (2 parameters, 100% schema coverage, output schema exists), the description is reasonably complete for its purpose. The output schema handles return values, so the description doesn't need to explain them. However, it could benefit from more behavioral context given the lack of annotations.

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?

The schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema, so it meets the baseline of 3 for high schema coverage without adding value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('count') and resources ('number of times a letter appears in a word'), making it immediately understandable. However, it doesn't differentiate from the sibling tool 'generate_uuid7s' (which is unrelated), so it doesn't fully address sibling distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives or in what context it's appropriate. It states what the tool does but offers no usage instructions, prerequisites, or exclusions.

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

generate_uuid7sB

Generates a specified number of UUIDv7 (default is 1).

ParametersJSON Schema
NameRequiredDescriptionDefault
countNoThe number of UUIDs to generate

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks critical details: it doesn't specify if the operation is idempotent, has side effects, requires permissions, or involves rate limits. For a generation tool with zero annotation coverage, this is a significant gap in transparency.

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 extremely concise and front-loaded, consisting of a single sentence that directly states the tool's function and key parameter detail. There is no wasted language, making it efficient and easy to parse for an agent.

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 the tool's low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks context on behavioral aspects like idempotency or side effects, which are important for a generation tool without annotations, leaving some gaps in completeness.

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?

The description adds minimal meaning beyond the input schema, which has 100% coverage for the single parameter 'count'. It mentions the default value (1) and implies the parameter controls quantity, but the schema already documents this thoroughly. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't add significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: generating UUIDv7 identifiers with a specified quantity. It uses specific verbs ('generates') and resources ('UUIDv7'), but does not distinguish from the sibling tool 'count_letters', which is unrelated. The description avoids tautology by explaining functionality beyond the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives or in what context it is appropriate. It mentions a default count but offers no usage scenarios, prerequisites, or exclusions. This leaves the agent without direction on application.

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.

  1. 2 tool updatesv1.0.0
    • Changedcount_letters3 fields changed
      • removedInput schema / properties / letter / title
        Removed value: -"Letter"
      • removedInput schema / properties / word / title
        Removed value: -"Word"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "type": "integer"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
    • Changedgenerate_uuid7s2 fields changed
      • removedInput schema / properties / count / title
        Removed value: -"Count"
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object",
+  "x-fastmcp-wrap-result": true
+}
  2. 2 tool updates
    • First observedcount_letters
    • First observedgenerate_uuid7s
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one counts letter occurrences in a word, while the other generates UUIDv7 identifiers. There is no overlap or ambiguity between these functions, making it easy for an agent to select the correct tool based on the task.

Naming Consistency3/5

The tool names follow a verb_noun pattern (count_letters, generate_uuid7s), which is consistent. However, the naming is slightly inconsistent in detail: 'count_letters' uses plural 'letters' while 'generate_uuid7s' uses an abbreviated 'uuid7s' instead of a full noun like 'uuids', but this is minor and does not hinder readability.

Tool Count2/5

With only 2 tools, the server feels thin and under-scoped for a general-purpose 'Toy MCP Server'. This limited set may not adequately cover typical toy or utility domains, suggesting it could benefit from additional tools to provide more comprehensive functionality.

Completeness2/5

Given the server's name implies a toy or utility domain, the tool set is severely incomplete. It lacks basic operations like string manipulation, random generation, or other common utility functions, leaving significant gaps that would limit an agent's ability to handle diverse tasks within this domain.

Maintenance

ActivityInactive
ResponsivenessSyncing

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

Related MCP Servers

  • unique-id-generator

    Pyroxin
    A
    license
    Not graded
    quality
    D
    maintenance
    A simple MCP server that provides tools for generating unique IDs in several formats, useful for when you need an LLM to create data containing new IDs.
    Eclipse Public 2.0

  • simple-mcp-server

    dataworkshop
    A
    license
    Not graded
    quality
    D
    maintenance
    A simple MCP server offering three utility tools: UUID generation, temperature conversion, and text statistics.
    11
    MIT

  • simple-mcp-server

    tluolamo
    F
    license
    Not graded
    quality
    D
    maintenance
    A simple MCP server demo providing 5 basic tools for time, calculations, string operations, UUID generation, and tool listing, built with functional programming principles.
    -

Latest Blog Posts

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/icck/toy'

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