toolkit-mcp-server
Публичный хостинг сервера: https://toolkit.caseyjhand.com/mcp
Инструменты
Семь инструментов. Пять всегда включены и не требуют настройки — утилиты чистых вычислений плюс поиск IP без SSRF. Два опрашивают хост-сервер и отсутствуют в tools/list, пока вы не включите их — закрыты по умолчанию.
Инструмент | Описание |
| Сгенерировать криптографический дайджест (sha256/sha512/sha1/md5) или выполнить сравнение значения с ожидаемым дайджестом с постоянным временем. |
| Создать криптостойкие случайные идентификаторы — UUIDv4, UUIDv7 или ULID — по одному или пакетами до 1000 штук. |
| Закодировать текст или URL в QR-код в виде SVG-разметки, PNG в base64 или строки, отображаемой в терминале. |
| Кодировать или декодировать значение в base64, base64url, hex или URL-процентное кодирование в любом направлении. |
| Разрешить публичный IP или доменное имя в географические и сетевые данные — страна, город, координаты, ASN, часовой пояс. |
| Ограничен, выключен по умолчанию. Сетевые диагностики только для чтения с хост-сервера — ping, traceroute, TCP-подключение или определение исходящего IP. |
| Ограничен, выключен по умолчанию. Сообщить аспект состояния системы хост-сервера — ОС, CPU, память, средняя нагрузка или сетевые интерфейсы. |
toolkit_hash_value
Сгенерировать дайджест или проверить значение на соответствие ожидаемому с постоянным временем.
operation:generate(дайджест в нижнем регистре hex) илиcompare(проверка с постоянным временем черезtimingSafeEqual)Алгоритмы:
sha256(по умолчанию) иsha512для безопасности;sha1иmd5представлены только для совместимости с контрольными суммами и целостностью файлов — никогда не используйте их для паролей или подписейinputEncodingчитаетvalueкакutf8(по умолчанию),hexилиbase64, поэтому двоичные данные пропускают этап декодированияКаноническое использование: сопоставление загруженного файла с контрольной суммой, опубликованной поставщиком
toolkit_generate_id
Создать криптостойкие случайные идентификаторы из CSPRNG платформы — правильный источник для идентификаторов, которые должны быть непредсказуемыми, в отличие от значений, придуманных моделью.
type:uuid_v4(случайный, по умолчанию),uuid_v7(упорядоченный по времени, сортируемый по созданию) илиulid(26-символьный Crockford base32, лексикографически сортируемый)countсоздаёт пакет до 1000 идентификаторов за один вызов; возвращаемый массивidsвсегда содержит ровноcountзначенийПакеты
uuid_v7иulidмонотонны — строго возрастают даже в пределах одной миллисекунды — поэтомуidsостаётся в порядке сортировки по созданиюТолько для чтения — создание ничего не меняет — но никогда не идемпотентно, поэтому клиент не будет кэшировать или дедуплицировать пакет
toolkit_generate_qr
Закодировать текст или URL в QR-код.
format:svg(встроенная разметка),png_base64(растровые данные сmimeTypeиbyteLength) илиterminal(строка из Unicode-блоков)errorCorrection(L/M/Q/H) обменивает ёмкость данных на устойчивость к повреждениям;marginзадаёт ширину тихой зоны;scaleзадаёт пиксели на модуль для растрового выводаВозвращаемый
version(1–40) отражает плотность закодированных данныхpng_base64также поступает как блок MCP-изображения, поэтому клиент, читающийcontent[], может отобразить код без декодированияstructuredContentОтрендеренный PNG ограничен 2048 пикселями по стороне —
(modules + 2 × margin) × scale— поэтому плотный символ с высокимscaleотклоняется с типизированной ошибкойraster_too_large, указывающей подходящий масштаб;svgиterminalне имеют ограниченийdataограничена 2953 байтами — абсолютный потолок (версия 40, уровень L, байтовый режим); полезная ёмкость ниже при более высоких уровняхerrorCorrection, поэтому входные данные, превышающие ёмкость, отклоняются с типизированной ошибкойdata_too_large, а не с общей ошибкой
toolkit_encode_value
Кодировать или декодировать значение в любом направлении.
encoding:base64,base64url(безопасный для URL алфавит),hexилиurl(процентное кодирование)operation:encode(сырой UTF-8 → кодировка) илиdecode(закодированное значение → текст)Некорректный вход декодирования возвращает типизированную ошибку
decode_failedс подсказкой по восстановлению, а не молчаливый результат «наилучшего усилия»
toolkit_geolocate_ip
Разрешить публичный IP или доменное имя в географические и сетевые данные.
Возвращает страну, регион, город, широту/долготу, ASN, владеющую организацию и часовой пояс
Флаги
proxy,hostingиmobileуказывают, является ли адрес прокси/VPN/выходом Tor, датацентровой сетью или мобильным оператором —trueна любом из них означает, что координаты описывают инфраструктуру, а не человека. Отсутствует, если провайдер не сообщает эти данныеДоменное имя сначала разрешается через DNS;
resolvedIpотражает фактически локализованный IP, аsourceуказывает отвечающего провайдераБез SSRF — сервер обращается к провайдеру, а не к цели; разрешённый IP повторно проверяется на частные диапазоны, а частные/зарезервированные адреса отклоняются (у них нет публичной геолокации)
Работает по принципу «наилучшего усилия» и ограничено провайдером: VPN, прокси, мобильный NAT и anycast не позволяют точно определить местоположение по IP, точность — максимум на уровне города, а отсутствующие поля сообщаются как неизвестные, а не выдумываются
Строки от провайдера обрезаются и очищаются от управляющих символов перед попаданием в ответ, поэтому текст из реестров (
org,isp,as) не может переполнить или испортить контекст моделиПо умолчанию без ключа (бесплатный уровень ip-api, который использует обычный HTTP — см.
TOOLKIT_GEO_BASE_URL); результаты кэшируются в памяти по разрешённому IP с фиксированным лимитом записей
toolkit_check_network
Ограничен — регистрируется только при TOOLKIT_ENABLE_NET_DIAGNOSTICS=true. Сетевые диагностики только для чтения с хост-сервера.
mode:ping(ICMP круговой путь),traceroute(путь до цели),connectivity(сырое TCP-подключение кtargetна портуport) илиpublic_ip(собственный исходящий IP хоста)Хост, который не отвечает, сообщается как
reachable: false— это корректный результат, а не ошибкаДиагностирует собственную сеть сервера, поэтому полезен в локальном или самостоятельно развёрнутом окружении; доступ к частной/зарезервированной/внутренней цели дополнительно требует
TOOLKIT_ALLOW_PRIVATE_NETWORK=true, что по умолчанию блокирует метаданные облачной конечной точки
toolkit_check_system
Ограничен — регистрируется только при TOOLKIT_ENABLE_SYSTEM_INFO=true. Сообщает аспект состояния системы хост-сервера, только для чтения.
what:os,cpu,memory,loadилиinterfacesЗа один вызов заполняется ровно один объект аспекта, соответствующий
whatОписывает хост, на котором запущен этот сервер, а не вызывающий клиент — имеет смысл в локальном или самостоятельно развёрнутом окружении; выключен по умолчанию, поскольку
osиinterfacesраскрывают топологию хоста и версии
Related MCP server: IT Tools MCP Server
Возможности
Построен на @cyanheads/mcp-ts-core:
Декларативные определения инструментов — один файл на инструмент, фреймворк обрабатывает регистрацию и валидацию
Единая обработка ошибок — обработчики выбрасывают исключения, фреймворк ловит, классифицирует и форматирует
Типизированные контракты ошибок — каждый подверженный ошибкам инструмент объявляет свои причины сбоев с подсказками по восстановлению, на которые агент может реагировать
Подключаемая аутентификация:
none,jwt,oauthСтруктурированное логирование с опциональной трассировкой OpenTelemetry
Транспорты STDIO и Streamable HTTP
Специфичные для набора инструментов:
Закрытое по умолчанию ограничение — два инструмента, опрашивающих хост, отсутствуют в
tools/list, если явно не включены, поэтому в хостинг-инстансе нет поверхности для SSRF или раскрытия информацииДвухуровневый сетевой шлюз — даже с включённой диагностикой частные/зарезервированные/loopback/link-local цели (включая метаданные облачной конечной точки) остаются заблокированными, пока не будет разрешён второй флаг
Примитивы на основе CSPRNG — идентификаторы и дайджесты берутся из криптоисточника платформы, а сравнение хешей выполняется с постоянным временем через
timingSafeEqualГеолокация без SSRF — сервер обращается к провайдеру, затем повторно проверяет разрешённый через DNS IP на частные диапазоны перед поиском, поэтому доменное имя не может перенаправить запрос на внутренний адрес
Вывод, удобный для агента:
Происхождение — геолокация возвращает разрешённый IP и имя отвечающего провайдера; отсутствующие поля от upstream сообщаются как неизвестные, никогда не выдумываются
Корректные результаты при недоступности — недостижимый хост возвращает
reachable: falseвместо ошибки, поэтому вызывающие разветвляются на основе данных, а не текста исключенияТипизированные причины сбоев — ошибки декодирования, отсутствующие дайджесты и заблокированные частные цели содержат структурированную причину и подсказку по восстановлению для следующего шага
Начало работы
Публичный хостинг-инстанс
Публичный инстанс доступен по адресу https://toolkit.caseyjhand.com/mcp — установка не требуется. Направьте любой MCP-клиент через Streamable HTTP:
{
"mcpServers": {
"toolkit-mcp-server": {
"type": "streamable-http",
"url": "https://toolkit.caseyjhand.com/mcp"
}
}
}Самостоятельное развёртывание / Локально
Добавьте следующее в файл конфигурации вашего MCP-клиента. Ключ API не требуется — пять постоянно включённых инструментов и бесплатный уровень геолокации без ключа работают «из коробки».
{
"mcpServers": {
"toolkit-mcp-server": {
"type": "stdio",
"command": "bunx",
"args": ["@cyanheads/toolkit-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info"
}
}
}
}Или с npx (Bun не требуется):
{
"mcpServers": {
"toolkit-mcp-server": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@cyanheads/toolkit-mcp-server@latest"],
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"MCP_LOG_LEVEL": "info"
}
}
}
}Или с Docker:
{
"mcpServers": {
"toolkit-mcp-server": {
"type": "stdio",
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "MCP_TRANSPORT_TYPE=stdio", "ghcr.io/cyanheads/toolkit-mcp-server:latest"]
}
}
}Чтобы включить ограниченные инструменты опроса хоста, добавьте их флаги в env (или -e для Docker):
"env": {
"MCP_TRANSPORT_TYPE": "stdio",
"TOOLKIT_ENABLE_NET_DIAGNOSTICS": "true",
"TOOLKIT_ENABLE_SYSTEM_INFO": "true"
}Для Streamable HTTP установите транспорт и запустите сервер:
MCP_TRANSPORT_TYPE=http MCP_HTTP_PORT=3010 bun run start:http
# Server listens at http://localhost:3010/mcpПредварительные требования
Bun v1.3.2 или выше (или Node.js v24+).
Ключ API не требуется — геолокация по умолчанию использует бесплатный уровень ip-api без ключа.
Установка
Клонируйте репозиторий:
git clone https://github.com/cyanheads/toolkit-mcp-server.gitПерейдите в каталог:
cd toolkit-mcp-serverУстановите зависимости:
bun installКонфигурация
Каждая переменная является опциональной. Специфичные для сервера параметры проверяются при запуске с помощью схемы Zod в src/config/server-config.ts.
Переменная | Описание | По умолчанию |
| Регистрирует закрытый инструмент |
|
| Регистрирует закрытый инструмент |
|
| При включенной диагностике сети разрешает частные/зарезервированные/петлевые цели. Второй явный шлюз. |
|
| API-ключ для конечной точки геолокации, если он требуется. | нет |
| Базовый URL для совместимой с ip-api конечной точки геолокации. Значение по умолчанию — HTTP без шифрования — конечная точка HTTPS от ip-api не входит в бесплатный уровень без ключа и отвечает |
|
| Время жизни кэша геолокации в памяти в секундах. |
|
| Максимальное количество запросов геолокации в минуту. |
|
| Транспорт: |
|
| Порт для HTTP-сервера. |
|
| Режим аутентификации: |
|
| Уровень журналирования (RFC 5424). |
|
| Включить инструментацию OpenTelemetry (спаны, метрики, журналы завершения). |
|
См. .env.example для полного списка опциональных переопределений.
Запуск сервера
Локальная разработка
Сборка и запуск:
# One-time build bun run rebuild # Run the built server bun run start:stdio # or bun run start:httpЗапуск проверок и тестов:
bun run devcheck # Lint, format, typecheck, security, changelog sync bun run test # Vitest test suite bun run lint:mcp # Validate MCP definitions against spec
Docker
docker build -t toolkit-mcp-server .
docker run --rm -e MCP_TRANSPORT_TYPE=http -p 3010:3010 toolkit-mcp-serverDockerfile по умолчанию использует HTTP-транспорт, режим сеанса без сохранения состояния и записывает журналы в /var/log/toolkit-mcp-server. Зависимости OpenTelemetry устанавливаются по умолчанию — соберите с --build-arg OTEL_ENABLED=false, чтобы их исключить.
Структура проекта
Каталог | Назначение |
| Точка входа |
| Парсинг и проверка специфичных для сервера переменных окружения с помощью Zod. |
| Определения инструментов ( |
| Служба геолокации — разрешение DNS, вызов провайдера с повторными попытками/отступлением, нормализация, кэш в памяти. |
| Служба сетевой диагностики плюс общий валидатор целей и классификатор частных диапазонов. |
| Модульные и интеграционные тесты, повторяющие структуру |
Руководство по разработке
См. CLAUDE.md / AGENTS.md для руководств по разработке и архитектурных правил. Краткая версия:
Обработчики выбрасывают исключения, фреймворк их перехватывает — без
try/catchв логике инструментовИспользуйте
ctx.logдля журналирования в рамках запроса,ctx.stateдля хранилища в рамках арендатораРегистрируйте новые инструменты в массивах
createApp()вsrc/index.tsДва инструмента проверки хоста регистрируются за своими флагами включения; шлюз сетевой цели проверяется после разрешения DNS — никогда не создавайте результат для нелокализуемой или недоступной цели
Участие
Приветствуются заявки и запросы на слияние. Запускайте проверки и тесты перед отправкой:
bun run devcheck
bun run testЛицензия
Apache-2.0 — подробности см. в LICENSE.
Available Tools
5 toolstoolkit_encode_valuetoolkit-mcp-server: encode valueARead-onlyIdempotentInspect
Encode or decode a value across base64, base64url, hex, or URL (percent) encoding, in either direction. Set operation to "encode" to transform raw UTF-8 text into the chosen encoding, or "decode" to recover the original bytes from an encoded value. Decoded bytes come back as UTF-8 text by default; set outputEncoding to "hex" or "base64" to receive them re-encoded instead, which is lossless for binary data and transcodes between encodings (a base64 digest to hex, for example). Decoding never substitutes replacement characters: bytes that are not valid UTF-8 text are reported as a recoverable error that points at outputEncoding. Whitespace in hex, base64, and base64url values is ignored, so line-wrapped MIME bodies and PEM bodies decode as-is (drop PEM's -----BEGIN/END----- lines, which are not base64). base64url uses the URL-safe alphabet (- and _ instead of + and /); url applies encodeURIComponent and percent-decoding. A value that is malformed for the chosen encoding is reported as a recoverable error, not a silent best-effort.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The value to transform — raw text for encode, an encoded string for decode. Whitespace is ignored when decoding hex, base64, or base64url; a url value is taken literally. | |
| encoding | Yes | The encoding to apply: base64, URL-safe base64url, hex, or URL percent-encoding. | |
| operation | Yes | "encode" transforms text into the encoding; "decode" recovers the bytes from an encoded value. | |
| outputEncoding | No | Decode only: how the recovered bytes are returned. utf8 (used when omitted) returns text and fails when the bytes are not valid UTF-8; hex and base64 return the raw bytes re-encoded, losslessly. Rejected when operation is "encode". |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| result | No | The transformed value: encoded text for encode; for decode, the recovered bytes as UTF-8 text, hex, or base64 per outputEncoding. |
| encoding | No | The encoding that was applied. |
| operation | No | The operation that was performed. |
| outputEncoding | No | How result renders the decoded bytes: utf8 text, hex, or base64. Present for operation "decode". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint/idempotentHint annotations by disclosing key behavior: decoding never substitutes replacement characters, malformed values produce recoverable errors, whitespace is ignored in certain encodings, base64url uses the URL-safe alphabet, and url uses encodeURIComponent. This is exactly the kind of behavioral context an agent needs beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence carries useful information, including edge cases, error behavior, and encoding-specific details. The first sentence front-loads the core purpose. It is dense rather than redundant, though it could be tightened slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity — four parameters, three enums, two operations, and multiple encoding formats — the description is remarkably complete. It covers error handling, whitespace tolerance, PEM/MIME scenarios, binary data handling, and output format options. With an output schema also present, nothing an agent needs to call and understand this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds substantial meaning to the parameters: it explains what "decode" returns by default, how outputEncoding enables lossless transcoding, how whitespace handling affects the value parameter, and which alphabet base64url uses. This is meaningful value beyond the schema's enumerated definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource combination: "Encode or decode a value across base64, base64url, hex, or URL (percent) encoding, in either direction." This unambiguously identifies the tool's operation and scope, and clearly separates it from siblings like hash_value or generate_id, which perform different transformations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: when to use "encode" vs "decode", and when to set outputEncoding. It also gives practical use cases like decoding base64 digests and PEM bodies. However, it does not explicitly name sibling tools or state when this tool should be preferred over them, though the context is strong enough that an agent can infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_generate_idtoolkit-mcp-server: generate idARead-onlyInspect
Mint cryptographically-random identifiers using the platform CSPRNG — the correct source for IDs that must be unpredictable, unlike model-generated values. type selects the format: uuid_v4 (random, the default), uuid_v7 (time-ordered, sortable by creation), or ulid (26-char Crockford-base32, lexicographically sortable). Set count to mint a batch in one call (up to 1000); the returned ids array always contains exactly count values and is never truncated. For uuid_v7 and ulid, a batch is monotonic — strictly increasing even within the same millisecond — so the ids array stays in sorted creation order; ids minted in the same millisecond are separated by random gaps, so no id in a batch can be derived from another. IDs from this tool feed into toolkit_generate_qr (pass ids[0] as data) to create a scannable code.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Identifier format: uuid_v4 (random), uuid_v7 (time-ordered), or ulid (sortable Crockford-base32). | uuid_v4 |
| count | No | How many identifiers to mint (1–1000). The full batch is always returned. |
Output Schema
| Name | Required | Description |
|---|---|---|
| ids | No | The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation), with random gaps between ids minted in the same millisecond. |
| type | No | The identifier format that was minted. |
| count | No | The number of identifiers minted (equals the requested count). |
| error | No | Present when the call failed. Absent on success. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description goes far beyond: it discloses the source (platform CSPRNG), output guarantees ('always contains exactly count values and is never truncated'), monotonic ordering for uuid_v7/ulid, strict increasing within the same millisecond, and the security property that 'no id in a batch can be derived from another'. This rich behavioral disclosure is not present in annotations and is critical for correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: purpose and source are front-loaded, then type semantics, batch behavior, ordering guarantees, and downstream integration. There is no fluff or repetition of schema verbatim; the description is dense but well-structured, guiding the agent from conceptual purpose to invocation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema and clear annotations, the description fully covers what an agent needs: when to use, format selection, batching limits, return-count guarantees, ordering behavior, and integration with a sibling. No critical information is missing, and the output schema handles return-shape details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful semantics beyond the schema: it explains the default (uuid_v4), clarifies each type's ordering properties, specifies 'up to 1000' for count, and introduces the guarantee that the full batch is always returned without truncation. This adds real value over the schema alone, though the schema already covers basic type and count limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Mint cryptographically-random identifiers using the platform CSPRNG' — a specific verb ('mint'), resource ('identifiers'), and method (CSPRNG). It distinguishes this tool from siblings by stating it is the correct source for unpredictable IDs and explicitly contrasts with 'model-generated values'. The purpose is unambiguous and differentiates from toolkit_hash_value, toolkit_encode_value, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says to use this tool when IDs 'must be unpredictable' and indicates 'unlike model-generated values' — an explicit when-not. It also provides a concrete downstream workflow: 'feed into toolkit_generate_qr (pass ids[0] as data)', which acts as a usage directive. Combined with format-selection guidance for type and batching with count, the agent knows exactly when and how to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_generate_qrtoolkit-mcp-server: generate QR codeARead-onlyIdempotentInspect
Encode text or a URL into a QR code. data is the content to encode (a link, a generated identifier such as toolkit_generate_id's ids[0], or any string). format selects the output: svg returns inline SVG markup sized in pixels, png_base64 returns base64-encoded PNG bytes (with mimeType and byteLength), and terminal returns plain Unicode half-block characters (no escape codes) for a monospace display, drawn for a dark background: light modules, quiet zone included, are blocks and dark modules are spaces. errorCorrection (L/M/Q/H) trades data capacity for damage tolerance, margin sets the quiet-zone width in modules, and scale sets pixels per module for svg and png_base64, so both are (modules + 2 × margin) × scale pixels per side. The returned version (1–40) reflects how dense the encoded data is. png_base64 rejects an image past 2048 px per side with a typed raster_too_large error, so a dense symbol needs a lower scale; svg is vector markup and carries no such limit.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The text or URL to encode, stored as UTF-8. Capacity is counted in bytes: 2953 UTF-8 bytes is the absolute ceiling (QR version 40, level L, byte mode). The 2953-character limit here is only an upper bound, since a non-ASCII character takes 2–4 bytes. Usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure. | |
| scale | No | Pixels per module for svg (its width and height) and png_base64. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32 there. | |
| format | No | Output format: svg markup, png_base64 (raster bytes), or terminal (plain Unicode half-blocks, drawn for a dark background). | svg |
| margin | No | Quiet-zone width in modules around the symbol. The spec recommends 4. | |
| errorCorrection | No | Error-correction level: L (~7% recoverable) to H (~30%). Higher tolerance lowers data capacity. | M |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| format | No | The format that was produced. |
| content | No | The QR artifact: SVG markup, the terminal half-block grid (newline-separated rows), or base64 PNG bytes for png_base64. |
| version | No | QR symbol version (1–40); higher versions hold denser data and indicate denser content. |
| mimeType | No | MIME type of content for image formats. Absent for the terminal format. |
| byteLength | No | Decoded byte size of the PNG. Present only for png_base64. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses significant behavioral detail: format-specific output shapes (SVG markup, base64 PNG bytes with mimeType and byteLength, terminal Unicode blocks), typed error conditions (data_too_large, raster_too_large), the pixel-size formula, and the version range reflecting data density. It even clarifies terminal rendering for dark backgrounds. This far exceeds what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense and front-loaded with the core purpose in the first sentence. Each subsequent sentence introduces a distinct parameter or constraint, and the flow from format to error behavior is logical. It is longer than two sentences, but given the three output formats and several interacting parameters, the length is justified without wasteful repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 3 formats, and a moderately complex output, the description is thorough: it covers all parameters, format-specific behaviors, encoding boundaries, and error conditions. An output schema exists, so return values are already documented. No critical information an agent needs to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already has 100% parameter coverage, the description adds meaningful semantics not present in the schema: how scale and margin combine into final image dimensions, which parameters are ignored by which format, how errorCorrection trades capacity against tolerance, and the pixel limit interaction with scale for png_base64. This elevates the description well above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Encode text or a URL into a QR code', which clearly states the tool's function. It goes beyond the title by naming concrete use cases (links, generated identifiers, strings) and enumerating the three output formats. Sibling tools like toolkit_encode_value, toolkit_generate_id, and toolkit_hash_value are clearly different in purpose, so an agent can distinguish this tool without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rich context for when to use the tool: what kinds of data are acceptable (links, identifiers, arbitrary strings), what each format yields, and how parameters interact. It does not explicitly state when not to use this tool or name alternative siblings for specific scenarios, but the sibling set is distinct enough that the usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_geolocate_iptoolkit-mcp-server: geolocate IPARead-onlyIdempotentInspect
Resolve a public IP or dotted hostname to country, region, city, coordinates, ASN, organization, timezone, and proxy/hosting/mobile flags. Supply target for one lookup or targets for an ordered batch, never both; blank target and empty targets are unset. Batches process the first 100 positions (duplicates retained) and disclose every remainder in unprocessedTargets; at most 1000 inputs are accepted. Each batch position reports its result or an error with recovery, so cached and local outcomes survive quota refusals. The provider is called directly, never the target. Hostnames are DNS-resolved and resolvedIp names the located address. Private/reserved addresses have no public geolocation. Results are best-effort, city-level at best; VPNs, proxies, mobile NAT, and anycast defeat IP-to-location. Read proxy, hosting, and mobile before trusting coordinates: true describes infrastructure, not the user. Absent metadata remains unknown. source names the provider. Single and batch quotas are independent; cache hits consume neither quota.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | One public IP or dotted hostname; mutually exclusive with nonempty targets. | |
| targets | No | Ordered public IPs or dotted hostnames; first 100 positions are served, every remainder is disclosed. Mutually exclusive with nonblank target. |
Output Schema
| Name | Required | Description |
|---|---|---|
| asn | No | Autonomous System number, e.g. "AS15169". Absent on providers that omit it. |
| org | No | Owning organization or ISP, e.g. "Google LLC". Absent when unknown. |
| city | No | City name. Absent when unknown. |
| error | No | Present when the call failed. Absent on success. |
| proxy | No | True when the address is a known proxy, VPN, or Tor exit — the location describes the exit node, not the user. Absent when the provider does not report it. |
| mobile | No | True when the address belongs to a mobile carrier network, where NAT can place the location far from the device. Absent when unreported. |
| region | No | Region or state name. Absent when unknown. |
| source | No | The provider that answered the lookup, e.g. "ip-api". |
| target | No | The target as supplied (IP or hostname). |
| country | No | Country name. Absent when the provider does not report it. |
| hosting | No | True when the address belongs to a hosting or datacenter network, so the location is a facility rather than a person. Absent when unreported. |
| results | No | Ordered results or failures for the first 100 input positions. |
| latitude | No | Latitude in decimal degrees. Absent when unknown. |
| timezone | No | IANA timezone, e.g. "America/Los_Angeles". Absent when unknown. |
| longitude | No | Longitude in decimal degrees. Absent when unknown. |
| resolvedIp | No | The IP that was actually located (a supplied hostname is resolved to this first). |
| countryCode | No | ISO 3166-1 alpha-2 country code. Absent when unknown. |
| failedCount | No | Number of failed processed targets. |
| unprocessedTargets | No | Every input position past the first 100; resubmit these targets in another batch. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnly/openWorld/idempotent; the description adds substantial behavior the annotations cannot convey: batches serve the first 100 positions (duplicates retained) and disclose the rest in unprocessedTargets, a 1000-input cap, per-position errors with recovery, independent single/batch quotas, cache hits consuming neither quota, and most importantly that the provider is called directly and never the target. It also states that private/reserved addresses have no public geolocation and that absent metadata stays unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph of roughly nine sentences, but the purpose and input-mode rules are front-loaded and each subsequent sentence carries non-redundant content (limits, quota behavior, accuracy caveats). It would benefit from light structuring, yet almost every sentence earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, yet the description still names the fields and explains source/resolvedIp semantics. Combined with quota rules, batch limits, mutual exclusivity, and accuracy caveats, an agent has everything needed to call this correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already fully documented, including mutual exclusivity and the blank-means-unset semantics. The description reinforces those points and adds one detail not in the schema (duplicates retained in a batch), but it adds little syntax or format meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource ("Resolve a public IP or dotted hostname") and enumerates exactly what is returned: country, region, city, coordinates, ASN, organization, timezone, and proxy/hosting/mobile flags. The sibling tools (generate_qr, hash_value, encode_value, generate_id) are unrelated utilities, so no sibling disambiguation is needed and none is missing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating rules: use target for one lookup or targets for a batch, never both; blank/empty values are treated as unset. It also supplies interpretation guidance ("Read proxy, hosting, and mobile before trusting coordinates") and warns that VPNs, proxies, mobile NAT, and anycast defeat IP-to-location. No alternative tool exists to route to, so the only gap is the absence of explicit when-not scenarios beyond the accuracy caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
toolkit_hash_valuetoolkit-mcp-server: hash valueARead-onlyIdempotentInspect
Generate a cryptographic digest of a value, or verify a value against an expected digest. Set operation to "generate" for a digest, or "compare" to constant-time-check value against the expected digest — compare is timing-safe and avoids manual string equality checks. Omitting operation compares when expected is supplied and generates otherwise. Algorithm defaults to sha256; sha384 and sha512 are also secure, while md5 and sha1 are exposed for checksum and file-integrity compatibility ONLY and must not be used for passwords, signatures, or any security purpose. digestEncoding selects the generated digest form: lowercase hex (default), base64, or sri (-, the npm lockfile integrity and Subresource Integrity form, sha256/sha384/sha512 only). expected is accepted as hex, base64, or SRI, recognized by its shape at the algorithm's digest length, so a published checksum can be pasted as-is; an SRI value may hold several space-separated entries, as an npm integrity field can, and matches when any entry for algorithm does. inputEncoding controls how value is read before hashing (utf8 default, or hex/base64 for raw binary data) so binary blobs need no decode round-trip. The canonical use is matching a download against a vendor-published checksum or a lockfile integrity entry.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | The data to hash, interpreted per inputEncoding (raw text by default). | |
| expected | No | The digest to compare against, as hex (any case), standard base64, or SRI (<algorithm>-<base64>); the form is recognized from its shape at the algorithm's digest length, and a string of only hex digits is always read as hex. An SRI value may carry several space-separated entries: entries for other algorithms are skipped, and it matches when any entry for algorithm matches. Supplying it with operation omitted runs a compare; it is rejected with operation "generate". | |
| algorithm | No | Digest algorithm. sha256 (default), sha384, or sha512 for security; md5/sha1 are checksum/compat only — not for security. | sha256 |
| operation | No | "generate" produces a digest; "compare" constant-time-checks value against expected. When omitted, resolves to "compare" if expected is supplied and "generate" otherwise. | |
| inputEncoding | No | How value is decoded before hashing: utf8 text, hex, or base64. | utf8 |
| digestEncoding | No | Form of the generated digest: lowercase hex (default), standard base64, or sri (<algorithm>-<base64>, sha256/sha384/sha512 only). Applies to operation "generate". | hex |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| digest | No | Digest of value in the requested digestEncoding: lowercase hex, base64, or <algorithm>-<base64>. Present for operation "generate". |
| matches | No | Constant-time equality of the computed digest against expected. Present for operation "compare". |
| algorithm | No | The algorithm used. |
| operation | No | The operation performed, after resolving an omitted operation. |
| lengthInBytes | No | Digest size in bytes (32 for sha256, 48 for sha384, 64 for sha512, 20 for sha1, 16 for md5). Present for "generate". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnly and idempotent. The description adds meaningful behavioral detail: constant-time comparison, security caveats for weak algorithms, flexible expected-format recognition, and SRI multi-entry matching. These go well beyond the annotations and give the agent a clear model of how the tool behaves without contradicting the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long (~150 words) but every sentence contributes a distinct piece of information: purpose, operation behavior, algorithm security, digest encoding, expected format handling, input encoding, and a canonical use case. It is front-loaded with the core purpose and then systematically covers each nuance. While it could be tightened, the density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not specify return values. It thoroughly covers all parameters, their defaults, and edge cases (omitted operation, SRI multi-entries, binary input). It does not mention error conditions or limits, but these are minor given the extensive guidance and the presence of structured schemas. Overall, an agent has enough context to invoke this tool correctly in typical scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter already has a description. The tool description enriches this by explaining the interaction between operation and expected (omission logic), the shape-based recognition of expected formats, the meaning of SRI, and the rationale for inputEncoding. This adds genuine value beyond the schema's individual property descriptions, making the parameter semantics clearer and more actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of both capabilities: 'Generate a cryptographic digest of a value, or verify a value against an expected digest.' It names the verb (generate/verify), the resource (value), and clearly distinguishes the two operations. This is far from a tautology and immediately separates it from sibling tools like encode or generate_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance: it explains the default operation resolution, warns against using md5/sha1 for security, and gives a canonical use case ('matching a download against a vendor-published checksum or a lockfile integrity entry'). It does not explicitly name alternatives or exclusions, but the unique function makes that less critical. The 'compare is timing-safe and avoids manual string equality checks' also informs when to use this tool over manual comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v2.3.3- Changed
toolkit_geolocate_ip10 fields changed- changed
Input schema / properties / target / anyOfPrevious value: -[ - { - "description": "A raw IPv4 address.", - "format": "ipv4", - "pattern": "^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])$", - "type": "string" - }, - { - "description": "A raw IPv6 address.", - "format": "ipv6", - "pattern": "^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:))$", - "type": "string" - }, - { - "description": "A dotted hostname, e.g. \"example.com\".", - "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(\\.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$", - "type": "string" - } -]New value: +[ + { + "description": "Blank means unset.", + "pattern": "^\\s*$", + "type": "string" + }, + { + "description": "A raw IPv4 address.", + "format": "ipv4", + "pattern": "^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])$", + "type": "string" + }, + { + "description": "A raw IPv6 address.", + "format": "ipv6", + "pattern": "^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:))$", + "type": "string" + }, + { + "description": "A dotted hostname, e.g. \"example.com\".", + "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(\\.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$", + "type": "string" + } +] - changed
Input schema / properties / target / descriptionPrevious value: -"A public IPv4/IPv6 address or a hostname (e.g. \"8.8.8.8\" or \"example.com\")."New value: +"One public IP or dotted hostname; mutually exclusive with nonempty targets." - added
Input schema / properties / targetsAdded value: +{ + "description": "Ordered public IPs or dotted hostnames; first 100 positions are served, every remainder is disclosed. Mutually exclusive with nonblank target.", + "items": { + "anyOf": [ + { + "description": "A raw IPv4 address.", + "format": "ipv4", + "pattern": "^(?:(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\\.){3}(?:25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])$", + "type": "string" + }, + { + "description": "A raw IPv6 address.", + "format": "ipv6", + "pattern": "^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,7}:|([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}|([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|:((:[0-9a-fA-F]{1,4}){1,7}|:))$", + "type": "string" + }, + { + "description": "A dotted hostname, e.g. \"example.com\".", + "pattern": "^[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(\\.[a-zA-Z0-9]([a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)+$", + "type": "string" + } + ], + "description": "A public IPv4/IPv6 address or a hostname (e.g. \"8.8.8.8\" or \"example.com\")." + }, + "maxItems": 1000, + "type": "array" +} - removed
Input schema / requiredRemoved value: -[ - "target" -] - changed
Output schema / anyOfPrevious value: -[ - { - "not": { - "required": [ - "error" - ] - }, - "required": [ - "target", - "resolvedIp", - "source" - ] - }, - { - "required": [ - "error" - ] - } -]New value: +[ + { + "not": { + "required": [ + "error" + ] + } + }, + { + "required": [ + "error" + ] + } +] - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `unresolvable_host`: A hostname target failed DNS resolution. `private_target`: The target resolves to a private/reserved IP with no public geolocation. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `rate_limited`: The endpoint request quota or provider cooldown is exhausted. `unresolvable_host`: A hostname target failed DNS resolution. `private_target`: The target resolves to a private/reserved IP with no public geolocation. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "unresolvable_host", - "private_target" -]New value: +[ + "rate_limited", + "unresolvable_host", + "private_target" +] - added
Output schema / properties / failedCountAdded value: +{ + "description": "Number of failed processed targets.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" +} - added
Output schema / properties / resultsAdded value: +{ + "description": "Ordered results or failures for the first 100 input positions.", + "items": { + "anyOf": [ + { + "additionalProperties": false, + "description": "Normalized geolocation metadata for one target.", + "properties": { + "asn": { + "description": "Autonomous System number, e.g. \"AS15169\". Absent on providers that omit it.", + "maxLength": 256, + "type": "string" + }, + "city": { + "description": "City name. Absent when unknown.", + "maxLength": 256, + "type": "string" + }, + "country": { + "description": "Country name. Absent when the provider does not report it.", + "maxLength": 256, + "type": "string" + }, + "countryCode": { + "description": "ISO 3166-1 alpha-2 country code. Absent when unknown.", + "maxLength": 256, + "type": "string" + }, + "hosting": { + "description": "True when the address belongs to a hosting or datacenter network, so the location is a facility rather than a person. Absent when unreported.", + "type": "boolean" + }, + "latitude": { + "description": "Latitude in decimal degrees. Absent when unknown.", + "type": "number" + }, + "longitude": { + "description": "Longitude in decimal degrees. Absent when unknown.", + "type": "number" + }, + "mobile": { + "description": "True when the address belongs to a mobile carrier network, where NAT can place the location far from the device. Absent when unreported.", + "type": "boolean" + }, + "org": { + "description": "Owning organization or ISP, e.g. \"Google LLC\". Absent when unknown.", + "maxLength": 256, + "type": "string" + }, + "proxy": { + "description": "True when the address is a known proxy, VPN, or Tor exit — the location describes the exit node, not the user. Absent when the provider does not report it.", + "type": "boolean" + }, + "region": { + "description": "Region or state name. Absent when unknown.", + "maxLength": 256, + "type": "string" + }, + "resolvedIp": { + "description": "The IP that was actually located (a supplied hostname is resolved to this first).", + "type": "string" + }, + "source": { + "description": "The provider that answered the lookup, e.g. \"ip-api\".", + "type": "string" + }, + "target": { + "description": "The target as supplied (IP or hostname).", + "type": "string" + }, + "timezone": { + "description": "IANA timezone, e.g. \"America/Los_Angeles\". Absent when unknown.", + "maxLength": 256, + "type": "string" + } + }, + "required": [ + "target", + "resolvedIp", + "source" + ], + "type": "object" + }, + { + "additionalProperties": false, + "description": "A failed batch target with recovery guidance.", + "properties": { + "error": { + "additionalProperties": false, + "description": "Failure for this input position.", + "properties": { + "message": { + "description": "Server-authored failure message.", + "type": "string" + }, + "reason": { + "description": "Why this target could not be located.", + "enum": [ + "unresolvable_host", + "private_target", + "rate_limited", + "provider_unavailable" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": false, + "description": "Recovery guidance for the failed target.", + "properties": { + "hint": { + "description": "How to recover this target lookup.", + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "waitTimeSeconds": { + "description": "Seconds to wait before retrying a rate-limited target.", + "type": "number" + } + }, + "required": [ + "reason", + "message", + "recovery" + ], + "type": "object" + }, + "target": { + "description": "The failed target as supplied.", + "type": "string" + } + }, + "required": [ + "target", + "error" + ], + "type": "object" + } + ], + "description": "Result or failure for one input position." + }, + "type": "array" +} - added
Output schema / properties / unprocessedTargetsAdded value: +{ + "description": "Every input position past the first 100; resubmit these targets in another batch.", + "items": { + "description": "One unprocessed target.", + "type": "string" + }, + "type": "array" +}
4 tool updates
v2.3.1- Changed
toolkit_encode_value7 fields changed- changed
Input schema / properties / operation / descriptionPrevious value: -"\"encode\" transforms text into the encoding; \"decode\" recovers text from an encoded value."New value: +"\"encode\" transforms text into the encoding; \"decode\" recovers the bytes from an encoded value." - added
Input schema / properties / outputEncodingAdded value: +{ + "description": "Decode only: how the recovered bytes are returned. utf8 (used when omitted) returns text and fails when the bytes are not valid UTF-8; hex and base64 return the raw bytes re-encoded, losslessly. Rejected when operation is \"encode\".", + "enum": [ + "utf8", + "hex", + "base64" + ], + "type": "string" +} - changed
Input schema / properties / value / descriptionPrevious value: -"The value to transform — raw text for encode, an encoded string for decode."New value: +"The value to transform — raw text for encode, an encoded string for decode. Whitespace is ignored when decoding hex, base64, or base64url; a url value is taken literally." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `decode_failed`: operation is \"decode\" but value is malformed for the chosen encoding. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `decode_failed`: operation is \"decode\" but value is malformed for the chosen encoding. `decode_not_utf8`: operation is \"decode\", outputEncoding is utf8 (or omitted), and the decoded bytes are not valid UTF-8 text. `output_encoding_not_applicable`: operation is \"encode\" and outputEncoding was supplied; it selects how decoded bytes are returned. Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "decode_failed" -]New value: +[ + "decode_failed", + "decode_not_utf8", + "output_encoding_not_applicable" +] - added
Output schema / properties / outputEncodingAdded value: +{ + "description": "How result renders the decoded bytes: utf8 text, hex, or base64. Present for operation \"decode\".", + "enum": [ + "utf8", + "hex", + "base64" + ], + "type": "string" +} - changed
Output schema / properties / result / descriptionPrevious value: -"The transformed value (encoded text, or the decoded original)."New value: +"The transformed value: encoded text for encode; for decode, the recovered bytes as UTF-8 text, hex, or base64 per outputEncoding."
- Changed
toolkit_generate_id1 field changed- changed
Output schema / properties / ids / descriptionPrevious value: -"The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation)."New value: +"The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation), with random gaps between ids minted in the same millisecond."
- Changed
toolkit_generate_qr4 fields changed- changed
Input schema / properties / data / descriptionPrevious value: -"The text or URL to encode. 2953 is the absolute ceiling (QR version 40, level L, byte mode); usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure."New value: +"The text or URL to encode, stored as UTF-8. Capacity is counted in bytes: 2953 UTF-8 bytes is the absolute ceiling (QR version 40, level L, byte mode). The 2953-character limit here is only an upper bound, since a non-ASCII character takes 2–4 bytes. Usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure." - changed
Input schema / properties / format / descriptionPrevious value: -"Output format: svg markup, png_base64 (raster bytes), or a terminal-renderable string."New value: +"Output format: svg markup, png_base64 (raster bytes), or terminal (plain Unicode half-blocks, drawn for a dark background)." - changed
Input schema / properties / scale / descriptionPrevious value: -"Pixels per module for raster (png_base64) output. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32."New value: +"Pixels per module for svg (its width and height) and png_base64. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32 there." - changed
Output schema / properties / content / descriptionPrevious value: -"The QR artifact: SVG markup, a terminal-renderable string, or base64 PNG bytes for png_base64."New value: +"The QR artifact: SVG markup, the terminal half-block grid (newline-separated rows), or base64 PNG bytes for png_base64."
- Changed
toolkit_hash_value13 fields changed- changed
Input schema / properties / algorithm / descriptionPrevious value: -"Digest algorithm. sha256 (default) or sha512 for security; md5/sha1 are checksum/compat only — not for security."New value: +"Digest algorithm. sha256 (default), sha384, or sha512 for security; md5/sha1 are checksum/compat only — not for security." - changed
Input schema / properties / algorithm / enumPrevious value: -[ - "sha256", - "sha512", - "sha1", - "md5" -]New value: +[ + "sha256", + "sha384", + "sha512", + "sha1", + "md5" +] - added
Input schema / properties / digestEncodingAdded value: +{ + "default": "hex", + "description": "Form of the generated digest: lowercase hex (default), standard base64, or sri (<algorithm>-<base64>, sha256/sha384/sha512 only). Applies to operation \"generate\".", + "enum": [ + "hex", + "base64", + "sri" + ], + "type": "string" +} - changed
Input schema / properties / expected / descriptionPrevious value: -"The expected lowercase-hex digest to compare against. Required when operation is \"compare\"."New value: +"The digest to compare against, as hex (any case), standard base64, or SRI (<algorithm>-<base64>); the form is recognized from its shape at the algorithm's digest length, and a string of only hex digits is always read as hex. An SRI value may carry several space-separated entries: entries for other algorithms are skipped, and it matches when any entry for algorithm matches. Supplying it with operation omitted runs a compare; it is rejected with operation \"generate\"." - changed
Input schema / properties / inputEncoding / descriptionPrevious value: -"How value (and expected's pre-image, when relevant) is decoded before hashing: utf8 text, hex, or base64."New value: +"How value is decoded before hashing: utf8 text, hex, or base64." - removed
Input schema / properties / operation / defaultRemoved value: -"generate" - changed
Input schema / properties / operation / descriptionPrevious value: -"\"generate\" produces a digest; \"compare\" constant-time-checks value against expected."New value: +"\"generate\" produces a digest; \"compare\" constant-time-checks value against expected. When omitted, resolves to \"compare\" if expected is supplied and \"generate\" otherwise." - changed
Output schema / properties / algorithm / enumPrevious value: -[ - "sha256", - "sha512", - "sha1", - "md5" -]New value: +[ + "sha256", + "sha384", + "sha512", + "sha1", + "md5" +] - changed
Output schema / properties / digest / descriptionPrevious value: -"Lowercase-hex digest of value. Present for operation \"generate\"."New value: +"Digest of value in the requested digestEncoding: lowercase hex, base64, or <algorithm>-<base64>. Present for operation \"generate\"." - changed
Output schema / properties / error / properties / data / properties / reason / descriptionPrevious value: -"Machine-readable failure mode. Declared by this tool: `missing_expected`: operation is \"compare\" but no expected digest was supplied. `expected_length_mismatch`: The expected digest length does not match the algorithm, so compare would always fail. `invalid_input_encoding`: value is not valid for the declared inputEncoding (e.g. non-hex characters with inputEncoding \"hex\"). Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `missing_expected`: operation is \"compare\" but no expected digest was supplied. `expected_without_compare`: operation is \"generate\" but an expected digest was also supplied, so it would be ignored. `expected_malformed`: expected is not a hex, standard base64, or sha256/sha384/sha512 SRI digest, or an SRI value holds a token that is not an SRI entry. `expected_length_mismatch`: expected is a recognized digest form but its length does not match the algorithm, so compare would always fail. `expected_algorithm_mismatch`: expected is SRI and none of its entries names the chosen algorithm. `sri_unsupported_algorithm`: digestEncoding is \"sri\" and algorithm is md5 or sha1, which SRI does not define. `invalid_input_encoding`: value is not valid for the declared inputEncoding (e.g. non-hex characters with inputEncoding \"hex\"). Other values are possible when a failure originates below the handler." - changed
Output schema / properties / error / properties / data / properties / reason / examplesPrevious value: -[ - "missing_expected", - "expected_length_mismatch", - "invalid_input_encoding" -]New value: +[ + "missing_expected", + "expected_without_compare", + "expected_malformed", + "expected_length_mismatch", + "expected_algorithm_mismatch", + "sri_unsupported_algorithm", + "invalid_input_encoding" +] - changed
Output schema / properties / lengthInBytes / descriptionPrevious value: -"Digest size in bytes (32 for sha256, 64 for sha512, 20 for sha1, 16 for md5). Present for \"generate\"."New value: +"Digest size in bytes (32 for sha256, 48 for sha384, 64 for sha512, 20 for sha1, 16 for md5). Present for \"generate\"." - changed
Output schema / properties / operation / descriptionPrevious value: -"The operation performed."New value: +"The operation performed, after resolving an omitted operation."
5 tool updates
v2.2.2- Changed
toolkit_encode_value6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "encoding", + "operation", + "result" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `decode_failed`: operation is \"decode\" but value is malformed for the chosen encoding. Other values are possible when a failure originates below the handler.", + "examples": [ + "decode_failed" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "encoding", - "operation", - "result" -]
- Changed
toolkit_generate_id6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "type", + "ids", + "count" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode.", + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "type", - "ids", - "count" -]
- Changed
toolkit_generate_qr6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "format", + "content", + "version" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `data_too_large`: data exceeds the QR capacity for the chosen errorCorrection level and encoding mode. `raster_too_large`: format is png_base64 and (modules + 2 × margin) × scale exceeds the pixel budget. Other values are possible when a failure originates below the handler.", + "examples": [ + "data_too_large", + "raster_too_large" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "format", - "content", - "version" -]
- Changed
toolkit_geolocate_ip6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "target", + "resolvedIp", + "source" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `unresolvable_host`: A hostname target failed DNS resolution. `private_target`: The target resolves to a private/reserved IP with no public geolocation. Other values are possible when a failure originates below the handler.", + "examples": [ + "unresolvable_host", + "private_target" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "target", - "resolvedIp", - "source" -]
- Changed
toolkit_hash_value6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "algorithm", + "operation" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `missing_expected`: operation is \"compare\" but no expected digest was supplied. `expected_length_mismatch`: The expected digest length does not match the algorithm, so compare would always fail. `invalid_input_encoding`: value is not valid for the declared inputEncoding (e.g. non-hex characters with inputEncoding \"hex\"). Other values are possible when a failure originates below the handler.", + "examples": [ + "missing_expected", + "expected_length_mismatch", + "invalid_input_encoding" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "algorithm", - "operation" -]
2 tool updates
v2.2.0- Changed
toolkit_generate_qr1 field changed- changed
Input schema / properties / scale / descriptionPrevious value: -"Pixels per module for raster (png_base64) output. Ignored for terminal."New value: +"Pixels per module for raster (png_base64) output. Ignored for terminal. png_base64 also bounds the whole image at 2048 px per side, so a dense symbol or a wide margin admits a lower scale than 32."
- Changed
toolkit_geolocate_ip10 fields changed- added
Output schema / properties / asn / maxLengthAdded value: +256 - added
Output schema / properties / city / maxLengthAdded value: +256 - added
Output schema / properties / country / maxLengthAdded value: +256 - added
Output schema / properties / countryCode / maxLengthAdded value: +256 - added
Output schema / properties / hostingAdded value: +{ + "description": "True when the address belongs to a hosting or datacenter network, so the location is a facility rather than a person. Absent when unreported.", + "type": "boolean" +} - added
Output schema / properties / mobileAdded value: +{ + "description": "True when the address belongs to a mobile carrier network, where NAT can place the location far from the device. Absent when unreported.", + "type": "boolean" +} - added
Output schema / properties / org / maxLengthAdded value: +256 - added
Output schema / properties / proxyAdded value: +{ + "description": "True when the address is a known proxy, VPN, or Tor exit — the location describes the exit node, not the user. Absent when the provider does not report it.", + "type": "boolean" +} - added
Output schema / properties / region / maxLengthAdded value: +256 - added
Output schema / properties / timezone / maxLengthAdded value: +256
2 tool updates
v2.0.1- Changed
toolkit_generate_id1 field changed- changed
Output schema / properties / ids / descriptionPrevious value: -"The minted identifiers — exactly count of them, in mint order."New value: +"The minted identifiers — exactly count of them, in mint order; for uuid_v7 and ulid that order is strictly increasing (sorted by creation)."
- Changed
toolkit_generate_qr1 field changed- changed
Input schema / properties / data / descriptionPrevious value: -"The text or URL to encode. Capped at 2953 bytes — the absolute QR capacity (version 40, level L)."New value: +"The text or URL to encode. 2953 is the absolute ceiling (QR version 40, level L, byte mode); usable capacity drops at higher errorCorrection levels, so over-capacity data is rejected with a typed data_too_large error rather than a generic failure."
21 tool updates
v2.0.0- Removed
checkConnectivity - Removed
clearGeoCache - Removed
compareHashes - Removed
convertTimezone - Removed
generateQRCode - Removed
generateUUID - Removed
geolocate - Removed
getCurrentTime - Removed
getLoadAverage - Removed
getNetworkInterfaces - Removed
getPublicIP - Removed
getSystemInfo - Removed
hashData - Removed
listTimezones - Removed
pingHost - Added
toolkit_encode_value - Added
toolkit_generate_id - Added
toolkit_generate_qr - Added
toolkit_geolocate_ip - Added
toolkit_hash_value - Removed
traceroute
16 tool updates
- First observed
checkConnectivity - First observed
clearGeoCache - First observed
compareHashes - First observed
convertTimezone - First observed
generateQRCode - First observed
generateUUID - First observed
geolocate - First observed
getCurrentTime - First observed
getLoadAverage - First observed
getNetworkInterfaces - First observed
getPublicIP - First observed
getSystemInfo - First observed
hashData - First observed
listTimezones - First observed
pingHost - First observed
traceroute
TDQS
Scored across 5 tools
Each tool targets a distinct utility: QR generation, cryptographic hashing, IP geolocation, encoding/decoding, and ID generation. There is no functional overlap that would cause misselection, and selectors like hash vs encode are clearly separated by purpose.
All tools follow a consistent toolkit_<verb>_<noun> pattern (generate_qr, hash_value, geolocate_ip, encode_value, generate_id). Verb choices are predictable and readable throughout.
Five tools is a well-scoped set for a miscellaneous utility toolkit. Each tool earns its place as an independent, non-redundant capability.
Each tool internally covers its operation well (e.g., hash generate/compare, encode/decode both directions, batch geolocation, batched ID minting). As a general 'toolkit' there is no canonical lifecycle to fully satisfy, but minor adjacent utilities (e.g., timestamp/date formatting) are absent.
Maintenance
Related MCP Connectors
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA comprehensive Model Context Protocol server implementation that enables AI assistants to interact with file systems, databases, GitHub repositories, web resources, and system tools while maintaining security and control.32 npm2MIT
- AlicenseBqualityFmaintenanceA comprehensive Model Context Protocol server providing access to 70+ IT tools for developers and system administrators, including encoding/decoding, text manipulation, hashing, and network utilities.100171 npm22TypeScriptMIT
- FlicenseNot gradedqualityCmaintenanceA secure Model Context Protocol server providing HTTP endpoints for AI agent tool execution, including file system operations, shell commands, and LLM-based code generation.1-
- AlicenseAqualityDmaintenanceA Model Context Protocol server providing network diagnostic tools for AI agents, including connectivity testing, batch operations, local network info, and pcap analysis.345MIT