Skip to main content
Glama

trade_party_screen

Read-only

Trade-compliance party screen (bundle) — One premium call for import/export compliance: screens a counterparty name against the US Consolidated Screening List (OFAC + BIS + State) AND pulls recent US Federal Register actions on the commodity/topic (export controls, tariffs, rules), fused into a clear/review/hold trade verdict with flags. JSON. Price: $0.20 USDC (Base, via x402).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYescounterparty / party name to screen
agencyNooptional agency slug, e.g. bureau-of-industry-and-security
commodityNooptional commodity or topic, e.g. 'semiconductors'

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the behavioral disclosure burden. The description adds meaningful context: exact data sources (OFAC, BIS, State), the fused verdict output with flags, JSON format, and a $0.20 USDC price. No contradictions with annotations.

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?

The description is one dense, information-rich sentence with no filler. It slightly repeats the title and bundles price alongside 'premium call', so it is efficient but not maximally tight.

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?

For a tool with no output schema and complex bundled behavior, the description covers the input (name, commodity), the action (screening + Federal Register), the output (verdict with flags, JSON), and price. The optional agency parameter is left to the schema, which is acceptable given full schema coverage.

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

Parameters3/5

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

Schema covers all three parameters with descriptions (100% coverage), so the description need not repeat them. It mentions 'counterparty name' and 'commodity/topic' in context, but adds no syntax or format detail beyond 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?

The description states a specific action ('screens a counterparty name') against a named resource (US Consolidated Screening List) and adds a second action (pulls Federal Register actions). This distinguishes it from siblings like legal_sanctions_screen or legal_reg_watch, which likely cover only one of these areas.

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

Usage Guidelines4/5

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

It clearly frames the tool as 'for import/export compliance' and as a 'bundle' combining two data sources. However, it does not explicitly name alternative tools or exclusion criteria (e.g., when to prefer simple sanctions screening over this premium bundle).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Many tools are clearly separated by prefix and data source, but several bundled products overlap heavily: vehicle_deal_check vs vehicle_report, realestate_property_report vs realestate_site_risk, finance_company_360 vs finance_health_scan, and domain_due_diligence vs email_domain_check/business_vet. An agent would frequently struggle to pick the correct premium bundle.

Naming Consistency4/5

Tool names overwhelmingly follow a consistent snake_case category-prefix pattern like weather_, crypto_, vehicle_, finance_, and geo_. Minor deviations such as bare names (domain, ip) and noun-verb forms (dns_lookup, url_check) are easy to learn and don't create real confusion.

Tool Count2/5

50 tools is far beyond the typical well-scoped 3–15 range and will require heavy filtering to navigate. The broad multi-domain data marketplace partially justifies the size, but it would be more coherent split into per-domain servers or consolidated further.

Completeness4/5

For a read-only data/diligence marketplace, the surface is quite comprehensive: weather, vehicle, crypto, SEC/finance, domain/email, sanctions, and geo workflows all have core operations plus fused verdict bundles. Minor gaps exist—such as a simple crypto price lookup or vehicle market value—but agents can usually work around them.

Resources