indicatorConvenience lookup for common Brazilian macro indicators by friendly name (no SGS code needed). names: selic_target, selic_daily, ipca, usd_brl_ptax, usd_brl, cdi. Returns the latest N observations with the series label and unit.
| Name | Required | Description | Default |
|---|---|---|---|
| last | No | How many recent observations to return (default 12, max 1000). | |
| name | Yes | One of: selic_target, selic_daily, ipca, usd_brl_ptax, usd_brl, cdi. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "last": 12,
+ "name": "selic_target"
+ },
+ {
+ "last": 24,
+ "name": "ipca"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds behavioral detail by stating it 'Returns the latest N observations with the series label and unit', which informs the agent about the output shape without contradicting the annotations. It doesn't cover edge cases like rate limits, but the added output context goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose and supported names, followed by the return behavior. Every sentence earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, read-only, idempotent), the description covers all essential aspects: what it does, supported names, the 'last' parameter behavior, and the return content. Annotations cover safety, and the schema covers parameter details. No output schema exists, but the description sufficiently explains the return shape, making the tool fully understandable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The description adds semantic meaning to the 'name' parameter by explaining these are friendly names and no SGS code is needed, which is not fully conveyed by the schema's simple enum list. For 'last', it essentially restates the schema's 'latest N observations' but doesn't introduce new meaning. Overall, it adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'Convenience lookup for common Brazilian macro indicators by friendly name (no SGS code needed)', which specifies both the action (lookup) and the resource (Brazilian macro indicators). It also lists the exact supported names and distinguishes it from sibling tools like 'sgs_series' by explicitly noting that no SGS code is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for looking up common indicators by friendly name, avoiding the need for SGS codes. This strongly implies it should be used over 'sgs_series' when a friendly name is available, though it doesn't explicitly name the alternative or state when not to use it. Thus it is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct purpose; even similar tools like ask_pipeworx and ask_pipeworx_grounded are clearly differentiated by grounding behavior. Polymarket tools are separated by specific angles (arbitrage, edges, tracking, fill risk, cross-venue).
All tool names use consistent snake_case with descriptive verbs (ask_, compare_, discover_, generate_, list_, recall_, etc.). No mixing of camelCase or other conventions.
35 tools is on the higher end but justified by the breadth of functionality: Brazilian economics, Pipeworx data querying, company analysis, Polymarket betting, memory, subscriptions, etc. Each tool seems necessary, though a few could potentially be consolidated.
The tool set covers major CRUD operations and data retrieval across multiple domains. Minor gaps exist (e.g., no tool to edit subscriptions directly, but unsubscribe/resubscribe works). Overall, the surface is well-rounded for the stated purposes.