Skip to main content
Glama
deenesjakoruzh
MukundaKatta

agentcast-mcp

by MukundaKatta
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

agentcast-mcp

npm tests mcp

An MCP server that gives AI assistants the ability to enforce structured output: extract JSON from messy LLM text, gate it against a shape spec, and produce the retry feedback message when the model returns the wrong shape.

Built on top of @mukundakatta/agentcast. Works with Claude Desktop, Cursor, Cline, Windsurf, Zed, and any other MCP client.

Tools exposed

extract_json

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.

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

→

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

source is one of whole, fenced_json, fenced_plain, balanced_substring, or none.

validate_response

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.

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

→

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

build_retry_prompt

Given an attempt history, produce the validation-error feedback message agentcast appends to the conversation when the model returned the wrong shape. Codifies the "validation error as feedback" pattern for non-Node MCP clients that want to drive the same retry loop manually.

{
  "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: JSONShelf

Install

Claude Desktop

Add to claude_desktop_config.json:

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

Cursor / Cline / Windsurf / Zed

Same shape, in the appropriate mcp.json for your client. Most clients auto-discover via npx -y @mukundakatta/agentcast-mcp.

Local install

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

Why this matters

When an LLM is supposed to return structured data, it sometimes wraps the JSON in prose, fences, or hallucinated fields. Standard JSON.parse throws. Hand-rolled regex misses nested structure. This MCP server gives any model driving an agent a real handle on (1) pulling JSON out of the response, (2) checking it matches the expected shape, and (3) building the exact retry prompt that nudges the model to fix it on the next turn.

License

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. Dates show when Glama detected each change.

  1. 3 tool updatesv0.1.0
    • First observedbuild_retry_prompt
    • First observedextract_json
    • First observedvalidate_response
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • 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
    73
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MukundaKatta/agentcast-mcp'

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