Skip to main content
Glama
Angry-Robot-Deals

Sys8 MCP Server

by Angry-Robot-Deals
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Sys8 is a comprehensive Model Context Protocol (MCP) server that provides system information and developer utilities: date/time, OS version, math calculations, random data generation (UUID, hex, base64), hashing, text formatting, data validation (including JSON), encoding/decoding, and more.

Features

System Information

  • Get Current DateTime: Get the current date and time in all available formats (UTC, date string, time string, datetime string, Unix timestamps, human-readable formats)

  • Get OS Version: Retrieve operating system version, platform information, and current user information

Calculations & Security

  • Calculate Math Expression: Safely evaluate mathematical expressions

  • Generate Random: Generate random data (UUID v4, hex strings, base64 strings, or raw bytes)

  • Hash String: Generate hashes for strings (useful for .env file keys)

Developer Utilities (New in v0.4.0)

  • Encode/Decode Base64: Encode and decode strings to/from Base64 format

  • Encode/Decode URL: URL encoding and decoding for query strings and paths

  • Format Text Case: Convert text to different case formats (camelCase, PascalCase, kebab-case, snake_case, CONSTANT_CASE, Title Case, lowercase, UPPERCASE)

  • Generate Slug: Generate URL-friendly slugs from text

  • Validate Data: Validate data against various formats (email, url, ipv4, ipv6, domain, phone, credit-card, uuid, hex, base64, json)

  • Format JSON: Format, validate, minify, or prettify JSON strings

  • Generate Password: Generate secure passwords with customizable options (length, character types, exclude similar)

  • Format Bytes: Format bytes to human-readable format (binary or decimal)

  • Format Number: Format numbers (currency, percentage, thousands separator, decimal)

  • Convert Color: Convert between color formats (hex, RGB, HSL)

  • Convert Timezone: Convert datetime between timezones

  • Analyze Logs: Analyze text for errors and warnings in logs (compilation, npm, Docker, runtime, etc.)

  • Analyze Language: Analyze text for language distribution and character types (English, Chinese, Russian, Ukrainian, Vietnamese, Japanese, Turkish, Spanish, digits, punctuation, symbols)

Related MCP server: Power Assist MCP Server

Why MCP? Project Philosophy

Why Use MCP Instead of LLM Agents?

This MCP server provides deterministic, reliable system utilities that should never be delegated to AI agents. Here's why:

🎯 Accuracy & Reliability

  • AI agents make mistakes: LLMs frequently hallucinate, miscalculate, and produce inconsistent results when handling mathematical operations, date/time conversions, or data validation

  • Deterministic algorithms: These functions use proven, tested algorithms that always produce correct results

  • No ambiguity: System information, calculations, and validations require precision that AI cannot guarantee

💰 Cost Efficiency

  • Token savings: Instead of sending complex calculations or validation logic to expensive LLM APIs, execute them locally via MCP

  • Reduced API calls: One MCP tool call replaces multiple LLM reasoning steps

  • Faster responses: Direct function execution is orders of magnitude faster than LLM processing

🔒 Security & Privacy

  • Local execution: Sensitive operations (hashing, password generation) run locally, not in cloud LLM services

  • No data leakage: System information, calculations, and validations stay on your machine

  • Auditable code: You can review and verify the exact algorithms being used

⚡ Performance

  • Instant results: Mathematical calculations, date/time operations, and validations execute in milliseconds

  • No network latency: All operations run locally without API round-trips

  • Scalable: Handle thousands of operations per second without rate limits

✅ Best Practices

  • Separation of concerns: Let AI handle reasoning and creativity; let algorithms handle computation and validation

  • Right tool for the job: Use deterministic functions for deterministic tasks

  • Reliability: Critical operations (UUID generation, password hashing, data validation) must be 100% reliable

Example: Instead of asking an LLM "What's the current time in UTC?", use get_current_datetime - it's faster, cheaper, and always accurate.

Prerequisites

System Requirements

For Local Installation

  • Node.js >= 24.0.0 (required)

    • Used for: All server functionality, UUID generation (via crypto module), date/time operations

  • npm or compatible package manager (required)

    • Used for: Installing dependencies and building the project

  • openssl (required for generate_random with hex/base64/bytes types)

    • Usually pre-installed on macOS and Linux

    • Windows: Install via OpenSSL for Windows or use WSL

    • Used for: Cryptographically secure random string generation

    • Note: UUID generation via generate_random with type: 'uuid' does NOT require openssl (uses Node.js crypto.randomUUID())

For Docker Installation

  • Docker (required)

    • The Dockerfile automatically installs openssl in the container

    • Base image: node:lts (includes Node.js and npm)

    • Production image: node:lts-slim with openssl installed

NPM Dependencies

The following packages are automatically installed via npm install:

  • @modelcontextprotocol/sdk (v0.6.0)

    • Required for: MCP protocol implementation, server/client communication

  • expr-eval (v2.0.2)

    • Required for: Safe mathematical expression evaluation in calculate_math_expression

    • Provides: Secure expression parsing without eval() security risks

System Libraries Used

  • Node.js Built-in Modules (no installation needed):

    • crypto - UUID generation, hashing (hash_string)

    • os - OS information (get_os_version)

    • util - Promise utilities for async operations

    • child_process - Executing openssl commands

    • Buffer - Base64 encoding/decoding, binary operations

  • System Commands:

    • openssl - Random string generation (hex, base64, bytes)

      • Command: openssl rand --hex <length>

      • Command: openssl rand <length> | openssl base64

Installation

Local Installation

  1. Navigate to the sys8 directory:

cd sys8

  1. Install dependencies:

npm install

  1. Build the server:

npm run build

Quick Start: MCP Configuration

After cloning and building the repository, configure sys8 in your MCP client.

Option 1: Local Installation (Recommended)

Example for macOS/Linux:

{
  "command": "node",
  "args": ["/home/user/mcp-sys8/build/index.js"]
}

Example for Windows:

{
  "command": "node",
  "args": ["C:\\Users\\user\\mcp-sys8\\build\\index.js"]
}

Option 2: Relative Path (Project-Specific Configuration)

If sys8 is located in your project:

{
  "command": "node",
  "args": ["./sys8/build/index.js"]
}

Complete Configuration Examples

For detailed installation and configuration instructions for all MCP clients (Cursor AI, Claude Desktop, Windsurf, Docker), see the Complete Installation Guide.

Docker Installation

The sys8 MCP server is containerized and can be run using Docker.

Docker Dependencies (automatically installed in container):

  • Node.js LTS (from node:lts base image)

  • openssl (installed via apt-get install openssl in production stage)

  • All npm dependencies from package.json

Building the Docker Image

cd sys8
docker build -t sys8:latest .

Running the Container

The sys8 MCP server uses stdio protocol for communication, so it should be run interactively:

docker run --rm -i sys8:latest

Using with Docker Desktop MCP Toolkit

The sys8 server is designed to be used with Docker Desktop MCP Toolkit. After building the image, you can configure it in Docker Desktop's MCP settings.

Note: For production use in Docker Registry, the server will be available through Docker Desktop MCP Toolkit after publication.

Viewing Docker Logs

The MCP server outputs detailed logs to stderr (standard error), which allows you to monitor all MCP operations in Docker. Here's how to view them:

Option 1: Run container and see logs directly

# Run container and see all logs immediately
docker run --rm sys8:latest node test-server.mjs

# This will show:
# - Server startup logs
# - All MCP tool calls
# - Success/failure status for each call

Option 2: Run container in detached mode (for production)

# IMPORTANT: Run container with default CMD (MCP server will start automatically)
docker run -d --name sys8-server sys8:latest

# View logs (server startup and all MCP operations)
docker logs sys8-server

# View logs in real-time (follow mode)
docker logs -f sys8-server

# View last 50 lines
docker logs --tail 50 sys8-server

# View logs with timestamps
docker logs -f -t sys8-server

# Stop and remove container
docker rm -f sys8-server

⚠️ Common Issue: Empty Logs

If docker logs sys8-server shows nothing, it means the container was started with a different command (like sleep infinity) instead of running the MCP server.

Solution:

# Stop and remove the container
docker stop sys8-server
docker rm sys8-server

# Start with correct command (MCP server will run automatically)
docker run -d --name sys8-server sys8:latest

# Now logs will be visible
docker logs -f sys8-server

To check if server is running:

# Check container status
docker ps | grep sys8-server

# Check if MCP server process is running (should show node process)
docker exec sys8-server sh -c "pgrep -f 'node.*build/index.js' || echo 'Server not running - container may be using sleep command'"

Option 2: Run container and see logs immediately

# Run container and see all output (including logs)
docker run --rm sys8:latest node test-server.mjs

