Skip to main content
Glama

Query official CVM investment-fund reports

get_cvm_investment_funds
Read-onlyIdempotent

Retrieve daily CVM aggregates by official fund classification or resolve a fund/class latest report by CNPJ or name. Net assets and flows are additive; quota values stay fund-level; reported holder totals are not deduplicated people.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoInclusive last report date, YYYY-MM-DD.
fromNoInclusive first report date, YYYY-MM-DD.
fundsNoUnformatted 14-digit fund/class CNPJ values.
limitNoMaximum fund or classification rows to return.
queryNoFund-name search; use only with breakdown=fund.
breakdownNoWhether to aggregate by official classification or resolve a fund.classification
dataset_idYesThe official CVM investment-funds dataset identifier.
classificationsNoOfficial fund classifications to include.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesSource-preserving data or schema payload for the selected official dataset.
metaYesResponse metadata and source provenance.
linksNoRelated API links.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / breakdown / description
      Added value: +"Whether to aggregate by official classification or resolve a fund."
    • addedInput schema / properties / classifications / description
      Added value: +"Official fund classifications to include."
    • addedInput schema / properties / dataset_id / description
      Added value: +"The official CVM investment-funds dataset identifier."
    • addedInput schema / properties / from / description
      Added value: +"Inclusive first report date, YYYY-MM-DD."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum fund or classification rows to return."
    • addedInput schema / properties / to / description
      Added value: +"Inclusive last report date, YYYY-MM-DD."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": {},
      +  "description": "REST-aligned Open Economics response with data, metadata, links, and source provenance.",
      +  "properties": {
      +    "data": {
      +      "description": "Source-preserving data or schema payload for the selected official dataset."
      +    },
      +    "links": {
      +      "additionalProperties": {},
      +      "description": "Related API links.",
      +      "properties": {
      +        "observations": {
      +          "description": "Canonical observations endpoint for this dataset.",
      +          "type": "string"
      +        },
      +        "self": {
      +          "description": "Canonical URL for this response.",
      +          "type": "string"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "meta": {
      +      "additionalProperties": {},
      +      "description": "Response metadata and source provenance.",
      +      "properties": {
      +        "dataset": {
      +          "description": "Open Economics dataset identity when supplied."
      +        },
      +        "provenance": {
      +          "description": "Upstream source URLs, versions, timestamps, and methodology details."
      +        }
      +      },
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "data",
      +    "meta"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds genuinely useful data-semantics beyond that: net assets and flows are additive across rows, quota values are fund-level only, and holder totals are not deduplicated — non-obvious interpretation caveats an agent would otherwise get wrong.

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?

Two sentences, no filler. The primary retrieval modes are front-loaded, with the data caveats packed into a compact trailing clause. Every phrase carries information.

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

Completeness4/5

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

With an output schema present, return-shape explanation is unnecessary, and the description covers both operating modes plus the key interpretation pitfalls. What is missing is small routing guidance — when to reach for the schema sibling or the search tool — but for an 8-parameter read tool this is close to complete.

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 description coverage is 100%, so the baseline is 3, and the description earns an extra point by explaining what breakdown actually selects and by clarifying the aggregation-level semantics that the schema only states mechanically ('aggregate by official classification or resolve a fund'). It still does not speak to limit defaults or the maxItems caps.

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?

States two concrete verbs and resources: 'Retrieve daily CVM aggregates by official fund classification' and 'resolve a fund/class latest report by CNPJ or name.' The two modes map cleanly onto the breakdown enum, and the sibling get_cvm_investment_funds_schema is clearly the schema companion rather than a competitor.

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?

The description implies that aggregation vs. single-fund resolution is chosen by which lookup key you supply (classification vs. CNPJ/name), and the schema notes query is only valid with breakdown=fund. But there is no explicit when-to-use guidance, no mention of when to prefer the schema sibling, and no stated prerequisites or exclusions.

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.