Entalpa Requirements MCP

Projects Import

projects_import

Import a project from the portable format projects_export writes. Version 4 chat links bind to fresh imported UUIDs; pending actions are discarded. Files from earlier schema versions import too; legacy chat links stay unbound.

Input Schema

Name	Required	Description	Default
`data`	Yes

Output Schema

Name	Required	Description
`title`	Yes	Project title (1-255 characters).
`can_redo`	Yes	True if a redo operation is available.
`can_undo`	Yes	True if an undo operation is available.
`chosen_llm`	No	The name of the LLM model chosen for the project (e.g. CLAUDE_4_5_SONNET).
`created_at`	No	Project creation timestamp (ISO 8601).
`project_id`	Yes	Project UUID (database id).
`usage_cost`	No	Accumulated usage cost as a decimal string.
`stories_count`	Yes	Number of stories in the project.
`messages_count`	Yes	Number of messages in the project history.
`unresolved_links`	Yes	Unbound document links. entity_id is a file-local label, or the zero-based transcript row for chat_message; missing_id is the unresolved reference.
`design_description`	No	Project description or design notes.
`requirements_count`	Yes	Number of requirements in the project.
`extra_requirement_fields`	No	List of extra requirement fields.
`interface_contracts_count`	Yes	Number of interface contracts in the project.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 20, 2026

addedInput schema / properties / data / properties / assessment_details

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

addedInput schema / properties / data / properties / assessment_score

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

changedInput schema / properties / data / properties / extra_requirement_attributes / description

Previous value: -"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."New value: +"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. Files before schema version 3 wrote null for absent."

changedInput schema / properties / data / properties / extra_requirement_attributes / type
```
Previous value: -"array"New value: +[
+  "array",
+  "null"
+]
```

addedInput schema / properties / data / 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"
+}

addedInput schema / properties / data / 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 declare a non-readonly, non-destructive mutation, and the description adds real behavioral detail beyond that: pending actions are discarded, version-4 chat links rebind to fresh UUIDs, and legacy/unresolved links stay unbound. It does not disclose overwrite/duplicate-name behavior or id-remapping consequences for ordinary documents.

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 compact sentences with no filler and the core purpose front-loaded, followed by version-compatibility specifics. Each sentence carries information, though the third sentence overlaps somewhat with the chat-link clause of the second.

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?

An output schema exists and annotations cover the mutation/safety profile, so the description need not explain return values. Coverage of version compatibility, chat-link rebinding, and discarded pending actions makes it largely sufficient, with only conflict/overwrite behavior at import time left unstated.

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?

The single `data` parameter has no top-level schema description (0% coverage), so the description must carry it, and it only says the payload comes from the projects_export portable format. The nested schema does document field semantics richly, but the description adds little about the top-level document shape or required fields.

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+resource ('Import a project') and anchors it to a named counterpart format written by projects_export, which an agent can map directly. It distinguishes the tool from the format-specific siblings only implicitly (portable projects_export format vs. the openspec/speckit importers), so sibling differentiation is not fully explicit.

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?

Usage is implied rather than stated: 'the portable format projects_export writes' tells the agent this is the counterpart to export, but there is no when-to-use/when-not-to-use guidance and no routing toward projects_import_openspec or projects_import_speckit for other formats.

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?