Entalpa Requirements MCP

Projects Export

projects_export

Read-onlyIdempotent

Export a project to the portable format projects_import reads. Chat is opt-in; version 4 uses typed file-local links, with pending actions removed. format: yaml returns the same export as a YAML document (with a suggested filename) for committing to a repository; it imports the same way once parsed.

Input Schema

Name	Required	Description
`format`	No	json (default) returns the export as structured data. yaml returns it as a YAML document, readable in a diff, for committing to a repository.
`project_id`	Yes	Project UUID (database id).
`include_chat_messages`	No	Include the project's chat history. Off by default, so a file meant for sharing or a repository carries no transcript.

Output Schema

Name	Required	Description
`title`	No
`format`	No
`stories`	No
`document`	No	The export, rendered as YAML.
`filename`	No	A suggested file name.
`chosen_llm`	No	The model the project used. A hint: import uses it when this install offers that model, and its default otherwise.
`subsystems`	No
`description`	No	The project description. Read as design_description in files before schema version 3.
`requirements`	No
`stakeholders`	No
`chat_messages`	No	Optional transcript. In version 4, entalpa:<kind>/local/<encoded human_id> links bind only to imported entities of that kind; legacy/unresolved links stay unbound. Pending actions are stripped. Before version 3: messages.
`open_questions`	No
`schema_version`	No	4 adds typed file-local chat references remapped to fresh UUIDs on import. Earlier versions remain readable; ordinary document relationships retain human IDs.
`assessment_score`	No	Accepted project completeness assessment, from 0 to 100.
`assessment_details`	No	Accepted explanation of the project assessment.
`interface_contracts`	No
`extra_requirement_attributes`	No	The requirement attributes this project generates. Absent when the project never chose a list, which is not the same as choosing an empty one: absent shows every content field, [] shows only the core ones.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 20, 2026

addedOutput schema / properties / assessment_details

Added value: +{
+  "description": "Accepted explanation of the project assessment.",
+  "type": "string"
+}

addedOutput schema / properties / assessment_score

Added value: +{
+  "description": "Accepted project completeness assessment, from 0 to 100.",
+  "type": "integer"
+}

addedOutput schema / properties / open_questions

Added value: +{
+  "items": {
+    "properties": {
+      "answer": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "human_id": {
+        "type": "string"
+      },
+      "question": {
+        "type": "string"
+      },
+      "rationale": {
+        "type": "string"
+      },
+      "resulting_story_id": {
+        "description": "Human id of the story its answer was converted into.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "status": {
+        "description": "open, answered or dismissed.",
+        "type": "string"
+      },
+      "story_id": {
+        "description": "Human id of the story the question was raised about.",
+        "type": [
+          "string",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "human_id",
+      "question"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / requirements / items / properties / lifecycle

Added value: +{
+  "description": "draft, in_review, reviewed, in_progress, implemented, verified, blocked, rejected or superseded. Absent in files written before it existed; import then reads content.implementation_status.",
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover read-only and idempotent behavior, but the description adds real context: chat is opt-in, version 4 emits typed file-local links, and pending actions are stripped from the export. These are non-obvious transformation traits an agent cannot derive from annotations or schema.

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?

Three front-loaded sentences with no filler, leading with the core purpose and the round-trip relationship. The version-4 internals are slightly dense but every clause conveys actionable information.

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?

With an output schema present, return-value detail is unnecessary, and annotations cover the safety profile. The description complements these by explaining the chat opt-in default and format consequences, leaving little an agent needs to call it correctly.

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 and the enum. The description largely restates the format behavior ("yaml returns the same export as a YAML document ... imports the same way once parsed") rather than adding syntax or semantics beyond the schema, so 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 ("Export a project") and identifies the counterpart tool it feeds ("the portable format projects_import reads"). It does not distinguish itself from the sibling exporters projects_export_openspec and projects_export_speckit, which an agent might otherwise pick, but the core purpose is unambiguous.

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

Usage Guidelines3/5

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

Provides a use case for the yaml format ("for committing to a repository") and notes round-trip compatibility with projects_import, implying when to reach for it. However, it never states when to choose this over the export_openspec/export_speckit alternatives or the plain JSON default, leaving selection to inference.

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?