Entalpa Requirements MCP

Projects Review With Pack

projects_review_with_pack

Check a project with a pack: an expert's checklist (privacy, security, accessibility, payments, or the user's own) whose concerns are read against this project's stories, requirements and questions. Name the pack by a pack_id from packs_list as pack_project_id, or by the public_share_url of a published pack. Every concern gets a verdict: asked (a new question), deferred (needs a question after these are answered), already_asked, covered (by the listed requirements, stories or questions), not_relevant (with the reason), or unchecked. Adds up to twice as many open questions as the pack has concerns, already saved, and changes nothing else; do not create them again. Show the user the questions and the counts. They answer with open_questions_answer, and turn an answer into a story with open_questions_convert_to_story. Checking again later says what changed since (previous_verdict). Requires editing the project. Uses AI and spends credits; may take a few minutes.

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": {
      "project_id": "<project_id>"
    },
    "name": "projects_review_with_pack"
  }
}

Input Schema

Name	Required	Description
`project_id`	Yes	Project UUID (database id).
`pack_project_id`	No	UUID of the pack: a pack_id from packs_list.
`public_share_url`	No	The public link of a published pack on this Entalpa instance.

Output Schema

Name	Required	Description
`counts`	Yes	Concerns per verdict.
`pack_id`	No	The pack's project UUID; absent once the pack is deleted.
`concerns`	Yes	Every concern of the pack, in its order.
`questions`	Yes	The questions this review raised, already saved.
`review_id`	Yes	Pack review UUID.
`created_at`	Yes	When the review ran (ISO 8601).
`pack_title`	Yes
`project_id`	Yes	Project UUID (database id).
`pack_version`	No	The published version read; absent for a pack read as it is now.
`previous_review_at`	No	When this project was last checked with the same pack, if it was.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing concrete side effects: it adds up to twice as many open questions as the pack has concerns, already saved, and changes nothing else. It also states it requires editing the project, uses AI, spends credits, and may take a few minutes — rich behavioral context an agent needs before invoking.

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 action and pack definition, then layers verdicts, side effects, and follow-ups. It is dense and somewhat run-on, but nearly every sentence carries actionable information, so little is wasted.

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?

For a complex, AI-driven, credit-spending tool, the description covers the verdict taxonomy, side effects, cost/latency, follow-up tools, and re-check behavior. With an output schema present, return values need not be explained, so nothing essential 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 coverage is 100%, so the schema already documents all three parameters. The description adds value by explaining where pack_project_id comes from (packs_list) and that exactly one of pack_project_id or public_share_url must be supplied, reinforcing the mutual-exclusivity constraint.

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 ('Check a project with a pack') and immediately defines the pack as an expert checklist whose concerns are read against the project's stories, requirements and questions. This clearly distinguishes it from siblings like projects_analyze, projects_assess, or projects_audit_backlog.

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: name the pack via pack_id from packs_list or a public_share_url, follow up with open_questions_answer and open_questions_convert_to_story, and re-run later to see what changed via previous_verdict. It also warns not to recreate the questions, giving clear when/when-not guidance.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?