Option 3: Test MCP methods and see logs

# Build image
docker build -t sys8-server:latest .

# Run tests inside container (logs will be visible)
docker run --rm sys8-server:latest node test-server.mjs

Log Format: All logs are prefixed with timestamps and log levels:

[2025-12-07T04:33:44.379Z] [INFO] ========================================
[2025-12-07T04:33:44.379Z] [INFO] Sys8 MCP Server started
[2025-12-07T04:33:44.379Z] [INFO] Version: 0.4.0
[2025-12-07T04:33:44.379Z] [INFO] Transport: stdio
[2025-12-07T04:33:44.379Z] [INFO] ========================================
[2025-12-07T04:33:44.383Z] [INFO] Tool call received: get_current_datetime
[2025-12-07T04:33:44.391Z] [INFO] Tool call: get_current_datetime | Args: {} | Status: SUCCESS
[2025-12-07T04:33:44.392Z] [INFO] Tool call received: get_os_version
[2025-12-07T04:33:44.392Z] [INFO] Tool call: get_os_version | Args: {} | Status: SUCCESS

What gets logged:

  • Server startup information (version, transport)

  • ListTools requests (when client requests available tools)

  • All tool calls (name, arguments, success/failure status)

  • Errors (with detailed error messages)

Note: When the server is used via MCP client (like Cursor AI), logs are automatically visible in the client's output. For Docker containers running in detached mode, use docker logs to view them.

Usage

Available Tools

1. get_current_datetime

Get the current date and time in all available formats.

Parameters: None

Example:

{
  "name": "get_current_datetime",
  "arguments": {}
}

Response:

{
  "utc": "2025-11-30T10:27:35.291Z",
  "date": "2025-11-30",
  "time": "10:27:35",
  "datetime": "2025-11-30 10:27:35",
  "unix_timestamp_seconds": 1764498455,
  "unix_timestamp_milliseconds": 1764498455291,
  "human_readable_utc0": "30/11/2025, 10:27:35",
  "human_readable_utc2": "30/11/2025, 12:27:35",
  "human_readable_utc3": "30/11/2025, 13:27:35"
}

Response Fields:

  • utc: ISO 8601 UTC datetime string

  • date: Date string in YYYY-MM-DD format

  • time: Time string in HH:mm:ss format

  • datetime: Combined date and time string

  • unix_timestamp_seconds: Unix timestamp in seconds

  • unix_timestamp_milliseconds: Unix timestamp in milliseconds

  • human_readable_utc0: Human-readable format in UTC+0 (DD/MM/YYYY, HH:MM:SS)

  • human_readable_utc2: Human-readable format in UTC+2 (DD/MM/YYYY, HH:MM:SS)

  • human_readable_utc3: Human-readable format in UTC+3 (DD/MM/YYYY, HH:MM:SS)

2. get_os_version

Get the operating system version, platform information, and current user information.

Parameters: None

Example:

{
  "name": "get_os_version",
  "arguments": {}
}

Response:

{
  "platform": "darwin",
  "release": "25.1.0",
  "architecture": "arm64",
  "type": "Darwin",
  "hostname": "mac.local",
  "username": "ug",
  "homedir": "/Users/ug",
  "platformName": "macOS",
  "uid": 501,
  "gid": 20
}

Response Fields:

  • platform: Platform identifier (darwin, win32, linux)

  • release: OS release version

  • architecture: CPU architecture

  • type: OS type

  • hostname: System hostname

  • username: Current user name

  • homedir: User home directory

  • platformName: Human-readable platform name (macOS, Windows, Linux)

  • uid: User ID (Unix systems only)

  • gid: Group ID (Unix systems only)

3. calculate_math_expression

Calculate a mathematical expression safely.

Parameters:

  • expression (required, string): Mathematical expression to evaluate (e.g., "2 + 2", "(10 + 5) * 3 / 2", "sqrt(16)")

Supported Operations:

  • Arithmetic: +, -, *, /, % (modulo), ^ (power)

  • Functions: abs, ceil, floor, round, max, min, sqrt, sin, cos, tan, asin, acos, atan, log, exp

  • Constants: PI, E

  • Parentheses: Full support for grouping expressions

  • Precedence: Standard mathematical operator precedence

Example:

{
  "name": "calculate_math_expression",
  "arguments": {
    "expression": "2 + 2"
  }
}

Response:

{
  "result": 4,
  "expression": "2 + 2"
}

More Examples:

  • Simple arithmetic: "2 + 2" → 4

  • Complex expression: "(10 + 5) * 3 / 2" → 22.5

  • Decimal operations: "3.14 * 2" → 6.28

  • Negative numbers: "-5 + 3" → -2

  • Functions: "sqrt(16)" → 4, "sin(PI/2)" → 1

  • Power: "2^3" → 8

Error Handling:

  • Invalid syntax: Returns error with clear message

  • Division by zero: Returns error "Division by zero is not allowed"

  • Empty expression: Returns error "Expression cannot be empty or whitespace-only"

  • Invalid operations: Returns error with description

4. generate_random

Generate random data: UUID v4, hex strings, base64 strings, or raw bytes.

Parameters:

  • type (string, required): Type of random data - 'uuid' | 'hex' | 'base64' | 'bytes'

  • length (number, optional): Length in bytes for hex/base64/bytes (8-128, default: generates all standard lengths)

  • format (string, optional): Format for UUID only - 'standard' | 'uppercase' | 'without-dashes' (default: returns all formats)

Example (UUID):

{
  "name": "generate_random",
  "arguments": {
    "type": "uuid"
  }
}

Response (UUID):

{
  "type": "uuid",
  "value": "550e8400-e29b-41d4-a716-446655440000",
  "uuid": {
    "standard": "550e8400-e29b-41d4-a716-446655440000",
    "uppercase": "550E8400-E29B-41D4-A716-446655440000",
    "without_dashes": "550e8400e29b41d4a716446655440000"
  }
}

Example (Hex - all lengths):

{
  "name": "generate_random",
  "arguments": {
    "type": "hex"
  }
}

Response (Hex - all lengths):

{
  "type": "hex",
  "value": "84A7B45B6BD20D97",
  "hex": {
    "hex_8_uppercase": "84A7B45B6BD20D97",
    "hex_16_uppercase": "4F76E8D72DFC73D01697F31B65910C19",
    "hex_32_uppercase": "57FCAA273E858F6CA7A467A8E233727F913C799E8B51E8B27EF04B90BBD4C2F4",
    "hex_64_uppercase": "5F2DCD116CEF205127445A5134D8008E3556CBDCC4759E89DA540C043E3B68B34A20A55587D375069BC38A97404E12C3FCEB42C8BB09E4C7651059107B2B9EFD"
  }
}

Example (Base64 - specific length):

{
  "name": "generate_random",
  "arguments": {
    "type": "base64",
    "length": 32
  }
}

Response (Base64 - specific length):

{
  "type": "base64",
  "value": "Yf1uDqalYr67AEtjTR/LxWj2zza/b7iUyHGNRpXPUAA=",
  "base64": {
    "base64_32": "Yf1uDqalYr67AEtjTR/LxWj2zza/b7iUyHGNRpXPUAA="
  }
}

Note:

  • UUID generation uses Node.js crypto and doesn't require openssl

  • Hex, base64, and bytes generation require openssl to be installed

  • If openssl is not available, hex/base64/bytes generation will return an error

5. hash_string

Generate hash for a string (useful for .env file keys).

Parameters:

  • input (required, string): String to hash

Example:

{
  "name": "hash_string",
  "arguments": {
    "input": "my-secret-key"
  }
}

Response:

{
  "input": "my-secret-key",
  "sha256_hex": "d5579c46dfcc7f18207013e65b44e4cb4e2c2298f4ac457ba8f82743f31e930b",
  "sha256_base64": "1VecRt/MfxggcBPmW0Tky04sIpj0rEV7qPgnQ/Mekws=",
  "sha512_hex": "10e6d647af44624442f388c2c14a787ff8b17e6165b83d767ec047768d8cbcb71a1a3226e7cc7816bc79c0427d94a9da688c41a3992c7bf5e4d7cc3e0be5dbac",
  "sha512_base64": "EObWR69EYkRC84jCwUp4f/ixfmFluD12fsBHdo2MvLcaGjIm58x4Frx5wEJ9lKnaaIxBo5kse/Xk18w+C+XbrA=="
}

Response Fields:

  • input: Original input string

  • sha256_hex: SHA256 hash in hexadecimal format (64 characters)

  • sha256_base64: SHA256 hash in base64 format

  • sha512_hex: SHA512 hash in hexadecimal format (128 characters)

  • sha512_base64: SHA512 hash in base64 format

