get_factor_regimeCloselook’s factor-regime read: the momentum/low-volatility ratio (SPMO vs SPLV) against its 50-day trend — which factor is leading, how stretched the ratio is (3-year percentile), and the 20/60-day rate of change. The fastest single read on risk appetite under the index surface. End-of-day.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safe nature is known. The description adds useful context not in the annotations: that this is an end-of-day reading, and it details the metrics computed (50-day trend, percentile, ROC). It does not need to disclose side effects since it is a pure read.
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 tight sentences that front-load the purpose ('factor-regime read') and then pack relevant detail: asset pair, trend horizon, output metrics, and 'end-of-day' timing. Every sentence earns its place, with no fluff.
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 tool with no output schema, the description is remarkably complete: it explains the exact indicator (SPMO/SPLV), the analysis (vs 50-day trend), the outputs (leading factor, percentile stretch, ROC), and the timing (end-of-day). The agent can select and invoke this tool confidently without further clarification.
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 0 parameters, so the baseline is 4. The description does not need to explain params, and it doesn't. It still adds context about what the tool computes, but the schema is empty, so no param semantics are required.
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 a factor-regime read: the momentum/low-volatility ratio (SPMO vs SPLV) against its 50-day trend, including which factor leads, how stretched the ratio is (3-year percentile), and 20/60-day rate of change. This specific verb (read) and resource (factor regime) distinguishes it from sibling tools like get_credit_stress or get_signal_scores.
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 clear context: 'The fastest single read on risk appetite under the index surface.' It implies when to use (quick risk-appetite check) but does not explicitly mention when not to use or name alternative tools for other scenarios. This is a clear context without exclusions, so a 4 is appropriate.
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 map cleanly to a distinct Closelook surface — indices, macro boards, rankings, research, tape, wires. There are a few near-neighbor pairs like get_df_ranking vs get_ranking and get_market_instrument vs get_stock_snapshot, but the detailed descriptions resolve most potential misselection.
Every tool follows a clear imperative verb + noun pattern — get_, define_term, compare_indices, search_closelook — with consistent snake_case and essentially all resource-oriented nouns. The naming is predictable and easy to navigate.
25 tools is on the heavy side, above the typical well-scoped range, but each endpoint maps to a meaningful product area of Closelook's public site. The count is justified by the breadth of a financial intelligence service, though it could have been trimmed slightly.
The tool surface covers the major Closelook workflows: indices, rankings, macro monitors, stock-level data, earnings, wires, research search, and portfolio snapshots. For a read-only intelligence server there are no obvious dead ends — depth and background material is paired with lookups and daily updates.