get_chart_pickCloselook’s Weekly Chart Pick: one standout name from the Directional Flow engine each week, worked through by hand — the setup bullets, the house reading and the STANDING closing forecasts (diary views, scored afterwards). Mirrors closelook.net/chart-pick/. Weekly (Friday).
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return every published pick (summaries) | |
| date | No | Optional YYYY-MM-DD of a specific pick; omit for the latest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive, and the description adds useful behavioral context: it is a curated, hand-worked pick, includes closing forecast details, mirrors the public web page, and is published weekly on Friday. It doesn't contradict annotations and gives more insight into the nature of the output.
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 compact, front-loads the main purpose, and adds essential context about content and cadence in two sentences. The phrasing is slightly ornate and cryptic at the end ('STANDING... diary views, scored afterwards'), but it does not waste words.
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 simple read-only retrieval with zero required parameters and no output schema, the description covers the core context: what the pick is, where it comes from, and the weekly publication timing. It leaves minor ambiguity about exact response structure, but this is not critical for invocation.
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 input schema fully documents both parameters ('all' and 'date') with meaningful descriptions. The tool description does not need to repeat those, but it also adds no extra semantic details or usage nuances for the parameters beyond the schema, so the baseline 3 applies.
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 returning Closelook's weekly Chart Pick: one standout name from the Directional Flow engine, with setup bullets, house reading, and forecast views. It is not a tautology and gives the resource and cadence, though it does not use an explicit retrieval 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 cadence and format imply when to use this tool — for the weekly Friday Chart Pick — but the description does not explicitly say when to use it over sibling tools or when to use the 'all' vs 'date' parameters. It identifies what the tool offers but leaves the choice of alternatives to the agent.
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.