Skip to main content
Glama
rawr-ai

Filesystem MCP Server

json_validate

Validate JSON files against specified schemas, ensuring data integrity and compliance. Configure byte limits and strict validation modes for tailored results.

Instructions

Validate JSON data against a JSON schema. Requires maxBytes parameter (default 10KB) for the data file. Returns true if the JSON data is valid against the schema, or false if it is not. The path must be within allowed directories.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
allErrorsNoWhether to collect all validation errors or stop at first error
maxBytesYesMaximum bytes to read from the file. Must be a positive integer. Handler default: 10KB.
pathYesPath to the JSON file to validate
schemaPathYesPath to the JSON Schema file
strictNoWhether to enable strict mode validation (additionalProperties: false)

Implementation Reference

  • Main handler function for the json_validate tool. Parses arguments, reads JSON data and schema files, validates using Ajv JSON Schema validator, returns validation status and detailed errors.
    export async function handleJsonValidate(
      args: unknown,
      allowedDirectories: string[],
      symlinksMap: Map<string, string>,
      noFollowSymlinks: boolean
    ) {
      const parsed = parseArgs(JsonValidateArgsSchema, args, 'json_validate');
    
      const validPath = await validatePath(parsed.path, allowedDirectories, symlinksMap, noFollowSymlinks);
      const validSchemaPath = await validatePath(parsed.schemaPath, allowedDirectories, symlinksMap, noFollowSymlinks);
    
      try {
        // Read both the data and schema files
        const [jsonData, schemaData] = await Promise.all([
          readJsonFile(validPath, parsed.maxBytes),
          readJsonFile(validSchemaPath)
        ]);
    
        // Configure Ajv instance
        const ajv = new Ajv({
          allErrors: parsed.allErrors,
          strict: parsed.strict,
          validateSchema: true, // Validate the schema itself
          verbose: true // Include more detailed error information
        });
    
        try {
          // Compile and validate the schema itself first
          const validateSchema = ajv.compile(schemaData);
          
          // Validate the data
          const isValid = validateSchema(jsonData);
    
          // Prepare the validation result
          const result = {
            isValid,
            errors: isValid ? null : (validateSchema.errors as ErrorObject[])?.map(error => ({
              path: error.instancePath,
              keyword: error.keyword,
              message: error.message,
              params: error.params,
              schemaPath: error.schemaPath
            }))
          };
    
          return {
            content: [{
              type: "text",
              text: JSON.stringify(result, null, 2)
            }],
          };
        } catch (validationError) {
          // Handle schema compilation errors
          if (validationError instanceof Error) {
            throw new Error(`Schema validation failed: ${validationError.message}`);
          }
          throw validationError;
        }
      } catch (error) {
        if (error instanceof Error) {
          throw new Error(`JSON validation failed: ${error.message}`);
        }
        throw error;
      }
    }
  • TypeBox schema defining input parameters for json_validate: paths to data and schema files, maxBytes limit, strict mode, and allErrors option.
    export const JsonValidateArgsSchema = Type.Object({
      path: Type.String({ description: 'Path to the JSON file to validate' }),
      schemaPath: Type.String({ description: 'Path to the JSON Schema file' }),
      maxBytes: Type.Integer({
        minimum: 1,
        description: 'Maximum bytes to read from the file. Must be a positive integer. Handler default: 10KB.'
      }),
      strict: Type.Optional(Type.Boolean({
        default: false,
        description: 'Whether to enable strict mode validation (additionalProperties: false)'
      })),
      allErrors: Type.Optional(Type.Boolean({
        default: true,
        description: 'Whether to collect all validation errors or stop at first error'
      }))
    });
    export type JsonValidateArgs = Static<typeof JsonValidateArgsSchema>;
  • index.ts:291-292 (registration)
    Registers the json_validate handler function in the toolHandlers object, which is used to add the tool to the FastMCP server.
    json_validate: (a: unknown) =>
      handleJsonValidate(a, allowedDirectories, symlinksMap, noFollowSymlinks),
  • Maps the JsonValidateArgsSchema to the 'json_validate' tool name in the central toolSchemas export.
    json_validate: JsonValidateArgsSchema,
  • index.ts:332-332 (registration)
    Declares the json_validate tool metadata (name and description) in the allTools array used for server registration.
    { name: "json_validate", description: "Validate JSON" },
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the validation outcome (returns true/false), a default value for maxBytes (10KB), and a security constraint (path within allowed directories). However, it lacks details on error handling, performance implications, or rate limits, which would be beneficial for a tool with file operations.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded, with the core purpose stated first, followed by key parameters and constraints in clear sentences. Every sentence earns its place by adding necessary information without redundancy, making it efficient and easy to parse.

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

Completeness4/5

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

Given the tool's complexity (file-based JSON validation with security constraints) and no output schema, the description is mostly complete. It covers the purpose, key parameters, and constraints, but could improve by detailing the return format (e.g., error messages on failure) or handling of large files. With no annotations, it does well but has minor gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by mentioning the default for maxBytes and the path constraint, but it does not provide additional syntax or format details. This meets the baseline for high schema coverage.

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

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 with specific verb ('validate') and resource ('JSON data against a JSON schema'), distinguishing it from sibling tools like json_filter, json_query, or json_transform which perform different operations on JSON. It precisely communicates the validation function without ambiguity.

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 by mentioning 'The path must be within allowed directories,' which hints at a constraint, but it does not explicitly state when to use this tool versus alternatives like json_structure or json_query for schema-related tasks. No clear exclusions or named alternatives are provided, leaving some ambiguity about optimal use cases.

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

Install Server

Other Tools

Related Tools

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/rawr-ai/mcp-filesystem'

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