Entalpa Requirements MCP

Projects Spec Score Settings

projects_spec_score_settings

Set how a project's Spec score weighs its areas and quality attributes. weights: area (D2 Requirements 25, D3 Stories 10, D4 Consistency 15, D5 Traceability 20, D6 Quality attributes 20, D7 Interfaces 10 by default) to a weight from 0 to 100; 0 switches the area off, its caps and fixes with it, and projects_assess stops judging what only it needs. relevance: ISO 25010 characteristic to {relevance: 0 not relevant, 1 relevant, 2 critical; reason}, the reason shown next to the score. Replaces the settings: anything left out returns to its default (the rubric's weight, the scoring model's suggestion), so read the current ones from projects_spec_score (weights, quality_attributes[].chosen) and send them all. Returns the score as it now stands. 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_settings"
  }
}

Input Schema

Name	Required	Description
`weights`	No	Weight per area, a whole number from 0 to 100; 0 switches the area off. An area left out weighs what the rubric says: D2 30, D3 10, D4 10, D5 20, D6 20, D7 10, which sum to 100. At least one area stays on.
`relevance`	No	How much each ISO 25010 characteristic matters, with a reason. A characteristic left out matters as the scoring model suggests.
`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

A4.3/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false), it discloses that the call is a full replacement where omitted keys revert to defaults, that a 0 weight disables a capability and its downstream judging in another tool, that reasons surface in the UI, and that it costs no AI calls or credits. That is materially more than the structured fields provide.

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 purpose, then per-parameter semantics, then the replace/default caveat and the return value. Dense and backtick-heavy for a 3-parameter tool, but nearly every clause carries operational 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?

Output schema and annotations cover return shape and safety profile, so the description need not explain them; it still states the return ('the score as it now stands'). The one gap is the default-weight numbers that disagree with the schema's own documentation of the same defaults.

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 coverage is 100%, so the parameter semantics are already carried by the schema; the description mostly restates them (0 = off, 0/1/2 relevance). However, its stated default weights conflict with the schema (description says D2 25 / D4 15, schema says D2 30 / D4 10), which is a misleading redundant detail rather than added value.

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?

A specific verb plus resource: 'Set how a project's Spec score weighs its areas and quality attributes,' followed by the two configurable surfaces (`weights`, `relevance`). It is clearly distinguished from the reading sibling projects_spec_score and names the downstream consumer projects_assess.

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

Usage Guidelines4/5

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

It prescribes the read-modify-write workflow explicitly ('read the current ones from projects_spec_score ... and send them all') because the call replaces prior settings. It also explains the consequence of sending 0 for an area. It stops short of a full when-not-to-use statement, but the alternative routing is concrete.

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?