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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the values are XBRL as reported in SEC filings, scoped to exactly one concept and one filer, and the response carries period, form and accession number. It still omits whether amended/restated filings are returned or how multiple periods/units are handled.

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

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

A single front-loaded sentence with no filler; every clause (what it returns, the one-concept/one-filer scope, the returned metadata) earns its place. Nothing is repeated from the schema or annotations.

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

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

With no output schema, the description does helpfully enumerate the returned fields (period, form, accession number), which is valuable. But for a zero-required-parameter tool with a taxonomy enum and an ambiguous cik/ticker pair, it leaves the agent guessing about valid calling combinations and value/unit representation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for four parameters, so the description must carry the burden — and it only implies that 'concept' and 'cik'/'ticker' are the identifying inputs. It says nothing about the taxonomy enum (us-gaap/ifrs-full/dei), how cik and ticker interact or which wins, or the expected concept name format (maxLength 120) even though the word 'XBRL' hints at it.

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

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

States a specific verb+resource: reported XBRL values for one concept of one SEC filer, and names the returned fields (period, form, accession number). The purpose is unambiguous, and no sibling tool (entity_lookup, federal_contract_awards, describe_proposition) overlaps with SEC financial-fact retrieval, so explicit differentiation isn't needed.

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

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

There is no when-to-use guidance at all — nothing says when to prefer this over a general entity or filings lookup, no exclusion of non-XBRL data, and no hint about the cik-vs-ticker choice or whether taxonomy is required in practice. The only guidance is implicitly inferred from the one-sentence purpose.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that the payload is comprehensive in scope, without saying what happens for an unknown slug, whether an error is raised, or how large the response is. It neither contradicts nor meaningfully extends the annotations.

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

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

It is a single front-loaded sentence with a colon-delimited list, which is structurally sound and short. But several list items are vague ('what you get', 'any operations'), so brevity comes at the cost of specificity rather than being purely efficient.

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

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

There is no output schema, so the description is the only source of return-value information, and it does gesture at the main content categories. Against the simplicity of a one-parameter read tool with rich annotations, that is roughly adequate, but the undefined slug and absent error/edge-case behavior leave gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter, slug, has 0% schema description coverage, so the description carries the full burden and does not meet it — 'slug' is never explained as the service identifier, its expected format, or where to obtain it. The items listed ('request fields', 'operations') describe response content, not the input, so they do not compensate for the schema gap.

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

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

The description conveys that this is a detail-lookup for a single service and enumerates the kinds of content returned (request flow, response, scope/limits, fields, operations). However, it never states an explicit verb and shifts terminology from the tool name's 'proposition' to 'service', which leaves the agent to infer that these are the same entity. The singular framing loosely implies a contrast with list_propositions, but no explicit differentiation is made.

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

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

There is no when-to-use guidance at all: nothing says to call this instead of list_propositions when the agent already has a slug, and nothing mentions the sibling tools. The description also never hints at what precondition must hold (a valid slug) before calling.

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

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

Annotations already establish that the tool is read-only, idempotent, non-destructive, and open-world. The description adds useful behavior beyond that by disclosing the paid x402 HTTP access model and $0.02 cost per call, though it remains unclear what the tool actually returns and whether payment is handled automatically.

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

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

The description is only two sentences and front-loads the domain before the payment detail. It is concise, though the phrase 'returns how to call it' introduces ambiguity rather than useful clarity.

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

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

For a four-parameter lookup tool with no output schema and no parameter descriptions, the definition is incomplete. It leaves unresolved whether the tool returns registration data or only invocation instructions, and it does not explain how the optional identifiers are matched or prioritized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has four parameters with 0% description coverage, and the description does not define cik, lei, name, or ticker. It hints at LEI and SEC EDGAR, which loosely maps to lei and cik, but gives no meaning for name or ticker or for how identifiers should be combined.

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

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

The description identifies the domain as LEI records and SEC EDGAR registration for a company, but then says the tool 'returns how to call it,' which blurs whether it retrieves company data or only payment/calling instructions. It does not clearly differentiate itself from siblings such as company_financial_facts.

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

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

There is no guidance on when to use this tool versus alternatives, nor on how to choose among cik, lei, name, and ticker. The only operational context is that calls are paid over HTTP with x402.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds genuinely non-redundant behavior: the upstream source (FPDS) and, importantly, the result-set size ('ten at a time'), which signals pagination pressure that the agent would otherwise only discover empirically. It stops short of describing ordering or what happens when no filters are supplied.

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

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

A single dense sentence, front-loaded with the resource, then scope, then filters, then page size, then provenance. Every clause carries information; nothing is padded or repeated from the title.

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

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

