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

Verify suppliers with Plumbline

verify_suppliers

Open Plumbline's supplier verification workspace in the conversation, with the companies the buyer named. It starts an order draft the buyer and you work on together: they can add, correct and identify companies in the app, and you change the same draft with update_order_draft when they ask in words ("add Microsoft", "replace Apple with Nvidia"); both of you see the same list and price. The report screens each company against the US Treasury OFAC SDN list, reads its GLEIF LEI record and, where a CIK is given, its SEC EDGAR registration; every finding names its source and time, and the report is hashed. Price: $5.00 for one company, $1.00 for each further one, up to 25; the firm offer states the binding price. Call identify_company when the buyer names a company loosely, so they can choose the exact legal entity. Nothing is ordered until the buyer sends the request and then accepts the firm offer. Call this once per order; afterwards use get_order_draft and update_order_draft with the draft's id and token (or pass draft to show it again, or order_link to continue an order from an emailed link). Without an app-capable host, use submit_request on entity-verification.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "verify_suppliers"
  }
}

Input Schema

Name	Required	Description
`draft`	No	Show this existing draft instead of starting one
`order_link`	No	An order or request link the buyer has from an email or an earlier conversation, to continue that order
`counterparties`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 9, 2026

addedInput schema / additionalProperties
```
Added value: +{}
```

changedInput schema / properties / counterparties / items / properties / cik / description

Previous value: -"SEC CIK number, if the buyer has it"New value: +"SEC CIK number, if known"

changedInput schema / properties / counterparties / items / properties / lei / description

Previous value: -"20-character LEI, if the buyer has it"New value: +"20-character LEI, if known"

changedInput schema / properties / counterparties / items / properties / name / description

Previous value: -"Company name as the buyer gave it"New value: +"Company name as the buyer gave it, or its legal name"

addedInput schema / properties / draft

Added value: +{
+  "description": "Show this existing draft instead of starting one",
+  "properties": {
+    "id": {
+      "description": "The draft id",
+      "format": "uuid",
+      "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+      "type": "string"
+    },
+    "token": {
+      "description": "The draft's private token (also the receipt token of every request sent from it); keep it private",
+      "pattern": "^[0-9a-f]{48}$",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "token"
+  ],
+  "type": "object"
+}

removedInput schema / properties / email

Removed value: -{
-  "description": "Where the buyer wants the receipt and order notices",
-  "maxLength": 200,
-  "type": "string"
-}

addedInput schema / properties / order_link

Added value: +{
+  "description": "An order or request link the buyer has from an email or an earlier conversation, to continue that order",
+  "maxLength": 400,
+  "type": "string"
+}

removedInput schema / properties / organization

Removed value: -{
-  "maxLength": 160,
-  "type": "string"
-}

AddedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false) by describing the collaboration model of the shared draft, the exact pricing ladder ($5.00 first, $1.00 each further, cap 25), and the non-binding-until-accepted offer semantics. It also discloses what the report actually does — OFAC SDN screening, GLEIF LEI lookup, SEC EDGAR when a CIK is given — plus source/timestamp attribution and hashing.

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?

Dense and long, but nearly every clause carries distinct operational information — pricing, offer bindingness, report contents, sibling routing. The main weakness is a run-on middle section where the report and pricing sentences are packed together rather than separated for scannability.

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 no output schema, the description still tells the agent what comes back: a hashed report with per-company findings naming their source and time, plus a shared draft showing the same list and price. For a 3-parameter tool with nested counterparties and a multi-step ordering flow, that is complete.

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 67%, and the description compensates by explaining the draft and order_link parameters in operational terms ("pass draft to show it again, or order_link to continue an order from an emailed link") and by noting that a supplied CIK drives the SEC EDGAR check. It does not explain the counterparty fields name/lei/country in detail, leaving that to the schema.

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: "Open Plumbline's supplier verification workspace in the conversation, with the companies the buyer named." It immediately distinguishes itself from siblings by naming identify_company and submit_request for the cases this tool does not cover.

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?

Explicit routing: call identify_company when a company is named loosely, use submit_request on entity-verification when there is no app-capable host, and "Call this once per order" followed by get_order_draft/update_order_draft. It also states the gating condition that nothing is ordered until the buyer sends the request and accepts the firm offer.

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?