Return the provenance of the loaded OFAC SDN list: source URL, publish date, record count, fetch time, and the source + index content hashes. No input, no PII. Use this to confirm which list version a screening ran against.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool takes no input, returns provenance details, and has no PII, which implies a safe read-only operation. It could explicitly state that it does not modify any data, but the metadata-focused nature and 'No input' make the behavior sufficiently clear.
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 sentences, zero filler. The first sentence immediately states the returned fields, the second adds the version-confirmation use case. Every word earns its place.
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 tool with no parameters, no output schema, and a simple provenance-returning function, the description covers purpose, return values, usage context, and safety characteristics. Nothing essential is missing for an agent to select and invoke it correctly.
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 parameters, so the schema already covers everything. The description adds the meaningful clarification that the tool accepts 'No input,' which directly prevents an agent from looking for arguments. This meets the baseline for no-parameter tools.
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 opens with a specific verb 'Return' and names the resource 'provenance of the loaded OFAC SDN list,' then enumerates the exact outputs: source URL, publish date, record count, fetch time, and content hashes. This clearly distinguishes it from the sibling tool 'screen_sdn' by focusing on metadata rather than screening logic.
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?
Explicitly states 'No input, no PII' to set expectations, and provides a concrete use case: 'Use this to confirm which list version a screening ran against.' This signals when to use this tool (version confirmation) and implicitly contrasts with screen_sdn for actual screening, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools have clearly distinct purposes: one provides list metadata/provenance, the other performs name screening. There is no overlap or ambiguity in their functions.
Both tools follow a consistent verb_noun pattern (get_sdn_list_meta, screen_sdn) with clear action words. The slight variation in noun phrasing (sdn_list vs sdn) does not create inconsistency.
With only two tools, the server feels minimally scoped. While the narrow purpose is acceptable, it is borderline thin for a full-featured screening service.
The core workflow of screening a name and checking which list version was used is covered. Missing batch screening or detailed list exploration, but these are extras rather than critical gaps for the stated purpose.