Error Handling:

  • Empty input: Returns error "Input string cannot be empty or whitespace-only"

6. analyze_logs

Analyze text for errors and warnings in logs. Detects common error patterns including compilation errors, npm errors, Docker errors, runtime errors, and warnings.

Parameters:

  • text (required, string): Text content to analyze for errors and warnings

Example:

{
  "name": "analyze_logs",
  "arguments": {
    "text": "npm ERR! code EACCES\nnpm ERR! permission denied\nerror TS2304: Cannot find name 'undefined'.\nnpm WARN deprecated package@1.0.0"
  }
}

Response:

{
  "error_count": 3,
  "warning_count": 1,
  "errors": [
    {
      "line": 1,
      "message": "npm ERR! code EACCES",
      "type": "npm"
    },
    {
      "line": 2,
      "message": "npm ERR! permission denied",
      "type": "npm"
    },
    {
      "line": 3,
      "message": "error TS2304: Cannot find name 'undefined'.",
      "type": "compilation"
    }
  ],
  "warnings": [
    {
      "line": 4,
      "message": "npm WARN deprecated package@1.0.0",
      "type": "npm"
    }
  ]
}

Response Fields:

  • error_count: Number of errors found in the text

  • warning_count: Number of warnings found in the text

  • errors: Array of error objects with:

    • line: Line number where error was found

    • message: Error message (truncated to 200 characters)

    • type: Error type (compilation, npm, docker, runtime, etc.)

  • warnings: Array of warning objects with:

    • line: Line number where warning was found

    • message: Warning message (truncated to 200 characters)

    • type: Warning type (npm, deprecated, security, etc.)

Detected Error Types:

  • Compilation errors (TypeScript, syntax, type errors)

  • npm errors (EACCES, ENOENT, installation failures)

  • Docker errors (build failures, image not found, container errors)

  • Runtime errors (exceptions, fatal errors, stack overflow)

  • Network errors (connection refused, timeout, HTTP errors)

  • File system errors (ENOENT, EACCES, permission denied)

  • Database errors (SQL errors, connection failures)

  • Authentication errors (unauthorized, invalid token)

Detected Warning Types:

  • npm warnings (deprecated packages, peer dependencies)

  • Compilation warnings (unused variables, type safety)

  • Docker warnings

  • Security warnings (vulnerabilities, insecure configurations)

  • Performance warnings (slow queries, memory leaks)

  • Deprecated API warnings

Error Handling:

  • Empty text: Returns zero counts and empty arrays

7. analyze_language

Analyze text for language distribution and character types. Detects characters from multiple languages (English, Chinese, Russian, Ukrainian, Vietnamese, Japanese, Turkish, Spanish) and categorizes other characters (digits, punctuation, symbols, whitespace).

Parameters:

  • text (required, string): Text content to analyze for language and character distribution

Example:

{
  "name": "analyze_language",
  "arguments": {
    "text": "Hello 你好 Привет こんにちは 123!"
  }
}

Response:

{
  "total_characters": 20,
  "encoding": "UTF-16 (JavaScript default)",
  "languages": {
    "english": {
      "count": 5,
      "percentage": 25.0
    },
    "chinese": {
      "count": 2,
      "percentage": 10.0
    },
    "russian": {
      "count": 6,
      "percentage": 30.0
    },
    "ukrainian": {
      "count": 0,
      "percentage": 0.0
    },
    "vietnamese": {
      "count": 0,
      "percentage": 0.0
    },
    "japanese": {
      "count": 5,
      "percentage": 25.0
    },
    "turkish": {
      "count": 0,
      "percentage": 0.0
    },
    "spanish": {
      "count": 0,
      "percentage": 0.0
    }
  },
  "categories": {
    "digits": {
      "count": 3,
      "percentage": 15.0
    },
    "punctuation": {
      "count": 1,
      "percentage": 5.0
    },
    "symbols": {
      "count": 0,
      "percentage": 0.0
    },
    "whitespace": {
      "count": 3,
      "percentage": 15.0
    },
    "other": {
      "count": 0,
      "percentage": 0.0
    }
  }
}

Response Fields:

  • total_characters: Total number of characters in the text

  • encoding: Detected encoding (UTF-8, UTF-16, etc.) if determinable

  • languages: Object with language-specific counts and percentages:

    • english: English letters (A-Z, a-z)

    • chinese: Chinese characters (CJK Unified Ideographs)

    • russian: Russian Cyrillic characters

    • ukrainian: Ukrainian Cyrillic characters (distinguished by specific characters like і, ї, є)

    • vietnamese: Vietnamese Latin characters with diacritics

    • japanese: Japanese characters (Hiragana, Katakana, Kanji)

    • turkish: Turkish Latin characters with specific characters (İ, ı, Ş, ş, Ğ, ğ, Ç, ç, Ö, ö, Ü, ü)

    • spanish: Spanish Latin characters with specific characters (á, é, í, ó, ú, ñ, ü)

  • categories: Object with character category counts and percentages:

    • digits: Numeric digits (0-9)

    • punctuation: Punctuation marks

    • symbols: Mathematical and other symbols

    • whitespace: Whitespace characters (spaces, tabs, newlines)

    • other: Unclassified characters

Language Detection:

  • Uses Unicode ranges to identify characters from different languages

  • Distinguishes between Russian and Ukrainian by detecting Ukrainian-specific characters (і, ї, є)

  • Detects language-specific characters for Vietnamese, Turkish, and Spanish

  • Percentages are calculated with 2 decimal places precision

Encoding Detection:

  • Attempts to detect encoding (UTF-8, UTF-16, UTF-8 BOM, etc.)

  • Uses heuristics based on BOM markers and character patterns

  • Returns encoding information if determinable, otherwise may be undefined

Error Handling:

  • Empty text: Returns zero counts and percentages for all languages and categories

8. encode_base64

Encode string to Base64 format.

Parameters:

  • input (required, string): String to encode

  • encoding (optional, string): Input encoding - utf8, hex, or binary (default: utf8)

Example:

{
  "name": "encode_base64",
  "arguments": {
    "input": "Hello World!",
    "encoding": "utf8"
  }
}

Response:

{
  "encoded": "SGVsbG8gV29ybGQh",
  "input": "Hello World!",
  "encoding": "utf8"
}

9. decode_base64

Decode Base64 string.

Parameters:

  • input (required, string): Base64 string to decode

  • encoding (optional, string): Output encoding - utf8, hex, or binary (default: utf8)

Example:

{
  "name": "decode_base64",
  "arguments": {
    "input": "SGVsbG8gV29ybGQh",
    "encoding": "utf8"
  }
}

Response:

{
  "decoded": "Hello World!",
  "input": "SGVsbG8gV29ybGQh",
  "encoding": "utf8"
}

10. encode_url

Encode string for URL (URL encoding).

Parameters:

  • input (required, string): String to encode

  • component (optional, string): Component type - full, path, or query (default: full)

Example:

{
  "name": "encode_url",
  "arguments": {
    "input": "Hello World!",
    "component": "full"
  }
}

Response:

{
  "encoded": "Hello%20World%21",
  "input": "Hello World!",
  "component": "full"
}

11. decode_url

Decode URL-encoded string.

Parameters:

  • input (required, string): URL-encoded string to decode

  • component (optional, string): Component type - full, path, or query (default: full)

Example:

{
  "name": "decode_url",
  "arguments": {
    "input": "Hello%20World%21",
    "component": "full"
  }
}

Response:

{
  "decoded": "Hello World!",
  "input": "Hello%20World%21",
  "component": "full"
}

12. format_text_case

Convert text to different case formats.

Parameters:

  • input (required, string): Text to convert

  • format (optional, string): Target format - camelCase, PascalCase, kebab-case, snake_case, CONSTANT_CASE, Title Case, lowercase, or UPPERCASE (if omitted, returns all formats)

Example:

{
  "name": "format_text_case",
  "arguments": {
    "input": "hello world example"
  }
}

Response:

{
  "input": "hello world example",
  "camelCase": "helloWorldExample",
  "PascalCase": "HelloWorldExample",
  "kebab-case": "hello-world-example",
  "snake_case": "hello_world_example",
  "CONSTANT_CASE": "HELLO_WORLD_EXAMPLE",
  "Title Case": "Hello World Example",
  "lowercase": "hello world example",
  "UPPERCASE": "HELLO WORLD EXAMPLE"
}

13. generate_slug

Generate URL-friendly slug from text.

Parameters:

  • input (required, string): Text to convert to slug

  • separator (optional, string): Separator character (default: -)

  • lowercase (optional, boolean): Convert to lowercase (default: true)

Example:

{
  "name": "generate_slug",
  "arguments": {
    "input": "Hello World Example!",
    "separator": "-",
    "lowercase": true
  }
}

