Skip to main content
Glama
flyanima

Open Search MCP

by flyanima

test_jsonplaceholder

Validate JSON data by testing JSONPlaceholder API endpoints like posts, users, and comments to ensure proper data structure and API functionality.

Instructions

Test JSONPlaceholder API for JSON data validation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpointNoJSONPlaceholder endpoint to testposts
idNoSpecific resource ID to fetch (optional)

Implementation Reference

  • The execute handler function for the 'test_jsonplaceholder' tool. It simulates JSONPlaceholder API calls using mock data based on the provided endpoint ('posts', 'users', 'comments') and optional id, returning structured success/error responses.
    execute: async (args: ToolInput): Promise<ToolOutput> => {
      try {
        const { endpoint = 'posts', id } = args;
        const baseUrl = 'https://jsonplaceholder.typicode.com';
        const url = id ? `${baseUrl}/${endpoint}/${id}` : `${baseUrl}/${endpoint}`;
    
        // Simulate API response
        const mockData = {
          posts: [{ id: 1, title: 'Test Post', body: 'Test content', userId: 1 }],
          users: [{ id: 1, name: 'Test User', email: 'test@example.com' }],
          comments: [{ id: 1, postId: 1, name: 'Test Comment', email: 'test@example.com', body: 'Test comment body' }]
        };
    
        return {
          success: true,
          data: {
            endpoint,
            url,
            response: mockData[endpoint as keyof typeof mockData] || [],
            status: 'success'
          },
          metadata: {
            tool: 'test_jsonplaceholder',
            timestamp: new Date().toISOString()
          }
        };
      } catch (error) {
        return {
          success: false,
          error: `JSONPlaceholder test failed: ${error instanceof Error ? error.message : String(error)}`,
          data: null
        };
      }
    }
  • Input schema definition for the 'test_jsonplaceholder' tool, specifying optional 'endpoint' (enum of JSONPlaceholder endpoints) and 'id' parameters.
    inputSchema: {
      type: 'object',
      properties: {
        endpoint: {
          type: 'string',
          enum: ['posts', 'users', 'comments', 'albums', 'photos', 'todos'],
          description: 'JSONPlaceholder endpoint to test',
          default: 'posts'
        },
        id: {
          type: 'number',
          description: 'Specific resource ID to fetch (optional)'
        }
      },
      required: []
    },
  • Tool registration block within registerJSONPlaceholderTools function, defining name, description, schema, and handler for 'test_jsonplaceholder'.
    registry.registerTool({
      name: 'test_jsonplaceholder',
      description: 'Test JSONPlaceholder API for JSON data validation',
      category: 'testing',
      source: 'JSONPlaceholder',
      inputSchema: {
        type: 'object',
        properties: {
          endpoint: {
            type: 'string',
            enum: ['posts', 'users', 'comments', 'albums', 'photos', 'todos'],
            description: 'JSONPlaceholder endpoint to test',
            default: 'posts'
          },
          id: {
            type: 'number',
            description: 'Specific resource ID to fetch (optional)'
          }
        },
        required: []
      },
      execute: async (args: ToolInput): Promise<ToolOutput> => {
        try {
          const { endpoint = 'posts', id } = args;
          const baseUrl = 'https://jsonplaceholder.typicode.com';
          const url = id ? `${baseUrl}/${endpoint}/${id}` : `${baseUrl}/${endpoint}`;
    
          // Simulate API response
          const mockData = {
            posts: [{ id: 1, title: 'Test Post', body: 'Test content', userId: 1 }],
            users: [{ id: 1, name: 'Test User', email: 'test@example.com' }],
            comments: [{ id: 1, postId: 1, name: 'Test Comment', email: 'test@example.com', body: 'Test comment body' }]
          };
    
          return {
            success: true,
            data: {
              endpoint,
              url,
              response: mockData[endpoint as keyof typeof mockData] || [],
              status: 'success'
            },
            metadata: {
              tool: 'test_jsonplaceholder',
              timestamp: new Date().toISOString()
            }
          };
        } catch (error) {
          return {
            success: false,
            error: `JSONPlaceholder test failed: ${error instanceof Error ? error.message : String(error)}`,
            data: null
          };
        }
      }
    });
  • src/index.ts:245-245 (registration)
    Main server registration call in OpenSearchMCPServer.registerAllTools() that invokes the registration of 'test_jsonplaceholder' (and test_httpbin).
    registerJSONPlaceholderTools(this.toolRegistry);    // 2 tools: test_jsonplaceholder, test_httpbin
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'test' and 'validation', implying a read-only operation that might involve checking data integrity, but doesn't specify whether it performs GET requests, validates responses, or has any side effects. It lacks details on rate limits, authentication needs, or error handling, leaving significant gaps in understanding the tool's behavior.

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

Conciseness4/5

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

The description is a single, concise sentence that directly states the tool's purpose. It is front-loaded with the main intent ('Test JSONPlaceholder API') and avoids unnecessary words. However, it could be slightly more informative without losing conciseness, such as specifying the action (e.g., 'fetch and validate').

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

Completeness2/5

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

Given the complexity of a testing tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'test' or 'validation' means in practice, what the expected output is, or how errors are handled. For a tool that likely involves API interactions, more context is needed to guide the agent effectively, making this description inadequate for full understanding.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting both parameters ('endpoint' and 'id') with enums and defaults. The description adds no additional meaning beyond what the schema provides, such as explaining how these parameters interact or what 'test' entails. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to given the schema's clarity.

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

Purpose3/5

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

The description states the tool 'Test JSONPlaceholder API for JSON data validation', which indicates a testing/validation purpose but is vague about the specific action. It mentions the API but doesn't specify what operation is performed (e.g., fetching, posting, validating). The description distinguishes from some siblings like 'jsonplaceholder_posts' by being a general test tool, but the purpose remains somewhat ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to use it over specific sibling tools like 'jsonplaceholder_posts' or 'jsonplaceholder_health_test', nor does it provide any context about prerequisites or typical use cases. The agent must infer usage from the tool name and parameters alone.

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

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/flyanima/open-search-mcp'

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