Skip to main content
Glama
deenesjakoruzh
MukundaKatta

agentcast-mcp

by MukundaKatta
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

agentcast-mcp

npm tests mcp

MCP-сервер (MCP), который дает ИИ-ассистентам возможность обеспечивать структурированный вывод: извлекать JSON из «грязного» текста LLM, проверять его на соответствие спецификации формы и создавать сообщение с обратной связью для повторной попытки, когда модель возвращает неверную форму.

Построен на базе @mukundakatta/agentcast. Работает с Claude Desktop, Cursor, Cline, Windsurf, Zed и любым другим MCP-клиентом.

Предоставляемые инструменты

extract_json

Извлекает значение JSON из «грязного» вывода LLM. Сначала пытается обработать весь текст, затем блок ```json ```, затем самую большую сбалансированную подстроку {...} / [...]. Возвращает разобранное значение и стратегию, которая сработала.

{
  "text": "Sure, here you go:\n```json\n{\"answer\": 42}\n```\nLet me know!"
}

→

{
  "value": { "answer": 42 },
  "found": true,
  "source": "fenced_json"
}

source может принимать значения whole, fenced_json, fenced_plain, balanced_substring или none.

validate_response

Проверяет разобранное значение JSON на соответствие спецификации формы agentcast. Спецификация сопоставляет имя поля с типом: string, number, boolean, array, object. Добавьте ? для необязательных полей.

{
  "value": { "name": "ada" },
  "shape": { "name": "string", "age": "number" }
}

→

{
  "valid": false,
  "error": "missing required field 'age'"
}

build_retry_prompt

На основе истории попыток создает сообщение с обратной связью об ошибке валидации, которое agentcast добавляет в диалог, когда модель возвращает неверную форму. Кодифицирует паттерн «ошибка валидации как обратная связь» для MCP-клиентов не на Node, которые хотят управлять тем же циклом повторных попыток вручную.

{
  "attempts": [
    { "text": "{\"name\":\"ada\"}", "error": "missing required field 'age'" }
  ],
  "expected_shape": { "name": "string", "age": "number" }
}

→

{
  "feedback": "Your previous response did not match the required shape. Error: missing required field 'age'\n\nTry again. Respond with ONLY valid JSON that fixes the error above.\n\nExpected shape: {\"name\":\"string\",\"age\":\"number\"}"
}

Related MCP server: json-sanity

Установка

Claude Desktop

Добавьте в claude_desktop_config.json:

{
  "mcpServers": {
    "agentcast": {
      "command": "npx",
      "args": ["-y", "@mukundakatta/agentcast-mcp"]
    }
  }
}

Cursor / Cline / Windsurf / Zed

Аналогичная структура в соответствующем файле mcp.json для вашего клиента. Большинство клиентов автоматически обнаруживают сервер через npx -y @mukundakatta/agentcast-mcp.

Локальная установка

npm install -g @mukundakatta/agentcast-mcp
mcp-agentcast        # listens on stdio

Почему это важно

Когда LLM должна вернуть структурированные данные, она иногда оборачивает JSON в прозу, блоки или галлюцинирует поля. Стандартный JSON.parse вызывает ошибку. Самописные регулярные выражения не справляются с вложенными структурами. Этот MCP-сервер дает любой модели, управляющей агентом, реальный инструмент для (1) извлечения JSON из ответа, (2) проверки соответствия ожидаемой форме и (3) создания точной подсказки для повторной попытки, которая подталкивает модель исправить ошибку на следующем шаге.

Лицензия

MIT.

Available Tools

3 tools
build_retry_promptA

Given an attempt history, produce the retry feedback message agentcast would append to the conversation when the model returned the wrong shape. Codifies the "validation error as feedback" pattern for non-Node MCP clients.

ParametersJSON Schema
NameRequiredDescriptionDefault
attemptsYesList of prior attempts. Each item should have the assistant text plus either a parsed value or an error string.
expected_shapeNoOptional agentcast shape spec to include in the feedback for extra grounding.

TDQS

A3.5/5.0
Behavior3/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. It discloses that the tool generates a retry feedback message, but does not detail the output structure, side effects (assumed none), or error behavior. Lacks specifics beyond the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences. The first front-loads the main action, the second adds context. No redundant or unnecessary words.

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?

The description explains the type of input (attempt history) and the pattern it codifies, but fails to mention the output format or any return value. Given the nested parameters and no output schema, the description is incomplete for full 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%, providing detailed explanations for both parameters (attempts, expected_shape). The description adds contextual value by framing the tool's purpose as retry feedback, but does not introduce new parameter semantics beyond what the schema offers. Baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's purpose: 'produce the retry feedback message' for when the model returned the wrong shape. It specifies the context (non-Node MCP clients) and distinguishes it from siblings (extract_json and validate_response) which focus on extraction or validation, not feedback generation.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention when-not to use it or provide comparisons to sibling tools. It only implies the scenario (validation error pattern) but lacks direct usage directives.

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