Response:

{
  "input": "Hello World Example!",
  "slug": "hello-world-example",
  "separator": "-"
}

14. validate_data

Validate data against various formats.

Parameters:

  • input (required, string): Data to validate

  • type (required, string): Validation type - email, url, ipv4, ipv6, domain, phone, credit-card, uuid, hex, base64, or json

Example:

{
  "name": "validate_data",
  "arguments": {
    "input": "user@example.com",
    "type": "email"
  }
}

Response:

{
  "input": "user@example.com",
  "type": "email",
  "valid": true,
  "normalized": "user@example.com"
}

Supported Validation Types:

  • email: Email address validation

  • url: URL validation (must start with http:// or https://)

  • ipv4: IPv4 address validation

  • ipv6: IPv6 address validation

  • domain: Domain name validation

  • phone: Phone number validation (international format)

  • credit-card: Credit card number validation (13-19 digits)

  • uuid: UUID v4 validation

  • hex: Hexadecimal string validation

  • base64: Base64 string validation

  • json: JSON string validation (parsing)

15. format_json

Format, validate, minify, or prettify JSON.

Parameters:

  • input (required, string): JSON string to process

  • action (required, string): Action to perform - format, validate, minify, or prettify

  • indent (optional, number): Number of spaces for indentation (0-10, default: 2)

Example:

{
  "name": "format_json",
  "arguments": {
    "input": "{\"name\":\"test\",\"value\":123}",
    "action": "prettify",
    "indent": 2
  }
}

Response:

{
  "valid": true,
  "formatted": "{\n  \"name\": \"test\",\n  \"value\": 123\n}",
  "minified": "{\"name\":\"test\",\"value\":123}"
}

Actions:

  • validate: Validate JSON and return formatted version

  • format: Format JSON with specified indentation

  • prettify: Same as format (pretty print)

  • minify: Remove all whitespace from JSON

16. generate_password

Generate secure passwords with customizable options.

Parameters:

  • length (optional, number): Password length (8-128, default: 16)

  • include_uppercase (optional, boolean): Include uppercase letters (default: true)

  • include_lowercase (optional, boolean): Include lowercase letters (default: true)

  • include_numbers (optional, boolean): Include numbers (default: true)

  • include_symbols (optional, boolean): Include symbols (default: true)

  • exclude_similar (optional, boolean): Exclude similar characters (il1Lo0O) (default: false)

Example:

{
  "name": "generate_password",
  "arguments": {
    "length": 16,
    "include_uppercase": true,
    "include_lowercase": true,
    "include_numbers": true,
    "include_symbols": true,
    "exclude_similar": false
  }
}

Response:

{
  "password": "Kx9#mP2$vL8@nQ4!",
  "length": 16,
  "strength": "strong",
  "entropy": 95.24,
  "character_set_size": 94
}

Password Strength Levels:

  • weak: Low entropy (< 50)

  • medium: Medium entropy (50-70)

  • strong: High entropy (70-90)

  • very-strong: Very high entropy (> 90)

17. format_bytes

Format bytes to human-readable format.

Parameters:

  • bytes (required, number): Number of bytes to format

  • format (optional, string): Format type - binary (1024-based) or decimal (1000-based) (default: binary)

  • precision (optional, number): Number of decimal places (0-10, default: 2)

Example:

{
  "name": "format_bytes",
  "arguments": {
    "bytes": 1048576,
    "format": "binary",
    "precision": 2
  }
}

Response:

{
  "bytes": 1048576,
  "formatted": "1.00 MB",
  "formatted_decimal": "1.05 MB",
  "kilobytes": 1024,
  "megabytes": 1,
  "gigabytes": 0.0009765625,
  "terabytes": 9.5367431640625e-7,
  "petabytes": 9.313225746154785e-10
}

18. format_number

Format numbers (currency, percentage, thousands separator, decimal).

Parameters:

  • number (required, number): Number to format

  • format (required, string): Format type - currency, percentage, thousands, or decimal

  • locale (optional, string): Locale (default: en-US)

  • currency (optional, string): Currency code for currency format (default: USD)

  • minimum_fraction_digits (optional, number): Minimum fraction digits (0-20)

  • maximum_fraction_digits (optional, number): Maximum fraction digits (0-20)

Example:

{
  "name": "format_number",
  "arguments": {
    "number": 1234.56,
    "format": "currency",
    "locale": "en-US",
    "currency": "USD"
  }
}

Response:

{
  "input": 1234.56,
  "formatted": "$1,234.56",
  "format": "currency",
  "locale": "en-US",
  "currency": "USD"
}

Format Types:

  • currency: Format as currency (e.g., $1,234.56)

  • percentage: Format as percentage (e.g., 12.34%)

  • thousands: Format with thousands separator (e.g., 1,234.56)

  • decimal: Format with decimal point (e.g., 1234.56)

19. convert_color

Convert between color formats (hex, RGB, HSL).

Parameters:

  • input (required, string): Color value to convert

  • from (required, string): Source color format - hex, rgb, or hsl

  • to (required, string): Target color format - hex, rgb, or hsl

Example:

{
  "name": "convert_color",
  "arguments": {
    "input": "#FF5733",
    "from": "hex",
    "to": "rgb"
  }
}

Response:

{
  "input": "#FF5733",
  "from": "hex",
  "to": "rgb",
  "hex": "#FF5733",
  "rgb": "rgb(255, 87, 51)",
  "hsl": "hsl(9, 100%, 60%)",
  "rgb_array": [255, 87, 51],
  "hsl_array": [9, 100, 60]
}

Note: Returns all formats (hex, RGB, HSL) regardless of requested conversion for convenience.

20. convert_timezone

Convert datetime between timezones.

Parameters:

  • datetime (required, string): Datetime string to convert

  • from_timezone (optional, string): Source timezone (default: UTC)

  • to_timezone (required, string): Target timezone

  • format (optional, string): Output format (optional)

Example:

{
  "name": "convert_timezone",
  "arguments": {
    "datetime": "2025-12-07T12:00:00Z",
    "from_timezone": "UTC",
    "to_timezone": "America/New_York"
  }
}

Response:

{
  "input_datetime": "2025-12-07T12:00:00Z",
  "from_timezone": "UTC",
  "to_timezone": "America/New_York",
  "converted_datetime": "2025-12-07 07:00:00",
  "iso_string": "2025-12-07T07:00:00-05:00",
  "unix_timestamp": 1733580000,
  "formatted": "2025-12-07 07:00:00"
}

Installation & Configuration

Quick Start

Choose your environment below for installation instructions:

Cursor AI

Global Configuration (All Users and Projects) - Recommended

To configure this MCP server for use in Cursor AI globally (for all users and projects), you need to add it to the global MCP configuration file.

Option 1: Using tsx (Recommended for Development)

This approach runs TypeScript directly without compilation, similar to other MCP servers. It's more convenient during development.

macOS/Linux:

  1. Create or edit the global MCP configuration file:

mkdir -p ~/Library/Application\ Support/Cursor/User/globalStorage
nano ~/Library/Application\ Support/Cursor/User/globalStorage/mcp.json

Or alternatively:

mkdir -p ~/.cursor
nano ~/.cursor/mcp.json

  1. Add the following configuration:

{
  "mcpServers": {
    "sys8": {
      "command": "npx",
      "args": ["tsx", "/Users/ug/code/AI/mcp/sys8/src/index.ts"]
    }
  }
}

Windows:

{
  "mcpServers": {
    "sys8": {
      "command": "npx",
      "args": ["tsx", "C:\\path\\to\\mcp\\sys8\\src\\index.ts"]
    }
  }
}

Important: Replace the path with the absolute path to your src/index.ts file.

Option 2: Using Compiled JavaScript (Production)

This approach uses the compiled JavaScript file. Requires running npm run build after code changes.

macOS/Linux:

  1. Create or edit the global MCP configuration file:

mkdir -p ~/Library/Application\ Support/Cursor/User/globalStorage
nano ~/Library/Application\ Support/Cursor/User/globalStorage/mcp.json

  1. Add the following configuration:

{
  "mcpServers": {
    "sys8": {
      "command": "node",
      "args": ["/Users/ug/code/AI/mcp/sys8/build/index.js"]
    }
  }
}

Important: Replace /Users/ug/code/AI/mcp/sys8/build/index.js with the absolute path to your build/index.js file.

Linux

  1. Create or edit the global MCP configuration file:

mkdir -p ~/.config/Cursor/User/globalStorage
nano ~/.config/Cursor/User/globalStorage/mcp.json

Or alternatively:

mkdir -p ~/.cursor
nano ~/.cursor/mcp.json

  1. Add the configuration as shown above for macOS.

Windows

  1. Create or edit the global MCP configuration file:

%APPDATA%\Cursor\User\globalStorage\mcp.json

Or alternatively:

%USERPROFILE%\.cursor\mcp.json

  1. Add the following configuration (use Windows path format):

{
  "mcpServers": {
    "sys8": {
      "command": "node",
      "args": ["C:\\path\\to\\mcp\\sys8\\build\\index.js"]
    }
  }
}

Note: Use double backslashes (\\) or forward slashes (/) in Windows paths.

Project-Specific Configuration

If you prefer to configure it per-project, create or edit .cursor/mcp.json file in your project root:

{
  "mcpServers": {
    "sys8": {
      "command": "node",
      "args": ["/absolute/path/to/sys8/build/index.js"]
    }
  }
}

Example: If your project is at /Users/ug/code/AI/mcp, you can use:

{
  "mcpServers": {
    "sys8": {
      "command": "node",
      "args": ["./sys8/build/index.js"]
    }
  }
}

Alternative: Using npm link (For Development)

If you want to use the server from anywhere without specifying the full path:

  1. In the sys8 directory:

npm link

  1. Then in the configuration, use:

{
  "mcpServers": {
    "sys8": {
      "command": "sys8"
    }
  }
}

Verifying Configuration

After adding the configuration:

  1. Restart Cursor AI

  2. The MCP server should be automatically loaded

  3. You can verify it's working by using the tools in Cursor AI chat

Example Configuration File

See cursor-mcp-config-example.json in this directory for a complete example configuration.

Testing

Automated Tests

Run the automated test suite to verify all functions:

npm test

This will test all 20 tools:

  • get_current_datetime - all available formats

  • get_os_version - OS information and user details

  • calculate_math_expression - simple arithmetic, complex expressions, functions, and error cases

  • hash_string - SHA256 and SHA512 hashes in hex and base64 formats

  • generate_random - UUID v4, hex strings, base64 strings, or raw bytes generation

  • encode_base64 / decode_base64 - Base64 encoding/decoding

  • encode_url / decode_url - URL encoding/decoding

  • format_text_case - text case conversion (camelCase, kebab-case, etc.)

  • generate_slug - URL-friendly slug generation

  • validate_data - data validation (email, URL, IP, JSON, etc.)

  • format_json - JSON formatting, validation, and minification

  • generate_password - secure password generation with customizable options

  • format_bytes - bytes formatting to human-readable format (binary/decimal)

  • format_number - number formatting (currency, percentage, thousands, decimal)

  • convert_color - color conversion (hex, RGB, HSL)

  • convert_timezone - timezone conversion

  • analyze_logs - analyze text for errors and warnings in logs

  • analyze_language - analyze text for language distribution and character types

  • analyze_language - analyze text for language distribution and character types

MCP Inspector

Test the server interactively using the MCP Inspector:

npm run inspector

This opens an interactive interface where you can test each tool manually.

Manual Testing

You can also run the server directly:

node build/index.js

Or using tsx:

npx tsx src/index.ts

Development

  • Watch mode: npm run watch - Automatically rebuilds on file changes

  • Build: npm run build - Compiles TypeScript to JavaScript

  • Inspector: npm run inspector - Runs MCP Inspector for testing

Limitations & Requirements

System Dependencies

  • openssl: Required for generate_random with type: 'hex', type: 'base64', or type: 'bytes'

    • Must be installed and accessible in system PATH

    • Usually pre-installed on macOS and Linux

    • Windows: Install separately or use WSL

    • UUID generation (generate_random with type: 'uuid') does NOT require openssl (uses Node.js crypto.randomUUID())

  • Node.js >= 24.0.0: Required for all functionality

    • Provides built-in crypto module for UUID and hashing

    • Provides os module for system information

    • Provides Buffer for encoding/decoding operations

Functional Limitations

  • OS version information: Based on Node.js os module capabilities (may vary by platform)

  • Date/time information:

    • get_current_datetime returns all formats in UTC timezone

    • Uses system timezone settings for conversions

  • Mathematical expressions: Limited to operations supported by expr-eval library

    • Supports: arithmetic, trigonometry, logarithms, power operations

    • Does NOT support: complex numbers, matrix operations, symbolic math

    • Security: Uses safe parser configuration to prevent code injection (no variables, logical operators, or comparison operators)

  • Hashing algorithms: Only SHA256 and SHA512 available (via hash_string)

    • Other algorithms (MD5, SHA1, etc.) not provided for security reasons

License

Private project - not for distribution.

Available Tools

20 tools
analyze_languageC

Analyze text for language distribution and character types (English, Chinese, Russian, Ukrainian, Vietnamese, Japanese, Turkish, Spanish, digits, punctuation, symbols)

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText content to analyze for language and character distribution

TDQS

C2.9/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 doesn't describe how it behaves: it doesn't specify the output format (e.g., percentages, counts), whether it handles mixed-language text, error conditions, or performance characteristics. This is a significant gap 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.

Conciseness4/5

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

The description is a single, efficient sentence that front-loads the core purpose ('Analyze text for language distribution and character types') followed by a specific list. There's no wasted verbiage, though it could be slightly more structured (e.g., separating languages from character categories).

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?

Given the complexity of language analysis, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a breakdown by language, character counts), how it handles ambiguous cases, or any limitations (e.g., supported encodings). This leaves significant gaps for an agent to use the tool effectively.

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 input schema has 100% description coverage, with the 'text' parameter clearly documented. The description adds marginal value by implying the text should contain content relevant to the listed languages and character types, but doesn't provide additional syntax, format, or constraints beyond what the schema already states. This meets the baseline for high schema coverage.

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: 'Analyze text for language distribution and character types' followed by a specific list of languages and character categories. It uses a specific verb ('analyze') and resource ('text'), though it doesn't explicitly differentiate from sibling tools like 'format_text_case' or 'validate_data' which might also process text.

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. It doesn't mention when this analysis is appropriate (e.g., for multilingual content, character encoding checks) or when other tools like 'format_text_case' or 'validate_data' might be better suited. No exclusions or prerequisites are stated.

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