For a 5-parameter search tool with no output schema, the description covers filters and page size but leaves meaningful gaps: whether multiple filters combine with AND, whether omitting all filters returns the whole corpus, any default fiscal year, and what an award record actually contains (amount, date, agency). An agent can call it, but not predict its results well.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden, and it largely does: 'vendor name', 'NAICS code', 'place-of-performance state' and 'fiscal year' map onto recipient, naics, state and fiscal_year with added meaning (place of performance, not vendor location). Only 'start' is left implicit, inferable from 'ten at a time' but never named as an offset.

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

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

The description names a specific resource ('US federal contract actions (awards and modifications)') and enumerates the exact filter dimensions, so the agent knows precisely what this retrieves. It does not explicitly contrast with siblings such as company_financial_facts or entity_lookup, though the contract-award framing makes the distinction reasonably inferable.

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

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

Usage is implied rather than stated: the list of queryable dimensions (vendor, NAICS, state, fiscal year) tells the agent what contexts this tool serves, but there is no explicit when-to-use rule, no prerequisites, and no mention of alternatives or when-not to use it.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds the useful detail that each entry is a one-line summary, but says nothing about ordering, count, or what identifiers come back for chaining.

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

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

A single front-loaded sentence with the resource named first and the return shape after the colon. No filler, though the 'requirements you can send' phrasing is slightly vague about what kind of requirement is meant.

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

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

For a trivial zero-param, no-output-schema tool with rich annotations the description is close to sufficient, but it leaves a real gap: an agent needs to know the listed entries can be fed into describe_proposition, and that linkage is not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero input parameters, so per the baseline this scores 4. The description correctly implies a no-argument catalog call, and nothing about parameters needs further explanation.

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

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

The description states a concrete verb and resource (list services) and characterizes the two kinds of services returned: instant lookups and sendable requirements. That characterization implicitly maps onto sibling tools (entity_lookup/screen_sanctions vs submit_request), though it never names them, and the name/title mismatch ('propositions' vs 'services') adds a small ambiguity.

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

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

Usage as a discovery step is implied by the fact that it lists services, but the description never says 'call this first, then use describe_proposition for details' or when to skip it. The agent must infer the routing from context rather than being told.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the safety profile is covered. The description adds one genuinely useful behavioral note: results are screening leads requiring review rather than confirmed determinations. It says nothing about the meaning of the score, default thresholds, or the volume/format of returned candidates.

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

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

Two short sentences, zero filler, with the core operation front-loaded and the important caveat placed immediately after. Nothing is redundant or buried.

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

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

With no output schema, 0% parameter coverage, and an unexplained relevance threshold, the description leaves too much unspecified for correct invocation. An agent cannot tell what a returned match looks like, what score scale applies, or how to tune min_score for looser or stricter screening.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both parameters, so the description must compensate and does not. It never explains the expected format of 'name' (full name, order, aliases) nor the meaning, default, or effect of 'min_score' despite its 0.5–1.0 range, leaving the agent to guess how threshold changes affect results.

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

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

States a specific verb (screen) and a specific resource (a name against the OFAC SDN list and aliases), so the operation is unambiguous. It does not differentiate from any sibling tool, though the sibling list contains no obvious sanctions alternative, so the gap is mild.

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

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

The description implies usage for sanctions/adverse-media style checks and adds an interpretive caveat that a match is a lead for review, not a determination. It gives no explicit when-to-use or when-not-to-use conditions, and no prerequisite or follow-up guidance (e.g., which tool to use after a hit).

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write, so the safety profile is covered. The description adds one genuinely new fact beyond them: submissions persist and are tracked by a returned reference number. It does not warn that repeated submits create duplicate requests (relevant given idempotentHint=false) or describe what the reference number looks like.

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

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

Two short sentences, no filler, with the core action stated first. The brevity is efficient, though part of it comes from omission rather than disciplined editing.

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

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

For a 10-parameter, nested-object mutation with no output schema, the description is far too thin: it omits the required-field pair, the open-ended specifications contract, and any notion of what a successful response contains. An agent could not assemble a valid call from this description alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40% across 10 parameters with nested objects, so the description needs to compensate and does not. It never names slug, need, budget, timing, quantity, specifications, or requested_fields, and gives no hint that 'specifications' must mirror a per-service request schema — the single most error-prone field. Only the 'need' meaning is loosely echoed by 'a requirement in words'.

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

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

States a specific verb and resource ('Send a requirement') and names the destination ('one of Plumbline's services'), so an agent knows this creates a submission rather than querying one. It is clearly distinct from the sibling tools (entity_lookup, screen_sanctions, list_propositions), none of which submit anything. It stops short of 5 because 'requirement' and 'service slug' are domain jargon left undefined.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites, and no explanation of how to pick a slug or when 'anything-else' applies. The description never says what happens if a need doesn't match a known service, which is exactly the decision an agent must make before calling.

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