get_day_hubCloselook’s trading-day hub: for a given date (or the latest), the day’s Morning 10 headline, Midday 10 headline and Daily Pulse edition(s) with links — the same pieces closelook.net/days// ties together. Last 90 trading days.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD; omit for the latest day with content | |
| days | No | Return the last N days as a list (1–14) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and non-destructive, so the description's key behavioral additions are the 'Last 90 trading days' availability constraint and the default of the latest day when date is omitted. This is useful context beyond the annotations, but the description does not disclose other traits such as result structure or behavior when no content exists.
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 dense sentence that front-loads the tool's purpose and includes the valuable 90-day limit. It is efficient and avoids repetition, though the final possessive clause about the web page is slightly indirect rather than purely functional.
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 read-only tool with 100% schema coverage and only two optional parameters, the description provides enough context about what the agent will receive, including the specific editions and the 90-day window. It is not fully exhaustive, but the missing details are already covered by the schema or annotations.
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?
Since schema description coverage is 100%, the schema already documents both the 'date' and 'days' parameters fully. The description adds no new parameter-level semantics, only restating the date-or-latest behavior and a 90-trading-day constraint.
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 the trading-day hub, enumerating exactly which pieces are returned for a given date: the Morning 10 headline, Midday 10 headline, and Daily Pulse edition(s) with links. It is resource-specific and distinct from sibling tools that return individual pieces, though it relies on nouns rather than an explicit action verb like 'returns' or 'gets'.
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 the tool should be used when you need all of a trading day's content pieces together, particularly when you have a specific date or want the latest. It does not explicitly say when not to use it or name a sibling alternative, leaving usage to be inferred.
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.