Entalpa Requirements MCP

Open Questions Convert To Story

open_questions_convert_to_story

Write an answered open question's decision into the backlog. A question asked about a story usually revises that story (action "revise"); a question about the whole project can revise the story whose goal its answer settles (revises_story_id). Otherwise, or when the answer settles a different goal, it becomes a new story. The text and the action are drafted for you when content is omitted; pass dry_run to read the draft (with the story's previous text, and any reviewed requirements to revisit) without changing anything, then pass content, action and revises_story_id back. action without content drafts for that action instead of letting the model choose. A new story is aligned to stakeholders unless run_align_to_story is false; when that fails, the story is saved all the same and alignment_failure says why. Fails with 409 if the question is unanswered or already converted.

Input Schema

Name	Required	Description
`action`	No	With content: "revise" rewrites the story the question was asked about (or, for a question about the whole project, the story in revises_story_id) with content; "new" (the default) adds a story. Pass back the action a dry run returned, or override it.
`content`	No	Story text to use. Omit to have it drafted from the question and answer.
`dry_run`	No	If true, return the drafted story text without creating the story.
`human_id`	No	Story human label (e.g. S-3), for creation and display.
`project_id`	Yes	Project UUID (database id).
`open_question_id`	Yes	Open question UUID (database id).
`revises_story_id`	No	UUID of the story to revise, as returned by the dry run. For a story-scoped question it must match the associated story.
`run_align_to_story`	No	If true, run the align_to_story LLM job after saving the story.

Output Schema

Name	Required	Description
`story`	No	Story summary fields.
`action`	Yes	"revise": content replaces the story in revises_story_id (the one the question was asked about, or the one its answer settles). "new": content is a new story.
`content`	Yes	Story text to use. Omit to have it drafted from the question and answer.
`question`	No	Open question summary fields.
`previous_content`	No	For a revision: the story's text before it.
`revises_story_id`	No	For a revision: UUID of the story it rewrites.
`alignment_failure`	No	For a new story: why it could not be aligned to stakeholders. The story and the question's link to it are saved all the same, so converting again is refused; align it with stories_update and `run_align_to_story: true`.
`requirement_labels`	No	Human labels keyed by UUID for requirements_to_revisit.
`revises_story_label`	No	For a revision: human story label for display.
`requirements_to_revisit`	No	For a revision of a story whose requirements are reviewed or further along: those requirements, which the changed story may no longer match.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

addedOutput schema / properties / story / properties / human_id

Added value: +{
+  "description": "Story human label (e.g. S-3), for creation and display.",
+  "type": "string"
+}

changedOutput schema / properties / story / required

Previous value: -[
-  "story_id",
-  "project_id",
-  "content",
-  "requirement_ids",
-  "stakeholder_ids",
-  "lifecycle_rollup"
-]New value: +[
+  "story_id",
+  "human_id",
+  "project_id",
+  "content",
+  "requirement_ids",
+  "stakeholder_ids",
+  "lifecycle_rollup"
+]

First observedOct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false); the description adds substantial behavior beyond them: text/action are auto-drafted when content is omitted, dry_run previews the draft including prior text and reviewed requirements, alignment failures still save the story and surface via alignment_failure, and 409 fires on unanswered/already-converted questions.

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?

Front-loaded with the core purpose and outcome branching, and every sentence carries actionable information. It is dense and somewhat run-on across five sentences, but there is little wasted text.

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

Completeness5/5

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

An output schema exists so return values needn't be re-explained, and the description still covers the mutation semantics, dry-run preview flow, alignment failure handling, and error condition. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: how action interacts with content and revises_story_id (including the project-scoped vs story-scoped rule), that passing action without content drafts for that action, and that action/revises_story_id should be passed back from a dry run.

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?

States a specific verb and resource: 'Write an answered open question's decision into the backlog,' then explains the two concrete outcomes (revise an existing story or create a new one). This clearly distinguishes it from siblings like stories_create and open_questions_answer without opening any schema.

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

Usage Guidelines5/5

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

Explicitly routes the agent: a story-scoped question 'usually revises that story,' a project-scoped question revises the settled story via revises_story_id, and 'otherwise... it becomes a new story.' It also states when to omit content (drafting), when to pass dry_run, and what the 409 failure conditions are.

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

All Entalpa Requirements MCP tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?