Loading ToolBench
Expose OpenSanctions screening and investigation to MCP clients. Lets an assistant screen people, companies, and other entities against sanctions, PEP, and watchlist data and walk their relationships.
Strong foundation with 10 well-named tools following verb_noun convention (match_entity, search_entities, fetch_*, describe_*). All tools have descriptions and input schemas with types. match_entity has exceptionally detailed description (450+ chars) explaining FtM schema usage and scoring. However, several parameter descriptions are minimal (e.g., search_entities 'countries' lacks format/constraint details), and output schemas are not explicitly documented in the visible code. No error handling guidance visible. Tool annotations present (readOnlyHint). Composition is clean, each tool has single responsibility, and tools chain well (match_entity → fetch_entity_by_id for expansion).
List available countries.
Describe a dataset from the live catalog.
Describe a sanctions program.
Describe an FtM schema and its properties.
List available topics for filtering.
Fetch a full entity by ID.
Fetch entities related to a given entity ID.
Output schemas not documented in visible code. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns. match_entity, fetch_entity_by_id, and search_entities should document their response structures (e.g., 'Returns array of {entity_id, name, score, match, schema_type, ...}')
Minimal parameter descriptions on discovery tools. describe_schema, describe_topics, describe_countries, describe_dataset, describe_program have 1-word or trivial descriptions ('Describe an FtM schema...', 'List available topics...'). Should explain WHEN to call them and what structure they reveal (e.g., 'Call before match_entity to understand available FtM property names and constraints')
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Fetch statements (raw data) for an entity.
Screen one entity against sanctions/PEP/watchlist data; return scored candidates. Query-by-example: describe the entity in as much detail as you can and the API returns ranked candidates. Use for ANY matching task, even with partial data. `schema` is an FtM type (Person, Company, ...) and `properties` maps FtM property names to value lists ({"name": ["Jane Doe"], "birthDate": ["1975"]}) — call describe_schema first if unsure of the names. Send every property you have. Country values accept free text ("Russia"); the server normalizes them, and matching works by value type rather than field name, so don't agonize over e.g. `country` vs `jurisdiction`. `score` is 0-1 confidence; `match` is true when score >= `threshold` (server default 0.7). Results are trimmed views — expand a candidate with fetch_entity_by_id.
Search entities by free-text query.
search_entities 'countries' parameter lacks constraint documentation. Description says 'Filter by countries' but does not specify format (free text like 'Russia', ISO codes, or both?). match_entity description clarifies 'Country values accept free text'; search_entities should match.
No error handling guidance visible. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., if match_entity returns no results, should the agent retry with different properties, or call search_entities instead?
Pagination not visible in search_entities or match_entity. If these return large result sets, LLMs need limit/offset or cursor parameters and a total count. Code shows 'limit' param on match_entity but no offset/cursor or total_count in documented output.