Colophon: translation quotes; image, music, font and patent licensing

Change a requirement by field

edit_requirement

Idempotent

Set fields by name ({"op":"set","values":{...}}, an empty value clears) or change the list ({"op":"add"|"update"|"remove"|"replace", ...}), exactly as given: no reading. Use it to answer the open question when the answer is a value.

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": {
      "slug": "<slug>",
      "id": "<id>",
      "token": "<token>",
      "ops": "<ops>"
    },
    "name": "edit_requirement"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The requirement id from an earlier answer
`ops`	Yes
`slug`	Yes	The service, from list_propositions
`op_id`	No
`token`	Yes	Its private token (also the receipt token of the request it is sent as); keep it private
`base_revision`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare non-read-only, non-destructive, idempotent, closed-world. The description adds two genuinely useful facts: an empty value clears a field, and the write is applied 'exactly as given: no reading', i.e. a blind write with no read-modify-write. It omits conflict/error behavior and permission requirements, and 'add' semantics sit slightly awkwardly with idempotentHint=true.

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

Conciseness3/5

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

It is short with no filler, but the compression is aggressive: a parenthetical JSON sketch plus a terse clause about open questions makes it hard to parse on first read. Front-loading the operation itself before the payload grammar would improve it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter mutation with optional optimistic-concurrency control and no output schema, the description leaves key questions unanswered: what base_revision does, what happens on a revision conflict, whether ops are atomic, and what is returned. The absent 'no reading' note is helpful but not enough for a state-changing tool.

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 50%, and the description does compensate for the undocumented `ops` parameter by spelling out the op grammar (set/add/update/remove/replace and the empty-value-clears rule). However, `base_revision`, `op_id`, and the 30-item cap are not explained anywhere, so the concurrency and batching semantics of the most consequential parameters remain unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with the shape of the ops payload rather than plainly stating 'edit the fields of an existing requirement'. The verb is implied by 'Set fields by name', and the resource only appears effectively in the title. An agent can infer it is a blind field-mutation operation, but the sentence structure buries that.

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

Usage Guidelines2/5

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

Only one usage cue: 'Use it to answer the open question when the answer is a value', which assumes concepts the reader may not have. There is no when-not and no reference to siblings like get_requirement, answer_remedy, interpret_requirement, or send_requirement, even though the choice among them is not obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Colophon: translation quotes; image, music, font and patent licensing 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?