analyze_logsC

Analyze text for errors and warnings in logs (compilation, npm, Docker, runtime, etc.)

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesText content to analyze for errors and warnings

TDQS

C2.9/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 the tool analyzes text for errors and warnings but doesn't describe what the analysis entails (e.g., pattern matching, severity levels, output format), whether it's read-only or has side effects, or any limitations (e.g., performance, supported log formats). This leaves significant gaps in understanding the tool's behavior.

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, efficient sentence that front-loads the core purpose ('Analyze text for errors and warnings in logs') and includes helpful examples in parentheses. There's no wasted verbiage, making it easy to parse and understand quickly.

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?

Given the tool's complexity (analyzing logs for errors/warnings), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what the analysis returns, how errors/warnings are identified, or any behavioral traits. This leaves the agent with inadequate information to use the tool effectively beyond basic invocation.

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 the single parameter 'text' well-documented in the schema. The description adds minimal value beyond the schema by implying the text should contain logs, but doesn't provide additional semantics like format requirements or examples. This meets the baseline for high schema coverage.

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: 'Analyze text for errors and warnings in logs' with specific examples of log types (compilation, npm, Docker, runtime). It uses a specific verb ('analyze') and resource ('text for errors and warnings in logs'), but doesn't explicitly distinguish from sibling tools like 'analyze_language' or 'validate_data', which might have overlapping domains.

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. It mentions log types but doesn't specify use cases, prerequisites, or exclusions. With sibling tools like 'analyze_language' and 'validate_data' present, there's no indication of how this tool differs or when it's the appropriate choice.

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

calculate_math_expressionC

Calculate a mathematical expression safely

ParametersJSON Schema
NameRequiredDescriptionDefault
expressionYesMathematical expression to evaluate (e.g., "2 + 2", "(10 + 5) * 3 / 2", "sqrt(16)")

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Safely' hints at error handling but doesn't specify what safety means (e.g., sandboxed evaluation, input validation, error types). No information about performance, rate limits, or output format is provided.

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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and gets straight to the point without unnecessary elaboration.

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?

For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what mathematical operations are supported, how errors are handled, what the return format looks like, or any limitations. The 'safely' hint is too vague to provide meaningful context.

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 schema already documents the single 'expression' parameter with examples. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.

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 a specific verb ('calculate') and resource ('mathematical expression'), and the 'safely' qualifier adds useful context. However, it doesn't distinguish this tool from potential mathematical siblings (though none exist in the provided sibling list).

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. While there are no obvious mathematical siblings in the list, there's no mention of what types of mathematical expressions are supported, limitations, or when other tools might be more appropriate.

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

