Entalpa Requirements MCP

Packs Update

packs_update

Destructive

Change a pack the user can edit; read it with packs_get first. A field left out stays as it is. concerns replaces the whole checklist, at most 20: give a concern's id to keep or reword it (it keeps its place), omit id for a new one, and leave a concern out to remove it. An owner the change leaves without a concern is removed unless owners lists it. One undo step.

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": {
      "pack_id": "<pack_id>"
    },
    "name": "packs_update"
  }
}

Input Schema

Name	Required	Description
`title`	No	The pack's title (1-255 characters).
`owners`	No	Owners to describe, or to keep without a concern.
`pack_id`	Yes	A pack's UUID, from packs_list.
`concerns`	No	The whole checklist, at most 20 concerns, which replaces the pack's.
`description`	No	What the pack checks, shown on its card.

Output Schema

Name	Required	Description
`title`	Yes
`owners`	Yes
`pack_id`	Yes	A pack's UUID, from packs_list.
`problem`	No	Why it cannot be used yet, if it cannot.
`can_edit`	Yes	Whether packs_update may change it.
`concerns`	Yes
`by_entalpa`	Yes	Published by Entalpa for everyone, and read as published.
`description`	No	What the pack checks.
`version_name`	No	The published version read.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds substantial non-obvious behavior: omitted fields are preserved, `concerns` replaces the entire checklist, the 20-item cap, the id-vs-omit keep/create/remove protocol, automatic owner removal when left without a concern, and a single undo step. This is exactly the destructive-semantics context an agent needs beyond the hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the action and the read-first prerequisite, then the partial-update rule, then the risky `concerns` semantics. No filler and nothing repeated from the schema.

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?

With an output schema present, the description need not describe return values, and it covers the areas that matter for a destructive patch: partial-update semantics, list replacement rules, cardinality limits, cascade deletion of owners, and reversibility.

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 baseline is 3, but the description adds merge semantics the schema does not encode — how the top-level `concerns` array reconciles with existing items via `id`, and how `owners` interacts with concern removal to decide whether an owner persists. It adds little for `title`/`description`, which the schema already documents.

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 ('Change a pack') plus the scope constraint ('the user can edit'), and explicitly points to packs_get for reading, which cleanly separates it from the sibling read tool and from packs_create/packs_delete.

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?

Gives an explicit prerequisite workflow ('read it with packs_get first'), which is the main precondition for a safe patch. It does not discuss when to use this versus packs_create or packs_delete, so it falls short of full when/when-not 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?