A dated daily editorial read on markets, macro and geopolitical risk, plus a graded risk radar that states what would prove each call wrong, upcoming catalysts, per-sector desk notes and macro-economic history for around 180 countries. Every answer carries its source and its date. Public and read-only: no account, no sign-in, and no tool that can change anything. Streamable HTTP; in the official MCP registry as ch.antevo/executive.
The forward calendar — dated events the Executive Brief is watching (data prints, decisions, deadlines), each with the signal to read from it and its category. Use days_ahead (1..90, default 14) to set the horizon. Answers 'what's coming up that could move things?'
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | retail | |
| market | No | global | |
| days_ahead | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail about what is returned: dated events, the signal to read, and category, while also specifying the days_ahead range and default. No contradiction with 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?
Two tight sentences carry all the essential information: the resource, the output shape, the key parameter, and the question it answers. No filler or redundant restatement of the tool name.
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?
The tool is callable with defaults and the core days_ahead behavior is explained, and an output schema exists to document return values. However, scope and market remain unexplained, and with several sibling tools that could plausibly overlap, the description does not fully disambiguate when this tool should be preferred.
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 description coverage is 0%, so the description must compensate for missing parameter documentation. It explains days_ahead's range and purpose, but scope and market are left entirely to inference from their names and defaults, with no allowed values or behavior described.
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 defines the tool as a forward calendar of dated events the Executive Brief is watching, including signals and categories. It gives a concrete question the tool answers, so an agent can tell it apart from general market or risk tools, though it does not explicitly contrast with siblings like get_world_events.
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?
It provides a clear use context: answering 'what's coming up that could move things?' and explains how to set the horizon via days_ahead. It does not offer exclusions or compare against alternative tools, but the guidance is specific enough for common use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One coverage area's note in full — for example real-assets-shipping or real-assets-aviation. scope 'retail' (default) or 'institutional'; the institutional read is longer and assumes more. Optional as_of (YYYY-MM-DD) for a past edition, newest otherwise. Cheaper and more direct than pulling the whole brief to read one theme. Call list_coverage for the areas and their dates.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | ||
| as_of | No | ||
| scope | No | retail |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the read-only and idempotent annotations: institutional scope is longer and assumes more, as_of returns a past edition, and this tool is cheaper than the full brief. It also correctly implies a safe read operation with no destructive side effects.
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?
Four short sentences cover purpose, parameters, behavior, and alternatives without waste. The key purpose is front-loaded, and every sentence adds value.
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 output schema exists and annotations cover safety, the description supplies everything needed to call the tool correctly: parameter values, defaults, date behavior, and how to find valid areas. There are no significant gaps.
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 0%, so the description must carry parameter meaning, and it does: area is illustrated with examples, scope is given with allowed values and default, and as_of is specified with format and semantics. All three parameters are meaningfully explained.
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 action: retrieving one coverage area's note in full, with concrete examples like real-assets-shipping and real-assets-aviation. It also differentiates from siblings by framing itself as cheaper and more direct than pulling the whole brief.
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?
It explicitly explains when to use this tool versus alternatives: use it to read one theme instead of the whole brief, and call list_coverage to discover the areas and their dates. This gives the agent clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Antevo Executive Brief — today's editorial read on markets and world events: the hero takeaway, the regime, the themes that matter, key risks and a market snapshot. Pass as_of (YYYY-MM-DD) to retrieve the brief as it was published on a past date. scope: 'retail' or 'institutional'. The full brief is large; pass sections (comma-separated) to fetch only what you need — e.g. 'hero,regime,what_matters' for a quick read, 'signal' for the probability layer, or 'plain_language' for the desk's own jargon-free rendering (headline, decode, signal_read, theme_reads).
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| scope | No | retail | |
| market | No | global | |
| sections | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark the tool as read-only, idempotent, and non-destructive, the description adds meaningful behavioral detail: as_of returns the brief as published on a past date, the full brief is large, sections limits the payload, and 'plain_language' provides a specific desk-rendering with sub-fields. This goes well beyond what the annotations reveal and helps an agent predict output shape and cost.
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 dense but efficient: it opens with the product identity, then gives parameter usage, then closes with concrete section examples. Every sentence contributes useful information, and the examples make the section filtering behavior concrete without feeling padded.
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?
The description covers the tool's purpose, historical behavior, scope options, and section-level customization, and an output schema exists so return-value documentation is not the description's burden. The missing 'market' parameter and the lack of explicit sibling differentiation are material but not fatal gaps. Overall, an agent can use this tool effectively in most cases.
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 schema description coverage at 0%, the description must compensate for all parameters. It does explain as_of with a date format, scope with valid values, and sections with a rich list of examples. However, it provides no explanation for the 'market' parameter, leaving 1 of 4 parameters entirely undocumented, which is a clear gap for correct invocation.
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 identifies the resource—the Antevo Executive Brief—and its editorial contents: hero takeaway, regime, themes, key risks, and market snapshot. It uses retrieval verbs like 'retrieve' and 'fetch,' so an agent can understand what the tool returns. However, it does not explicitly distinguish this from sibling tools like get_executive_desk or get_executive_note, so differentiation is implied rather than stated.
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 gives concrete usage guidance: pass as_of for a past publication date, choose 'retail' or 'institutional' scope, and use sections to avoid fetching the large full brief. It also includes practical examples for section values. It does not mention when to choose this tool over related sibling tools or state exclusion criteria, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The longer-form desk read for today — analysis and research notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent, and non-destructive, so the description carries little safety burden. It adds some useful context—'for today' signals a dated, changing result—but it doesn't disclose anything beyond that temporal framing.
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?
One sentence, front-loaded with the key differentiator ('longer-form') and finished with content type. No wasted words or repetition of schema details.
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 an output schema and safety annotations, very little is needed to invoke it. The main gap is routing among the closely named siblings get_executive_brief and get_executive_note, which is only hinted at by 'longer-form' rather than stated.
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?
The tool has zero parameters, so there is no parameter documentation burden. The 100% schema coverage plus 0-parameter count make the baseline 4 appropriate; no description-level parameter guidance is needed.
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 names a specific resource ('the desk read') with a clear retrieval verb and adds the useful qualifier 'longer-form,' which roughly separates it from the executive brief/note siblings. It doesn't explicitly define what a 'desk read' is or name the sibling it is not, so it falls just short of full clarity.
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 phrase 'longer-form desk read for today' implies this is the in-depth daily analysis option, but the description never states when to prefer it over get_executive_brief or get_executive_note. Usage context is implied rather than explicit, with no alternatives or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One dated Executive Brief in full (YYYY-MM-DD) — the permanent record of what was published that day. Use after list_executive_notes to read a specific day, or to answer 'what did we say about X back then?'.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | Yes | ||
| scope | No | retail | |
| market | No | global |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds value by stating the result is the full, permanent record for a published day and by pinning the expected date format (YYYY-MM-DD).
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?
Two short sentences deliver the core behavior, date format, and primary use case without fluff. The most important scoping phrase ('one dated Executive Brief in full') is front-loaded.
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?
The description handles purpose, ordering relative to list_executive_notes, and date format, and an output schema is present. However, with 0% input-schema coverage, the unexplained scope and market parameters leave a real gap for an agent selecting values or understanding the tool's breadth.
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 description coverage is 0%, so the description needs to compensate for all three parameters. It implicitly covers as_of via 'dated (YYYY-MM-DD)' but says nothing about scope or market, which appear only as unannotated names with defaults.
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 names a specific resource ('one dated Executive Brief in full'), requires a date, and frames it as the permanent daily record. It differentiates itself from list_executive_notes by saying this is the follow-up read for a specific day, and from the many siblings by highlighting the dated-retrieval scope.
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 explicitly gives two triggers: use after list_executive_notes to read a specific day, and use it for retroactive questions like 'what did we say about X back then?'. This clearly routes an agent toward this tool and away from list_executive_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Major indices with recent history — use days_back (1..365, default 30) to see how markets have moved over a period.
| Name | Required | Description | Default |
|---|---|---|---|
| days_back | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds meaningful context about the time-window behavior and the type of information returned, which 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?
A single well-structured sentence with no filler. The core purpose is front-loaded and the parameter usage follows naturally.
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?
This is a simple, optional-parameter read-only tool with an output schema and comprehensive annotations. The description covers what the tool returns and how the parameter affects results, leaving no significant gap for an agent to invoke it correctly.
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 description coverage is 0%, so the description must carry the parameter meaning. It does so by providing the valid range (1..365), the default (30), and the effect on the result (market movement over the period). It does not clarify the odd string typing of the parameter, but it provides substantial semantic value.
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 a specific verb and resource ('Major indices') and adds the distinguishing element of recent history over a configurable period. It does not explicitly call out how it differs from sibling tools like get_market_snapshot, so it stops short of a 5.
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 explains the intended use of the days_back parameter and what the data shows, giving implied usage context. However, it does not state when to choose this tool over alternatives or mention any exclusions or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One macro series by ticker, newest first, with the date of its most recent observation stated on the response. These are QUARTERLY levels and they lag — the newest point is a quarter end, never today. Use search_macro_indicators to find the ticker. Optional since/until (YYYY-MM-DD) narrow the window.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | No | ||
| until | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, it discloses that results are ordered newest-first, that the response explicitly includes the date of the most recent observation, and that the underlying frequency is quarterly with a lag. These are meaningful behavioral traits that shape expectations. It does not contradict the 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?
Three tight sentences, each carrying substantive information: core behavior, data lag caveat, sibling pointer and optional date window. No filler or restatement of the title.
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?
The tool is well covered given the presence of an output schema and annotations: purpose, ordering, lag, date window, and sibling routing are all present. The only completeness gap is the undocumented limit parameter, but the default value in the schema partially mitigates the risk.
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 0% schema description coverage, the description must explain parameters. It covers since/until by giving the YYYY-MM-DD format and saying they narrow the window, and implies ticker is the key selector. However, the limit parameter is never explained, leaving its meaning (likely max observations) to inference.
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 states a specific verb and resource: retrieve one macro series by ticker, sorted newest first, and includes the date of the most recent observation. It differentiates from search_macro_indicators, which is for finding a ticker, and from the other market/report siblings.
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?
It explicitly directs the agent to use search_macro_indicators to discover the ticker, providing a clear alternative for a different need. It also warns that data are quarterly and lagged (newest point is a quarter end, never today), which helps the agent judge when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where markets stand right now — indices, FX, commodities, crypto.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety behavior. It adds useful context about temporal freshness ('right now') and coverage, but does not disclose deeper behavior such as data delays or aggregation logic.
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, compact, front-loaded sentence that conveys the tool's purpose and coverage with no filler. Every word adds meaning.
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, read-only snapshot tool with an output schema and clear annotations, the description is sufficient. It tells the agent what the snapshot contains and the broad asset classes included.
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?
The tool has zero parameters, so there is nothing for the description to elaborate on beyond the schema. The baseline of 4 applies because no parameter documentation is needed.
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's scope: a broad, real-time view of markets across indices, FX, commodities, and crypto. It differentiates from narrower siblings like get_indices and get_macro_series, though it does not use an explicit imperative verb like 'Get' or 'Return'.
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 phrase 'right now' implies it is for a current, broad market overview, and the asset-class list suggests coverage. However, it gives no explicit guidance about when to prefer this over related sibling tools such as get_indices or get_risk_radar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The risk radar — what the Antevo Executive Brief judges could go wrong from here, each with its trend, impact, probability and why it matters, plus the regime it sits in and the indicators that would confirm or kill it. Pass as_of (YYYY-MM-DD) for the radar as it stood on a past date. For how risks have DEVELOPED over weeks, use track_risk_evolution.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | ||
| scope | No | retail | |
| market | No | global |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it returns a point-in-time snapshot and supports historical as-of dates, which is not visible in the 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?
Two dense sentences with no filler. The first sentence front-loads the core value and output contents; the second handles historical usage and sibling differentiation. Every clause earns its place.
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?
The description richly covers outputs (and an output schema exists) and explains as_of, but it omits scope and market semantics that an agent would need to parameterize calls for different radar views. It is adequate for a basic call with defaults but not fully complete for the tool's intended variations.
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 description coverage is 0%, so the description must compensate. It documents as_of format and meaning, but says nothing about scope or market — two of the three parameters — leaving their semantics to guesswork despite defaults 'retail' and 'global'. This is a substantial gap.
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 identifies a specific deliverable — the risk radar as judged by the Antevo Executive Brief — and enumerates its contents (trend, impact, probability, why it matters, regime, indicators). It also distinguishes from track_risk_evolution by positioning that sibling as the tool for how risks have developed over weeks.
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?
It states when to use this tool (to see current or as-of risk radar), how to pass a historical date ('Pass as_of (YYYY-MM-DD)'), and explicitly routes trend-over-time use to track_risk_evolution. This gives clear contextual choice guidance against the main sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Geopolitical events over a look-back window (days_back 1..90, default 7) — conflict, chokepoints, sanctions and related signals. The public cut. Pass layers to narrow — waterways, armed_conflicts, hotspots, regulatory, cyber, sanctions — comma-separated. All six together run large and two of them truncate; ask for one or two and those come back much deeper. row_limits on the response says what was in force, so you can tell a layer that ended from one that was cut off. Three reference layers are opt-in and not in the default set: submarine_cables (routes and landing points), disasters (USGS, GDACS, EONET) and displacement (UNHCR, by origin and corridor). Name them to get them.
| Name | Required | Description | Default |
|---|---|---|---|
| layers | No | ||
| days_back | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only and idempotent, and the description adds substantial behavioral context beyond that: it reveals that all six default layers run large, two truncate, that row_limits indicates whether truncation occurred, and that some layers are opt-in. This gives the agent accurate expectations about response completeness and performance.
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?
Despite being longer than average, every sentence carries distinct, non-redundant information: window defaults, layer behavior, truncation signals, and opt-in layers are all covered efficiently. The core purpose is front-loaded, and the additional detail is justified because the input schema provides no property descriptions.
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?
The description covers the tool's purpose, parameter semantics, defaults, performance caveats, and opt-in behavior. An output schema exists, so return-value documentation is unnecessary here. Given the tool's complexity and the zero-coverage schema, this description leaves no important calling detail unaddressed.
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 0%, but the description fully compensates: it defines days_back as an integer range 1..90 with a default of 7, and it enumerates exact layer names, comma-separated formatting, and which reference layers require explicit opt-in. This is more than enough for an agent to construct valid arguments.
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 identifies the tool as retrieving geopolitical events over a configurable look-back window, naming the signal types (conflict, chokepoints, sanctions). It is specific about the resource and scope, but it does not explicitly contrast itself with sibling tools like get_risk_radar or get_catalysts, so it falls short of full sibling differentiation.
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 gives strong in-tool usage guidance: it explains how to pass layers, that one or two layers return deeper data, and that three reference layers are opt-in. However, it never states when to prefer this tool over alternatives or when not to use it, so the when-to-use guidance is only implied by the tool's domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the Antevo Executive connector exposes. No account required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the useful operational fact that no account is required, which goes beyond the annotations and helps an agent understand access requirements.
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 short, information-dense clauses with no wasted words. It front-loads the core purpose and adds the no-account detail without repeating the title or schema.
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 parameterless, read-only, idempotent discovery tool with an output schema, the description provides sufficient purpose and auth context. There are no input parameters to explain, and return values are covered by the output schema.
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?
The tool has zero parameters and schema coverage is 100%, so there are no parameter semantics for the description to add. With no parameters to document, a baseline of 4 is appropriate.
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 states that the tool lists what the Antevo Executive connector exposes, and the resource 'capabilities' is clearly distinct from the sibling data-retrieval tools. It avoids pure tautology by adding connector-specific scope, though it does not explicitly name or distinguish a sibling tool.
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?
There is no guidance on when to use this tool versus alternatives such as list_coverage or list_executive_notes. The only usage-adjacent detail is 'No account required,' which is a prerequisite rather than a comparison or selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the Antevo desk writes on beyond the daily brief — shipping, aviation, yachts, energy, infrastructure, real estate, commodities, geopolitics, AI and technology, energy transition, demographics, generational wealth, succession planning, art. Each with the date of its most recent note. Pass an area to get_coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds meaningful scope: it is 'beyond the daily brief' and includes the most-recent-note date for each area. It does not add details such as ordering, pagination, or response structure, but the output schema likely covers those.
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 informative sentence plus a short routing sentence. The long topic list is justified because naming the coverage areas is the core value of the tool. It is front-loaded with the scope ('beyond the daily brief') and ends with a useful pointer to get_coverage, with no filler.
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 no-parameter, read-only listing tool with a rich output schema and safety annotations, the description is nearly complete: it explains what is listed, that dates are included, and where to go for a specific area. It does not explicitly frame the tool as a discovery/browsing step, but the content strongly implies it.
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?
The tool has zero parameters and the input schema is empty, so there is no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4; the description appropriately includes no parameter-related confusion.
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 identifies the resource as the Antevo desk's coverage areas and states that each entry includes the date of the most recent note. It also points to get_coverage as the destination for a specific area, which distinguishes the list-level purpose from the single-area sibling. However, it never explicitly says 'this returns a list of coverage areas,' relying on the tool name and inference.
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 phrase 'Pass an area to get_coverage' provides a clear alternative for when a specific area's content is needed, implying that list_coverage is the browsing/overview tool. It gives useful context that this tool covers topics beyond the daily brief, but it does not explicitly state when to prefer list_coverage over list_capabilities or list_executive_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The archive of past Executive Briefs, newest first — each with its date, title, subtitle and hero line. Use this to see what has been covered, to find the date of a story, or to follow how a theme developed over time, then call get_executive_note for the full text of a given day.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| market | No | global |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as readOnly, idempotent, and non-destructive. The description adds useful behavioral context by noting the ordering ('newest first'), the archive scope, and that only summaries are returned. This goes beyond the annotations without contradicting them.
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 with no filler. It front-loads the core definition and return content, then provides concise usage guidance and cross-referencing. Every clause earns its place.
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?
The description explains what the tool lists and how to proceed to full text, and an output schema exists so return structure is covered. However, the two optional parameters, especially 'market', are left undocumented, which is a meaningful gap for a tool intended to list archived briefs. Overall adequate but not fully complete.
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 description coverage is 0%, and the description does not explain either 'limit' or 'market'. While 'limit' may be self-explanatory, 'market' is ambiguous and lacks any guidance about acceptable values or how it affects results. The description fails to compensate for the schema's missing parameter documentation.
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 a specific action ('list') and resource ('executive notes'), characterizes the archive as 'past Executive Briefs, newest first', and enumerates the fields returned (date, title, subtitle, hero line). It also differentiates itself by pointing to get_executive_note for full text, so an agent can distinguish this tool from its sibling.
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 gives explicit use cases: 'see what has been covered', 'find the date of a story', and 'follow how a theme developed over time'. It also names the alternative get_executive_note and tells the agent to call it for full text, making the routing between tools clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a macro-economic series by name or country — CPI, policy and market interest rates, equity indices, house prices, industrial production, commodities. Covers 180 countries, some back to 1920. Returns each series' ticker and the span it actually covers; pass the ticker to get_macro_series. country takes either a name ('Switzerland') or an ISO-3 code ('CHE'). Search first: there are tens of thousands of series and they cannot be listed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| country | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: it returns the ticker and the span each series actually covers, discloses coverage breadth (180 countries, some back to 1920), and explains that series cannot be listed — only searched. No contradiction with 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?
Five sentences, each earning its place: purpose with examples, coverage scope, return value plus downstream workflow, country parameter format, and a usage directive. The description is dense but efficient, front-loaded with the core purpose, and uses compact formatting (em-dashes, semicolons) without waste.
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?
With an output schema present, return-structure details are already covered. The description addresses search semantics, geographic and temporal coverage, the ticker+span return behavior, the next-step workflow, and the country parameter format. The only notable gap is the undocumented `limit` parameter, which is a minor omission for a search tool of this profile.
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 description coverage is 0%, so the description must carry the documentation burden. The `country` parameter is explicitly documented with format and examples ('Switzerland' or 'CHE'). The `query` parameter is only implicitly defined through the examples (CPI, commodities), not formally described. The `limit` parameter is entirely undocumented, leaving its behavior and default semantics unexplained.
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 opening clause 'Find a macro-economic series by name or country' names a specific verb, resource, and scope, followed by concrete examples (CPI, interest rates, equity indices) that pin down the domain. It also differentiates itself from the sibling get_macro_series by positioning this tool as the search entry point ('pass the ticker to get_macro_series').
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?
'Search first: there are tens of thousands of series and they cannot be listed' is an explicit directive that tells the agent when this tool is the correct entry point. The instruction to pass the returned ticker to get_macro_series provides a clear workflow with the most relevant sibling. However, it does not explicitly mention when not to use this tool versus other siblings like get_indices or list_coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every risk radar the brief published over recent weeks, in one call — each dated board with its regime and its risks, oldest first. Use this to see which risks are new, which have been carried for weeks, which dropped off, and how their trend, impact and probability moved. Read the boards in order and group the risks yourself: the brief rephrases the same risk every day, so match them by meaning, not wording. days_back 7..90, default 30. detail trades size for depth: 'counts' for grades only (chart the board), 'titles' to also group themes, 'full' (default) to also read why each risk matters — a 90-day pull is roughly a third the size at 'counts'.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | retail | |
| detail | No | full | |
| market | No | global | |
| days_back | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly and idempotent behavior, and the description adds substantial non-obvious behavioral context: boards are dated, ordered oldest first, and the same risk is rephrased daily so matching must be semantic. It also discloses the size/depth tradeoff between detail levels and quantifies a 90-day pull at 'counts' as roughly a third the size. This goes well beyond the 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 dense but well organized: core behavior first, then usage intent and interpretation caveat, then parameter specifics. Every sentence adds necessary information, and there is no padding or redundancy. The length is justified by the tool's multi-board, multi-level detail complexity.
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 complexity, the description covers the essential workflow: what is returned, ordering, how to interpret repeated risks, and how detail affects output size. The output schema exists, so return-value documentation is not the description's burden. The remaining gap is that scope and market parameters are not explained, which slightly reduces completeness for an agent deciding how to invoke the tool.
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 description coverage is 0%, so the description must compensate. It does explain days_back range and default, and details the allowed values and meaning of detail ('counts', 'titles', 'full'). However, scope and market are left entirely undocumented, with only their defaults hinting at meaning. The compensation is strong for two parameters but incomplete overall.
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 explains that this tool returns all risk radar boards published over recent weeks, dated and sorted oldest first for trend analysis. It distinguishes itself from the sibling get_risk_radar by its temporal aggregation: instead of a single snapshot, it gives the full evolution of risks, regimes, and metrics. The specific use case of identifying new, carried, and dropped risks is explicit.
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 states when to use the tool: 'Use this to see which risks are new, which have been carried for weeks, which dropped off, and how their trend, impact and probability moved.' It also gives practical guidance to read boards in order and group risks by meaning. It does not explicitly name a more appropriate sibling for a single snapshot, so it lacks an explicit exclusion, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_catalystsget_coverageget_executive_briefget_executive_deskget_executive_noteget_indicesget_macro_seriesget_market_snapshotget_risk_radarget_world_eventslist_capabilitieslist_coveragelist_executive_notessearch_macro_indicatorstrack_risk_evolutionClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools map clearly to distinct resources: get_* for retrieval, list_* for enumeration, search_* for lookup, track_* for time series. Some overlap exists between get_executive_brief, get_executive_note, and get_executive_desk, and between get_indices and get_market_snapshot, but descriptions clarify the intended use. Overall an agent can usually tell which tool to pick with little ambiguity.
Tool names follow a highly consistent snake_case verb_noun pattern: get_, list_, search_, and track_ prefixes clearly indicate the operation. Resource nouns like executive_brief, risk_radar, world_events, and macro_series are descriptive and predictable. There are no mixed conventions or vague verbs.
Fifteen tools is on the higher end but remains within a reasonable range for a server covering briefs, notes, coverage areas, macro data, market snapshots, and risk tracking. Each tool has a plausible purpose, though a few could arguably be consolidated, such as the separate executive brief/note/desk retrieval tools. The count does not feel bloated or excessive for the stated scope.
The tool surface covers the core lifecycle of the domain: listing and retrieving briefs, coverage, macro series, indices, risk radars, and world events, plus search for macro indicators. Minor gaps exist, such as no way to search editorial briefs or coverage notes by keyword, and no direct retrieveal of catalysts beyond a forward horizon. These are workable gaps and do not prevent most agent workflows.