convert_colorB

Convert between color formats (hex, RGB, HSL)

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesColor value to convert
fromYesSource color format
toYesTarget color format

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 doesn't describe how it behaves: it doesn't mention error handling (e.g., for invalid inputs), output format, or any constraints like rate limits or permissions. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.

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: 'Convert between color formats (hex, RGB, HSL)' is a single, efficient sentence that directly states the purpose with zero waste. Every word earns its place, making it easy to parse and understand quickly.

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 moderate complexity (3 parameters, no nested objects) and the absence of annotations and output schema, the description is minimally adequate. It covers the basic function but lacks details on behavior, error handling, and output format, which are important for a conversion tool. It's complete enough to understand what it does but not how it works fully.

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 clear descriptions for all three parameters ('input', 'from', 'to') and enums for 'from' and 'to'. The description adds minimal value beyond the schema by listing the formats (hex, RGB, HSL), but it doesn't provide additional context like examples or edge cases. Given the high schema coverage, a baseline score of 3 is appropriate.

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: 'Convert between color formats (hex, RGB, HSL)'. It specifies the action (convert) and the resources involved (color formats), making the function immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'convert_timezone' beyond the domain difference, which is why it doesn't reach a perfect score.

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. It doesn't mention any prerequisites, limitations, or comparisons to other tools in the server (e.g., when to choose this over other conversion tools like 'convert_timezone'). The usage is implied by the purpose but lacks explicit context or exclusions.

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

convert_timezoneC

Convert datetime between timezones

ParametersJSON Schema
NameRequiredDescriptionDefault
datetimeYesDatetime string to convert
from_timezoneNoSource timezone (default: UTC)
to_timezoneYesTarget timezone
formatNoOutput format (optional)

TDQS

C2.9/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 but offers minimal information. It states the conversion action but doesn't cover error handling (e.g., invalid timezone names), performance aspects, or output specifics like default formats. This leaves significant gaps for an agent to understand tool behavior.

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 with a single, clear sentence that front-loads the core purpose without any wasted words. It efficiently communicates the essential function, making it easy for an agent to parse and understand quickly.

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?

