macro
Latest US macro indicators (CPI/NFP/U3/oil) with release flags
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Latest US macro indicators (CPI/NFP/U3/oil) with release flags
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns latest data with release flags, suggesting it's read-only and time-sensitive. No annotations exist, so the description carries the full behavioral disclosure burden. It doesn't mention caching behavior, update frequency, data source, or whether historical data is accessible.
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 a single, concise sentence that front-loads the core purpose ('Latest US macro indicators') and adds specific examples and features ('release flags'). Every word is essential and earns its place with no wasted verbiage.
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?
For a zero-parameter tool with no output schema, the description provides reasonable completeness: it names the type of data (US macro indicators), gives examples (CPI/NFP/U3/oil), and mentions a key feature (release flags). However, it could be more complete by specifying whether data includes historical values, the time range covered, or units of measurement.
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?
With zero parameters and 100% schema coverage, the description correctly identifies that no input is needed. The description adds value by explaining what data the tool returns (CPI/NFP/U3/oil with release flags), which helps the agent understand the fixed output. Since there are no parameters, a 4 is appropriate for providing semantic context beyond the empty 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 provides 'Latest US macro indicators' and lists specific examples (CPI/NFP/U3/oil) with 'release flags'. This is a specific verb-resource combination ('get indicators') with enough detail to distinguish from sibling tools like 'calendar' or 'earnings', though it doesn't explicitly differentiate from them.
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 implies this is for retrieving macro economic data with release date flags, which suggests use when needing up-to-date US economic indicators. However, it provides no explicit when-to-use or when-not-to-use guidance, and doesn't mention alternatives among the 14 sibling tools.
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.
Most tools have clearly distinct purposes: financial data tools (calendar, candles, earnings, etc.) are separate from web scraping tools (read, screenshot, unlock, etc.). However, there is some overlap between 'history' (daily closes + range change) and 'candles' (OHLCV), which could cause minor confusion.
Tool names are inconsistent: most are single-word nouns (e.g., 'calendar', 'candles') but some are verbs ('read', 'search', 'unlock') and one uses an underscore ('url_safety'). There is no uniform verb_noun or noun pattern, making it harder for an agent to predict tool names.
With 16 tools, the server is slightly above the ideal range of 3-15, but each tool appears to serve a distinct purpose. The count is manageable given the two domains (financial data and web scraping).
The financial data tools cover many common data points (economic releases, price history, filings, earnings) but miss order books, real-time trades, or news. The web scraping tools are comprehensive for fetching content but lack structured data extraction. The feedback tool suggests the server is still evolving, indicating notable gaps.