Skip to main content
Glama

Cmf Sanctions

cmf_sanctions
Read-onlyIdempotent

Search the CMF (Chile's financial regulator) register of sanction resolutions, about 1,500 resolutions from 2002 to today: each row has the resolution number, date, subject (e.g. 'APLICA SANCIÓN A ITAÚ CORREDORES DE BOLSA LIMITADA') and a link to the resolution document. Filter by free-text query (Spanish; matches the subject, accent- and case-insensitive, all words must match) and/or year. Resolutions that name individuals are served with the person's name as the register publishes it (Bruce's case ruling of 2026-10-25, scoped to this tool): every row carries its source record (resolution number, date, CMF document link); no address is ever served for an individual and a natural person's RUT is stripped from the subject; anyone named can ask for removal at support@pipeworx.io and a removed name is replaced in the subject and its document link dropped (counted in withheld_by_removal_request). Each row has a subject_kind (person | organisation | mixed | unclassified) assigned only from explicit cues in the subject (honorific = person; corporate-form word = organisation); a bare personal name with neither cue is 'unclassified', not guessed, and subject_kind_basis says why. When nothing matches, returns found:false with the exact scope searched (a sanction announced in a press release but absent from the register is not covered).

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": 2026,
      "query": "Itaú"
    },
    "name": "cmf_sanctions"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoOptional resolution year, e.g. 2026.
limitNoMax rows to return (default 25, max 200). Newest first.
queryNoOptional Spanish words to match in the resolution subject, e.g. "Itaú" or "Cooperativa Oriente". All words must match.

Output Schema

NameRequiredDescriptionDefault
foundNo
sourceNo
resultsNo
returnedNo
data_as_ofNo
scope_searchedNo
total_matchingNo
withheld_natural_person_rowsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds substantial non-structured behavior: per-row source provenance, that no address is ever served for individuals, that a natural person's RUT is stripped, the removal-request path and the withheld_by_removal_request counter, subject_kind derivation rules, and the exact found:false shape. None of this is recoverable from annotations or schema.

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

Conciseness3/5

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

Purpose is correctly front-loaded in the first sentence, but the remainder is one dense run-on paragraph mixing privacy policy, provenance, a specific anonymized case reference, and classification rules. Nearly all facts are relevant, yet the phrasing ('Bruce's case ruling of 2026-10-25, scoped to this tool') and the interleaved caveats make it harder to scan than it needs to be.

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?

Covers everything an agent needs to call this correctly: what is indexed, how filters compose, how unmatched queries behave, the individual-name redaction regime, and the fact that an output schema handles the row shape. For a read-only search tool with rich annotations and an output schema, no material gap remains.

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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: the query is Spanish, matches the subject field only, is accent- and case-insensitive, and requires all words to match. The limit parameter's ordering is left to the schema, keeping this just short of a 5.

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?

Opens with a specific verb+resource and scope: 'Search the CMF (Chile's financial regulator) register of sanction resolutions, about 1,500 resolutions from 2002 to today'. It also states what each row contains (resolution number, date, subject, document link), which cleanly separates it from sibling tools like cmf_registry and cmf_regulation.

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?

Gives concrete usage guidance: filter by free-text Spanish query and/or year, all terms must match, and explicitly frames the boundary case ('a sanction announced in a press release but absent from the register is not covered'). It stops short of naming a sibling alternative (e.g. cmf_registry for entity data), so it is strong but not a full when/when-not/alternatives statement.

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.