Given the lack of annotations and output schema, the description is incomplete for a tool with four parameters and no structured behavioral hints. It doesn't explain return values, error cases, or usage constraints, leaving the agent with insufficient context to reliably invoke the tool beyond basic parameter passing.

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 schema fully documents all four parameters. The description adds no additional parameter semantics beyond implying datetime and timezone conversion, which is already covered by the schema. This meets the baseline score of 3 for high schema coverage without extra value from the description.

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 a specific verb ('convert') and resource ('datetime between timezones'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_current_datetime' or 'format_json', which could also handle datetime operations in different contexts.

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. It doesn't mention sibling tools like 'get_current_datetime' for current time operations or 'format_json' for datetime formatting, nor does it specify prerequisites or exclusions for timezone conversion scenarios.

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

decode_base64C

Decode Base64 string

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesBase64 string to decode
encodingNoOutput encoding (default: utf8)

TDQS

C2.9/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 the action ('decode') but lacks details on error handling (e.g., invalid Base64 input), performance characteristics, or output behavior (e.g., what happens with binary data). This is a significant gap for a tool with potential edge cases in decoding.

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 ('Decode Base64 string')—just three words—with zero wasted language. It is front-loaded and directly communicates the core function without unnecessary elaboration, making it efficient for quick understanding.

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?

Given the complexity of decoding operations (which can involve errors or varied outputs) and the lack of annotations and output schema, the description is incomplete. It doesn't cover what the tool returns (e.g., decoded string, error messages) or behavioral aspects like input validation, leaving gaps that could hinder correct usage by an AI agent.

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 clear descriptions for both parameters ('input' and 'encoding'), including an enum for 'encoding'. The description adds no additional parameter semantics beyond what the schema provides, such as examples of valid Base64 strings or guidance on choosing encodings. Baseline 3 is appropriate given the schema does the heavy lifting.

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 'Decode Base64 string' clearly states the verb ('decode') and resource ('Base64 string'), making the purpose immediately understandable. It distinguishes from sibling tools like 'encode_base64' by specifying the opposite operation, though it doesn't explicitly mention the output format or contrast with other decoding tools like 'decode_url'.

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. It doesn't mention scenarios where Base64 decoding is appropriate (e.g., handling encoded data from APIs or files) or when to choose other tools like 'decode_url' for URL decoding or 'analyze_logs' for log analysis involving encoded content.

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

decode_urlB

Decode URL-encoded string

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesURL-encoded string to decode
componentNoComponent type (default: full)

TDQS

B3.1/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 but only states the basic action. It doesn't cover important aspects like error handling (e.g., for malformed input), performance characteristics, or what the output looks like (e.g., decoded string format). This leaves gaps for an AI agent to understand tool behavior.

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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple utility tool, making it easy for an AI agent to parse quickly.

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 (a straightforward decoding operation) and the schema's full parameter coverage, the description is minimally adequate. However, with no output schema and no annotations, it lacks details on return values or behavioral traits, leaving room for improvement in completeness for reliable agent use.

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 input schema has 100% description coverage, with clear documentation for both parameters ('input' and 'component'), including an enum for 'component'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating for any schema gaps.

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 'Decode URL-encoded string' clearly states the verb (decode) and resource (URL-encoded string), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'encode_url', which performs the inverse operation, though the distinction is implied through the verb choice.

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. It doesn't mention sibling tools like 'decode_base64' for other encoding types or 'encode_url' for the reverse operation, nor does it specify contexts where URL decoding is needed (e.g., handling web data or query parameters).

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

encode_base64B

Encode string to Base64

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesString to encode
encodingNoInput encoding (default: utf8)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic function without mentioning error handling, performance characteristics, or output format details. It doesn't address whether invalid inputs cause errors or what the Base64 output looks like, which are important for an encoding operation.

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 at just four words, front-loading the core purpose with zero wasted language. Every word earns its place, making it efficient for quick comprehension without unnecessary elaboration.

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?

For a simple encoding tool with two parameters and no output schema, the description covers the basic purpose adequately. However, it lacks context about typical use cases, error scenarios, or output format, which would help an agent understand when and how to use it effectively. The absence of annotations means the description should do more heavy lifting.

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 has 100% description coverage, so parameters are fully documented in structured form. The description adds no additional parameter information beyond what's in the schema, which is acceptable given the high coverage. However, it doesn't explain the relationship between 'input' and 'encoding' parameters or provide usage examples.

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 a specific verb ('encode') and resource ('string to Base64'), making it immediately understandable. However, it doesn't explicitly differentiate from its sibling 'decode_base64' beyond the obvious inverse operation, which would require mentioning the complementary relationship for full clarity.

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 like 'encode_url' or 'hash_string', nor does it mention prerequisites or typical use cases. It states what the tool does but not when it's appropriate, leaving the agent to infer usage context.

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

encode_urlC

Encode string for URL (URL encoding)

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesString to encode
componentNoComponent type (default: full)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe important behavioral aspects like what encoding standard is used (e.g., percent-encoding), whether it handles Unicode characters, what happens with invalid input, or what the output format looks like. For a transformation tool with zero annotation coverage, this is insufficient.

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 with just one parenthetical phrase adding clarification. Every word earns its place, and it's front-loaded with the core purpose. There's zero waste or redundancy in this minimal description.

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?

Given this is a transformation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the encoded output looks like, what encoding standard is used, or provide any examples. For a tool that transforms data, users need to understand the output format, which isn't addressed.

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 schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions URL encoding generally but doesn't explain the 'component' parameter's significance or provide examples of when to use different component types.

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 verb ('encode') and resource ('string for URL'), specifying URL encoding as the operation. It distinguishes from sibling tools like encode_base64 by specifying URL encoding, but doesn't explicitly differentiate from decode_url beyond the obvious encode/decode 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?

No guidance is provided about when to use this tool versus alternatives. The description doesn't mention when URL encoding is needed, what scenarios require it, or how it differs from other encoding tools like encode_base64. There's no context about appropriate use cases.

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

format_bytesB

Format bytes to human-readable format (binary or decimal)

ParametersJSON Schema
NameRequiredDescriptionDefault
bytesYesNumber of bytes to format
formatNoFormat type: binary (1024-based) or decimal (1000-based) (default: binary)
precisionNoNumber of decimal places (0-10, default: 2)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the two format types (binary/decimal) but doesn't describe what 'human-readable format' means in practice (e.g., returns strings like '1.5 MB'), doesn't mention default behaviors beyond what's in the schema, and doesn't address edge cases like negative bytes or performance characteristics. For a tool with no annotation coverage, this leaves significant behavioral gaps.

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 - a single sentence that efficiently communicates the core functionality. Every word earns its place: 'Format bytes' (action), 'to human-readable format' (outcome), '(binary or decimal)' (key options). No wasted words or unnecessary elaboration for this straightforward utility tool.

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 this is a simple data formatting utility with 3 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. However, without annotations and with no output schema, the description should ideally clarify what 'human-readable format' returns (e.g., string with units) and mention any default behaviors. It's complete enough for basic understanding but lacks output details that would help the agent use it effectively.

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 schema already fully documents all three parameters (bytes, format, precision). The description adds minimal value beyond the schema - it mentions 'binary or decimal' which is already in the format parameter's enum description. No additional parameter semantics, examples, or constraints are provided beyond what's in the structured schema.

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: 'Format bytes to human-readable format' with the specific verb 'format' and resource 'bytes'. It distinguishes between 'binary or decimal' formats, though it doesn't explicitly differentiate from sibling tools like format_number or format_json. The purpose is specific but lacks sibling comparison context.

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. There's no mention of when this specific byte formatting is appropriate compared to other formatting tools (format_number, format_json) or conversion tools. The agent must infer usage from the tool name alone without contextual direction.

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

format_jsonC

Format, validate, minify, or prettify JSON

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesJSON string to process
actionYesAction to perform
indentNoNumber of spaces for indentation (0-10, default: 2)

TDQS

C2.9/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 full burden. It lists actions but doesn't disclose behavioral traits like error handling (e.g., what happens with invalid JSON), performance characteristics, side effects, or output format details. The description is functional but lacks operational context needed for informed tool selection.

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 with zero wasted words - a four-word phrase listing all key actions. It's front-loaded with all essential information and every word earns its place by specifying distinct functionalities. This is a model of efficiency for a multi-action utility tool.

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?

For a tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'format' versus 'prettify' means, how validation results are communicated, what minified output looks like, or error conditions. The agent lacks crucial context about tool behavior and outputs despite the complete parameter schema.

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%, providing complete parameter documentation. The description adds minimal value beyond the schema, only implying that 'input' is JSON and 'action' defines the operation type. It doesn't explain parameter interactions (e.g., 'indent' relevance to 'minify' vs 'prettify') or provide usage examples, meeting the baseline for high schema coverage.

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 (format, validate, minify, prettify) and resource (JSON). It distinguishes itself from siblings like format_bytes or format_text_case by specifying JSON as the target data format. However, it doesn't explicitly differentiate from potential JSON-specific siblings that might exist on other servers.

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. It doesn't mention prerequisites, when not to use it, or compare it to similar tools like validate_data or format_text_case for different data types. The agent must infer usage from the action enum and parameter descriptions alone.

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

format_numberB

Format numbers (currency, percentage, thousands separator, decimal)

ParametersJSON Schema
NameRequiredDescriptionDefault
numberYesNumber to format
formatYesFormat type
localeNoLocale (default: en-US)
currencyNoCurrency code for currency format (default: USD)
minimum_fraction_digitsNoMinimum fraction digits (0-20)
maximum_fraction_digitsNoMaximum fraction digits (0-20)

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 full burden. It states what the tool does but doesn't disclose behavioral traits like whether it's read-only, what happens with invalid inputs, performance characteristics, or what the output looks like. For a formatting tool with no annotation coverage, this leaves significant gaps in understanding the tool's behavior.

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 with all necessary information in a single parenthetical phrase. Every word earns its place, with no wasted text or unnecessary elaboration. The structure efficiently communicates the core functionality.

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 moderate complexity (6 parameters, no output schema, no annotations), the description is minimally complete. It covers what the tool does but lacks information about output format, error handling, or behavioral constraints. For a formatting utility that transforms data, more context about the result would be helpful, though the 100% schema coverage helps compensate.

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 schema already documents all 6 parameters thoroughly. The description adds minimal value beyond the schema - it lists the format types (which are already in the enum) but doesn't provide additional context about parameter interactions or usage patterns. Baseline 3 is appropriate when schema does the heavy lifting.

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: 'Format numbers' with specific format types listed (currency, percentage, thousands separator, decimal). It uses a specific verb ('format') and resource ('numbers'), though it doesn't explicitly distinguish from sibling tools like 'format_bytes' or 'format_json' beyond the number focus.

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. There's no mention of when to choose this over other formatting tools (like format_bytes for byte formatting) or when not to use it. Usage is implied by the format types listed but not explicitly stated.

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

format_text_caseB

Convert text to different case formats (camelCase, PascalCase, kebab-case, snake_case, CONSTANT_CASE, Title Case, lowercase, UPPERCASE)

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesText to convert
formatNoTarget format (optional, returns all formats by default)

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 full burden for behavioral disclosure. While it mentions the conversion action, it doesn't describe error handling, performance characteristics, or what happens with invalid inputs. The description is functional but lacks operational context needed for a mutation 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?

The description is extremely concise and front-loaded: the first clause states the core purpose, followed by a comprehensive list of supported formats. Every word serves a purpose with zero redundancy. The structure efficiently communicates both function and capabilities.

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 moderate complexity (text transformation with multiple formats) and 100% schema coverage but no annotations or output schema, the description is minimally adequate. It explains what the tool does but lacks information about return values, error conditions, or behavioral constraints that would be helpful for an agent.

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 schema already fully documents both parameters. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.

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: 'Convert text to different case formats' followed by a specific list of formats. It uses a specific verb ('Convert') and resource ('text'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'format_bytes' or 'format_json', which prevents a perfect score.

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. It doesn't mention any prerequisites, limitations, or comparison to sibling tools like 'format_bytes' or 'format_json'. The agent must infer usage from the tool name and description alone without explicit context.

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

generate_passwordB

Generate secure passwords with customizable options

ParametersJSON Schema
NameRequiredDescriptionDefault
lengthNoPassword length (8-128, default: 16)
include_uppercaseNoInclude uppercase letters (default: true)
include_lowercaseNoInclude lowercase letters (default: true)
include_numbersNoInclude numbers (default: true)
include_symbolsNoInclude symbols (default: true)
exclude_similarNoExclude similar characters (il1Lo0O) (default: false)

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'secure passwords' which implies security considerations, but doesn't specify what makes them secure (e.g., cryptographically random generation, entropy levels). It also doesn't mention output format, whether passwords are stored or ephemeral, or any rate limits. The description adds minimal behavioral context beyond the basic function.

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, efficient sentence that immediately communicates the core function. Every word earns its place: 'generate' (action), 'secure passwords' (resource), 'with customizable options' (key feature). There's no redundancy or unnecessary elaboration, making it optimally concise for this tool type.

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?

For a password generation tool with 6 well-documented parameters but no output schema and no annotations, the description is minimally adequate. It covers the what but not the how or why - missing details about security guarantees, output format, or integration considerations. The high schema coverage compensates for some gaps, but behavioral aspects remain underspecified.

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 schema already documents all 6 parameters thoroughly with descriptions, defaults, and constraints. The description adds no additional parameter semantics beyond 'customizable options' - it doesn't explain parameter interactions, trade-offs, or provide examples. This meets the baseline 3 when schema coverage is high.

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 verb ('generate') and resource ('secure passwords'), specifying the tool's function. It distinguishes from siblings like 'generate_random' by focusing specifically on password generation with customizable options. However, it doesn't explicitly contrast with 'generate_slug' or other generation tools, keeping it at a 4 rather than 5.

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 like 'generate_random' or 'hash_string'. There's no mention of prerequisites, typical use cases, or scenarios where other tools might be more appropriate. The phrase 'with customizable options' hints at flexibility but doesn't offer concrete usage context.

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

generate_randomC

Generate random data: UUID v4, hex strings, base64 strings, or raw bytes

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesType of random data to generate
lengthNoLength in bytes for hex/base64/bytes (8-128, default: generates all standard lengths)
formatNoFormat for UUID only (optional, returns all formats by default)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what types of data can be generated but doesn't mention important behavioral traits like whether generation is deterministic, what the default output format is, whether there are rate limits, or what happens with invalid parameters. For a tool with no annotation coverage, this leaves significant gaps.

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 - a single sentence that efficiently lists all four data generation options. Every word earns its place with zero waste. It's appropriately sized for a straightforward utility tool and front-loads the core functionality.

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?

Given no annotations and no output schema, the description should do more to explain what the tool returns. It mentions what can be generated but not what the output looks like (e.g., string format, encoding). For a data generation tool with 3 parameters and no structured output documentation, this leaves the agent guessing about return values.

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 schema already documents all three parameters thoroughly. The description mentions the four data types that map to the 'type' parameter enum but doesn't add meaningful semantic context beyond what the schema provides. No additional parameter guidance is given for length or format parameters.

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 verb 'generate' and the resource 'random data', listing specific types (UUID v4, hex strings, base64 strings, raw bytes). It distinguishes from siblings like generate_password or generate_slug by focusing on raw random data generation rather than structured outputs. However, it doesn't explicitly differentiate from all siblings in the list.

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. It doesn't mention when to choose generate_random over generate_password for security contexts or when raw bytes might be preferred over formatted strings. There's no explicit when/when-not usage or named alternatives.

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

generate_slugB

Generate URL-friendly slug from text

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesText to convert to slug
separatorNoSeparator character (default: -)
lowercaseNoConvert to lowercase (default: true)

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 full burden. It states the basic function but doesn't disclose behavioral traits like what transformations are applied (e.g., removing special characters, handling spaces), whether the operation is idempotent, error conditions, or output format. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple transformation tool. Every word earns its place without redundancy.

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 (simple text transformation), 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks details on behavioral aspects like transformation rules or output format, which would be helpful for an agent to use it correctly without trial and error.

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 schema already documents all three parameters thoroughly. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, edge cases, or provide examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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 'Generate URL-friendly slug from text' clearly states the verb ('generate'), resource ('slug'), and purpose ('URL-friendly'). It distinguishes from siblings like 'format_text_case' or 'generate_password' by specifying the specific transformation type. However, it doesn't explicitly differentiate from all possible text transformation tools beyond the sibling list provided.

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. It doesn't mention when slug generation is appropriate compared to other text formatting tools, nor does it specify any prerequisites or exclusions. The agent must infer usage from the purpose alone.

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

get_current_datetimeA

Get the current date and time in all available formats (UTC, date string, time string, datetime string, Unix timestamps, human-readable formats)

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool returns, not behavioral traits like performance, rate limits, or error handling. It mentions output formats but doesn't disclose if it's real-time, cached, or has any side effects, leaving gaps for a tool with potential time-sensitive behavior.

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 a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by explicitly noting the lack of parameters, but it avoids redundancy and wastes no words, earning a high score for brevity and clarity.

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 (0 params, no annotations, no output schema), the description is minimally adequate but incomplete. It covers the purpose and output formats but lacks behavioral context (e.g., real-time vs. cached, error cases). Without annotations or output schema, more detail on return values or usage constraints would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here, but doesn't explicitly state 'no parameters required,' so it slightly underperforms. Baseline for 0 params is 4, as the description doesn't need to compensate for schema gaps.

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 specific verb ('Get') and resource ('current date and time'), with explicit scope ('all available formats'). It distinguishes from siblings by focusing on datetime retrieval rather than analysis, conversion, generation, or validation operations.

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 context through 'all available formats,' suggesting this tool is for comprehensive datetime retrieval. However, it lacks explicit guidance on when to use this vs. alternatives like convert_timezone or generate_random for timestamps, and provides no exclusions or prerequisites.

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

get_os_versionB

Get the operating system version, platform information, and current user information

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 full burden for behavioral disclosure. While 'Get' implies a read-only operation, it doesn't explicitly state whether this requires permissions, whether it's safe to call frequently, what format the information returns in, or potential limitations. The description mentions what information is retrieved but not how it behaves or any constraints.

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, efficient sentence that directly states what the tool does. Every word earns its place - 'Get' (action), 'operating system version, platform information, and current user information' (resources retrieved). No wasted words or redundant information.

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?

For a simple, parameterless information retrieval tool with no output schema, the description is adequate but has gaps. It specifies what information is retrieved but doesn't describe the return format, structure, or any behavioral aspects. Given the simplicity of the tool (0 params, no annotations), the description meets minimum requirements but could be more complete by addressing output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage (empty schema). The description appropriately doesn't discuss parameters since none exist. It focuses instead on what information the tool retrieves, which is the correct emphasis for a parameterless tool.

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 ('Get') and resources ('operating system version, platform information, and current user information'). It distinguishes itself from siblings by focusing on system information retrieval rather than data transformation or analysis. However, it doesn't explicitly differentiate from potential similar tools like 'get_current_datetime' beyond the different data domains.

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. It doesn't mention prerequisites, context for usage, or comparison with sibling tools. While the tool's purpose is clear, there's no explicit 'when' or 'when not' guidance for an AI agent.

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

hash_stringB

Generate hash for a string (useful for .env file keys)

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesString to hash

TDQS

B3.3/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 mentions the tool 'generates a hash' but doesn't specify whether this is deterministic, what algorithm is used, if it's cryptographically secure, or what the output format looks like (e.g., hex, base64). For a hashing tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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: the core purpose is stated in the first phrase, and the additional context is brief and relevant. Every sentence earns its place without redundancy, making it efficient and easy to parse.

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 moderate complexity (hashing function), no annotations, no output schema, and 1 parameter with full schema coverage, the description is minimally adequate. It states what the tool does and hints at usage but lacks details on behavior (e.g., algorithm, output format) and doesn't fully compensate for the missing annotations, leaving room for improvement.

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 input schema has 100% description coverage, with the parameter 'input' documented as 'String to hash'. The description adds no additional parameter semantics beyond this, as it doesn't explain constraints like string length or character set. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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: 'Generate hash for a string' specifies both the action (generate hash) and the resource (string). It distinguishes from siblings like encode_base64 or generate_password by focusing specifically on hashing. However, it doesn't specify the hashing algorithm or output format, keeping it from a perfect score.

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 provides implied usage context with '(useful for .env file keys)', suggesting a specific application scenario. However, it doesn't explicitly state when to use this versus alternatives like generate_password (for security) or encode_base64 (for encoding), nor does it mention any prerequisites or exclusions. The guidance is helpful but incomplete.

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

validate_dataB

Validate data against various formats (email, url, ipv4, ipv6, domain, phone, credit-card, uuid, hex, base64, json)

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesData to validate
typeYesValidation type

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether validation is strict or lenient, what happens on failure (e.g., returns boolean vs error), performance characteristics, or rate limits. 'Validate' implies a read-only check, but details are lacking.

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, efficient sentence that front-loads the core purpose and enumerates all supported formats. Every word earns its place with zero redundancy, making it easy to scan and understand quickly.

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?

For a validation tool with 2 parameters, 100% schema coverage, and no output schema, the description is adequate but incomplete. It covers what formats are supported but lacks details on return values, error cases, or validation specifics. Given the simplicity, it meets minimum viability but leaves gaps an agent would need to infer.

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 parameters 'input' and 'type' are well-documented in the schema. The description adds value by listing all possible validation types, but doesn't explain parameter interactions or validation rules beyond what the enum provides. Baseline 3 is appropriate given high schema coverage.

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: 'Validate data against various formats' with a comprehensive list of supported formats. It specifies the verb (validate) and resource (data), though it doesn't explicitly differentiate from siblings like 'analyze_language' or 'format_json' which serve different purposes.

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. It doesn't mention prerequisites, error handling, or compare it to similar tools like 'format_json' or 'decode_base64' that might overlap in functionality. Usage context is implied but not explicit.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap; for example, analyze_language focuses on text language analysis while analyze_logs targets error detection in logs, and format_json handles JSON operations separate from format_text_case for text casing. The descriptions precisely differentiate their functions, eliminating any ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., analyze_language, convert_color, generate_password) using snake_case throughout. This uniformity makes the set predictable and easy to navigate, with no deviations in naming conventions.

Tool Count4/5

With 20 tools, the count is slightly high for a utility server but reasonable given the broad scope covering text analysis, encoding, formatting, and system info. Each tool serves a specific, non-redundant function, though it borders on being heavy compared to more focused servers.

Completeness4/5

The toolset comprehensively covers common utility operations like encoding/decoding, formatting, and validation, with no obvious gaps for its domain. Minor omissions might include more advanced data transformations or system monitoring tools, but core workflows are well-supported.

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

  • Local Utilities MCP Server

    aiforhumans
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides essential utility tools for text processing, file operations, hashing, temperature conversion, password generation, and date/time operations through a comprehensive MCP interface.
    MIT

  • Power Assist MCP Server

    BACH-AI-Tools
    A
    license
    B
    quality
    D
    maintenance
    Provides a comprehensive suite of utility tools for string manipulation, mathematical calculations, and array processing via the Power Assist API. It enables complex data transformations and validations including regex operations, statistical analysis, and collection management.
    41
    MIT

  • basic-mcp

    msilverblatt
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides a suite of deterministic tools for time calculations, math, and string manipulation that LLMs often struggle to perform accurately. It also includes utilities for secure randomness, data validation, and basic network operations like DNS lookups.
    11
    MIT

Appeared in Searches

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/Angry-Robot-Deals/mcp-sys8'

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