Plumbline: OFAC SDN sanctions screening, SEC financials and company checks from public registries

Change the order draft

update_order_draft

Idempotent

Change a Plumbline order draft the way the buyer asked: add, update, remove or replace companies (name an item by its key from the draft, or by match on its name), or clear the list (item fields: name (the company's name as the buyer has it, or its exact legal name); country (ISO 3166 two-letter code; narrows the LEI search by name); lei (20-character Legal Entity Identifier; the report then reads that exact record); cik (SEC Central Index Key; adds the SEC EDGAR registration (EDGAR is not searched by name))). The app in the conversation shows the change at once. A placed order is never changed (the draft is locked); a change after the request was sent is a revision the buyer sends again with send_order_draft. Repeat a call with the same op_id and it is applied once.

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

Input Schema

Name	Required	Description
`id`	Yes	The draft id
`ops`	Yes
`op_id`	No	Your id for this change, so a retry is applied once
`token`	Yes	The draft's private token (also the receipt token of every request sent from it); keep it private
`from_app`	No	Set only by the app itself
`base_revision`	No	The revision you read

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real context beyond the annotations: the app reflects the change immediately, placed orders are immutable, and repeating a call with the same op_id is applied once (reinforcing idempotentHint). What's missing is failure behavior — what happens on a stale base_revision, an unmatched key/match, or a partially failing multi-op batch.

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?

Every clause carries information, but the whole definition is one dense sentence-plus-parenthetical, with deeply nested parentheses around the item fields. It would be far more scannable as short separated statements; the operation list and item-field glossary are buried mid-sentence.

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?

For a 6-parameter mutation tool with annotations and no output schema, this covers locking, revision flow, idempotency, and item field meaning — nearly everything needed to call it correctly. The remaining gap is outcome/error reporting, which the description never addresses.

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 already 83%, so the baseline is 3; the description goes further by explaining that lei pins an exact record, country narrows the LEI name search, and cik pulls in the EDGAR registration that is not searchable by name. It does not explain base_revision's conflict behavior or the 30-op cap, but the added field semantics are substantial.

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?

Opens with a specific verb and resource ("Change a Plumbline order draft") and immediately enumerates the five operations (add, update, remove, replace, clear), so the agent knows exactly the scope. It is clearly separable from get_order_draft and send_order_draft, both of which are referenced.

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?

Gives an explicit when-not: "A placed order is never changed (the draft is locked)", and routes the agent to the correct alternative ("a revision the buyer sends again with send_order_draft"). Item identification strategy (key from the draft vs. match on name) is also stated as a choice the caller makes.

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

All Plumbline: OFAC SDN sanctions screening, SEC financials and company checks from public registries 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?