ProdPad MCP Server

Create User Story for Idea

prodpad_create_idea_userstory

Create a user story for an existing ProdPad idea using its ID and story text, with optional acceptance criteria to define requirements.

Instructions

Create a new user story for an idea.

Args:

id (string): Numeric ID of the idea (required)
story (string): The user story text, e.g. 'As a [persona], I want [feature], so that [benefit]' (required)
acceptance_criteria (string): Acceptance criteria for the story

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": {
      "id": "<id>",
      "story": "<story>"
    },
    "name": "prodpad_create_idea_userstory"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Numeric ID of the idea
`story`	Yes	The user story text (e.g. 'As a [persona], I want [feature], so that [benefit]')
`acceptance_criteria`	No	Acceptance criteria for the user story

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 13, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations declare a write operation (readOnlyHint=false, idempotentHint=false), so the agent knows this mutates state and is non-idempotent. The description adds nothing beyond that: no note on whether the parent idea must exist, what happens on duplicate stories, or what the response returns. Given annotations carry the safety profile, this remains a thin disclosure.

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

Conciseness3/5

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

Front-loads the purpose in one sentence, which is good, but the args list largely duplicates the schema. It is not wasteful enough to penalize heavily, yet it doesn't earn its lines by adding value.

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?

A create tool with no output schema and no mutation-behavior details. The essential calling information (required params, formats) is present via the schema, but the description omits return shape, error conditions, and sibling disambiguation. Adequate but with clear 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 three parameters including the story-format example. The description restates the parameters and repeats the example verbatim, adding no meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: 'Create a new user story for an idea.' The relationship to the parent idea (via id) is clear. However, it doesn't explicitly distinguish these idea-scoped stories from the sibling prodpad_create_userstory, leaving some ambiguity about which creation tool to pick.

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 when-to-use guidance. With both prodpad_create_userstory and prodpad_create_idea_userstory as siblings, the description never explains when this idea-scoped variant is the right choice versus the generic one. No prerequisites or exclusions are stated.

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