extract_jsonA

Pull a JSON value out of messy LLM output. Tries the whole text, then a fenced json block, then the largest balanced {...}/[...] substring. Returns the parsed value plus which strategy succeeded.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesFree-form text from an LLM that may contain JSON anywhere inside.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It transparently explains the fallback strategy: tries whole text, then fenced block, then largest balanced substring, and returns the parsed value plus which strategy succeeded. This is sufficiently detailed for a read-only cleanup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two concise sentences, front-loaded with purpose and followed by strategy. Every sentence adds value with no wasted words. Easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, no nested objects, no output schema), the description is fairly complete. It explains the return value (parsed value plus strategy). The absence of an output schema is mitigated by the description's mention of the return 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?

Schema coverage is 100% with a clear parameter description. The description adds value by explaining how the text parameter is processed (the extraction strategy), which goes beyond the schema's basic description.

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 purpose: 'Pull a JSON value out of messy LLM output.' It specifies the verb and resource, and the context of use (LLM output). It distinguishes itself from siblings by focusing on JSON extraction, while siblings deal with retry and validation.

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 when extracting JSON from messy LLM output, but does not explicitly state when not to use it or mention alternative tools. No exclusion criteria or when-to-use guidance beyond the implied context.

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

validate_responseA

Validate a parsed JSON value against an agentcast shape spec. Spec maps field name to type: 'string', 'number', 'boolean', 'array', 'object'. Suffix with '?' for optional. Returns valid=true on success, or valid=false with a human-readable error string suitable for retry feedback.

ParametersJSON Schema
NameRequiredDescriptionDefault
shapeYesShape spec: { fieldName: 'string' | 'number' | 'boolean' | 'array' | 'object', ... }. Append '?' for optional fields, e.g. { name: 'string', age: 'number?' }.
valueYesThe parsed JSON value to validate (any shape).

TDQS

A4.3/5.0
Behavior4/5

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

Discloses return format, spec details, optional fields, and error string suitability for retry. No annotations provided, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two sentences, front-loaded purpose, no wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers validation logic, shape format, return values, and ties to retry feedback. Could mention what happens if input is not parsed JSON, but overall sufficient.

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

Parameters5/5

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

Adds meaning beyond schema: explains shape spec format, optional field syntax, and return behavior. Schema coverage is 100% but description enriches understanding.

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 explicitly states it validates a parsed JSON value against a shape spec, with clear return behavior. It distinguishes from sibling tools (extract_json, build_retry_prompt) by focusing on validation.

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?

Implicitly indicates use for validation after parsing, but no explicit when-to-use, when-not, or comparison to siblings.

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. 3 tool updatesv0.1.0
    • First observedbuild_retry_prompt
    • First observedextract_json
    • First observedvalidate_response
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: build_retry_prompt handles feedback generation, extract_json extracts JSON from text, and validate_response checks JSON against a spec. There is no functional overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (build_retry_prompt, extract_json, validate_response), making them predictable and easy to understand.

Tool Count4/5

With only 3 tools, the server is slightly underpopulated but still appropriately scoped for the narrow domain of agent response validation and retry feedback. It covers the core workflow without unnecessary bloat.

Completeness4/5

The tools cover the essential pipeline of extracting JSON, validating it against a spec, and generating retry feedback. A minor gap is the lack of explicit handling of attempt history beyond what build_retry_prompt expects, but that is assumed provided by the client.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • json-sanity

    peak-agent
    A
    license
    Not graded
    quality
    D
    maintenance
    Deterministic JSON validation and repair for AI agents. Validates, repairs, schema-checks, and diffs JSON so long-running agents don't corrupt their session state with malformed writes.
    MIT
  • perf-mcp by Perf-Technology

    perf-mcpofficial

    Perf-Technology
    A
    license
    A
    quality
    D
    maintenance
    Fact-checks and fixes AI outputs by catching hallucinations, repairing broken JSON, and correcting errors before they reach users, with tools for verification, validation, and correction.
    4
    45 npm
    MIT
  • genpark-structured-extract-schema-validator-skill by alphaparkinc

    genpark-structured-extractofficial

    alphaparkinc
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables agents to deterministically extract structured entities from input payloads and validate or coerce them against JSON schemas, returning a standardized response dossier with execution telemetry. It runs as a zero-dependency MCP server that plugs into Claude Desktop, Cursor, and other MCP clients.
    8
    -