JSONPlaceholder MCP Server

create_post

Create simulated posts for testing and prototyping by providing title, body, and user ID data in a development environment.

Instructions

Create a new post (simulated - JSONPlaceholder doesn't actually store data)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "title": "<title>",
      "body": "<body>",
      "user_id": "<user_id>"
    },
    "name": "create_post"
  }
}

Input Schema

Name	Required	Description	Default
`title`	Yes
`body`	Yes
`user_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jan 26, 2026

TDQS

B3/5.0

Behavior3/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 states this is a creation tool, implying mutation, and adds that it's simulated with no actual data storage, which is useful context about the tool's behavior. However, it lacks details on permissions, response format, or error handling, leaving gaps for a mutation 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?

The description is a single, efficient sentence that front-loads the core action ('Create a new post') and includes a brief, relevant note about simulation. Every word earns its place, with no redundancy or unnecessary elaboration.

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 mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the simulated nature but misses critical details like parameter explanations, return values, or error conditions, making it inadequate for full agent understanding.

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

Parameters2/5

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

The schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It provides no information about the three required parameters (title, body, user_id), such as their meaning, constraints, or examples, failing to add value beyond the bare schema.

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

Purpose4/5

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

The description clearly states the verb ('Create') and resource ('new post'), making the purpose specific and understandable. However, it doesn't distinguish this tool from potential siblings like 'search_posts' or 'get_posts' beyond the creation action, and the parenthetical note about simulation adds context but doesn't affect the core purpose clarity.

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 like 'get_posts' or 'search_posts'. It mentions that JSONPlaceholder doesn't actually store data, which hints at a simulated environment, but offers no explicit usage rules, prerequisites, or exclusions for tool selection.

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

Deploy Server