Entalpa Requirements MCP

Projects Spec Score

projects_spec_score

Read-onlyIdempotent

The Spec score: how ready a project's spec is to hand to a coding agent. The score with its band and areas once the project has been assessed (projects_assess); every rubric check (ids such as D2.12 or D5.3) with the items that fail it, a note quoting the words concerned; open questions, placeholders and suspect requirements; the caps holding the score down; the five fixes that gain the most; and subsystem pairs that may lack an interface contract (unconfirmed). assessment.due counts what changed since the last assessment. Every item carries its kind and UUID. Uses no AI and no credits.

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_spec_score"
  }
}

Input Schema

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

Output Schema

Name	Required	Description
`caps`	Yes	Caps in force, lowest first.
`gaps`	Yes
`score`	No	Null until the project is assessed.
`checks`	Yes
`weights`	Yes	Each area's weight. Relative: an area's share of the score is its weight over the sum for the areas that apply.
`top_fixes`	Yes	Up to five, the largest gain first.
`assessment`	Yes	How far the scoring model has judged the project's current text.
`rubric_version`	Yes
`interface_hints`	Yes
`story_priorities`	Yes
`not_scored_checks`	Yes	Rubric checks Entalpa does not score: the product context (D1), which would judge the description, where a project starts; a glossary (D2.9); the category and risk attributes (D2.16, D2.17); and D7.1, whose candidates are the interface hints.
`quality_attributes`	Yes	D6, per characteristic: how much it matters, what covers it.
`requirement_priorities`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 10, 2026

addedOutput schema / properties / assessment / properties / compared

Added value: +{
+  "description": "Whether requirements have been compared with each other for conflicts, duplicates and sets that cannot all be met (D4). False after quick assessments only, or a full one cut short before it compared everything once: D4 is then left out of the score, which is a quick estimate, until a full Assess.",
+  "type": "boolean"
+}

addedOutput schema / properties / assessment / properties / comparisons_due

Added value: +{
+  "description": "Requirements and groups still to compare, which only a full Assess does. Not counted in `due`.",
+  "type": "integer"
+}

addedOutput schema / properties / assessment / properties / estimates

Added value: +{
+  "description": "What the next Assess would take on, at each depth.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "calls": {
+        "description": "Model calls, at most.",
+        "type": "integer"
+      },
+      "credits": {
+        "description": "Credits the run holds for them; it is billed for what it uses.",
+        "type": "number"
+      },
+      "depth": {
+        "enum": [
+          "quick",
+          "full"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "depth",
+      "calls",
+      "credits"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / checks / items / properties / scored

Added value: +{
+  "description": "False for advice: its findings are listed, but it does not count toward the score.",
+  "type": "boolean"
+}

AddedNov 7, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered; the description adds non-obvious operational context that annotations cannot express — 'Uses no AI and no credits' — which matters for cost-sensitive agent planning. It also discloses that subsystem interface-contract findings are '(unconfirmed)' and that `assessment.due` reflects change since the last assessment, giving the agent a basis for interpreting staleness. It does not mention result size or whether the payload is truncated.

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 core concept is front-loaded in the first sentence and every subsequent clause names a distinct part of the returned payload, so little is padding. The middle section is a long semicolon-and-comma inventory that is dense to parse in one pass, which keeps it from a 5.

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, so the description's detailed return-value inventory is partly redundant but harmless; the prerequisite (run projects_assess first) and the no-AI/no-credits cost note cover the main gaps an agent would hit. Given a one-parameter, read-only tool, an agent has enough to invoke it correctly. Only the behavior when no assessment exists is 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?

There is a single parameter with 100% schema description coverage ('Project UUID (database id)'), so the schema already carries the meaning. The description adds nothing about project_id — no format, no error behavior for unknown ids. Baseline 3 is appropriate when the schema does the work.

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 names the concrete artifact it returns (a spec-readiness score with band, rubric checks, open questions, caps and top fixes) and defines the metric's meaning as 'how ready a project's spec is to hand to a coding agent'. That is far more specific than the name alone, and it implicitly separates itself from projects_assess by framing itself as the read of an already-computed assessment. It stops short of a clean verb-plus-resource statement, reading instead as a noun-phrase inventory of outputs.

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?

The parenthetical '(projects_assess)' plus 'once the project has been assessed' establishes a prerequisite, which is real usage guidance. However, it never states when to prefer this over siblings such as projects_get_assessment or projects_spec_score_settings, nor what to do when no assessment exists yet. The guidance is implied through prerequisites rather than explicit routing.

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?