Skip to main content
Glama

Get sanctions overview

get_sanctions_overview
Read-onlyIdempotent

The sanctions picture in one call: restricted-party register counts by list and type, the Russia shadow-fleet enforcement index, Russia economic-impact measures and recent enforcement actions.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare read-only, idempotent, non-open-world, non-destructive, so the description needn't restate safety. It adds the behavioral shape of the call, that it's an aggregate combining four distinct datasets, which is useful context. It does not mention whether results are cached/stale, rate limits, or the response layout.

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

Conciseness5/5

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

One front-loaded sentence, zero waste, and the four data components are listed compactly. It is exactly the length the content needs.

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

Completeness3/5

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

No output schema exists, so the agent must decide whether the four listed components are sufficient. The four components are named, but their shape (counts vs. scores vs. action records) is only hinted at. Given the tool returns a multi-dataset panel, the description should say more about the shape of each component.

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?

With zero parameters, the baseline is 4. The description signals there is nothing to filter or scope: it's a fixed overview bundle, which matches the empty schema.

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

Purpose4/5

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

The description gives a precise verb and resource ('sanctions picture in one call') and enumerates the returned content: register counts by list and type, shadow-fleet index, economic-impact measures, recent actions. It's distinguishable from adjacent siblings like find_enforcement_precedent and check_commodity_controls, but it does not explicitly name any sibling it might be confused with.

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

Usage Guidelines3/5

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

Implied usage is clear: this is a bundled overview, so an agent reaches for it when it wants a broad snapshot rather than a targeted query. No explicit when/when-not guidance or named alternatives are supplied, so the agent must infer from the sibling names which to pick for detail.

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.