Entalpa Requirements MCP

Stories Get

stories_get

Read-onlyIdempotent

Get a story by UUID.

Input Schema

Name	Required	Description	Default
`story_id`	Yes	Story UUID.
`project_id`	Yes	Project UUID (database id).

Output Schema

Name	Required	Description
`extra`	No	Optional free-form metadata object.
`content`	Yes	Story text.
`human_id`	Yes	Story human label (e.g. S-3), for creation and display.
`story_id`	Yes	Story UUID (database id).
`project_id`	Yes	Project UUID (database id).
`requirement_ids`	Yes	List of requirement UUIDs (database ids), not content.id.
`stakeholder_ids`	Yes	List of stakeholder UUIDs.
`lifecycle_rollup`	Yes	How the requirements underneath are distributed across lifecycle values.
`outdated_requirement_ids`	No	Requirements written from an earlier text of this story, which may no longer match it. Re-propagating the story revisits them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

addedOutput schema / properties / human_id

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

changedOutput schema / 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

B3.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety and idempotency profile. The description adds no behavioral context beyond what those annotations and the output schema provide, such as project scoping or side-effect details.

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 front-loaded sentence with no wasted words. It is arguably under-sized for a tool with two required parameters, but it is not verbose or poorly structured.

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 simple get operation, 100% schema coverage, rich annotations, and an output schema, the description is nearly sufficient. Its main gap is the lack of routing guidance against sibling retrieval tools, but the structured fields carry most of the burden.

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 both parameters are fully documented by the schema itself. The description adds no meaning beyond the schema; its 'by UUID' phrase maps only to story_id and omits the required project_id.

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 states a specific verb ('Get') and resource ('a story') and implies singular retrieval by UUID, which distinguishes it from siblings like stories_list and stories_get_many. However, it does not explicitly differentiate itself from those alternatives by name or clarify that project scoping is required.

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 such as stories_get_many, stories_list, or stories_update. Usage is only implied by the singular 'a story' phrasing.

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?