maatsii_chart_mapThe authoritative 200-chart / 25-group map (id -> symbol/timeframe/group), including the group ALIASES (NQ, GOLD, PLTR, ...) and the derived tickCharts inventory (which ids are 100T/1000T tick charts). Chart ids are non-contiguous; use this to route a symbol to the right ids. The printed header on a render always wins over the map.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds important context: chart IDs are non-contiguous, the map includes aliases and derived tickCharts inventory, and the precedence rule about printed headers. This goes beyond the structured annotations and helps an agent understand behavior and limitations.
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 and information-dense. Every sentence adds value: the authoritative scope, the content of the map, the non-contiguity caveat, the routing use case, and the header precedence rule. No wasted 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 static read-only map tool with no parameters and no output schema, the description covers all necessary information: what data is included, how to use it, and a critical behavioral caveat. There is nothing an agent needs to call it correctly that is missing.
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 schema detail to compensate for. The description explains what the returned data contains (the map and its components), which is sufficient for a parameterless tool.
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 purpose: providing an authoritative map of chart IDs to symbols/timeframes/groups, including aliases and tickCharts inventory. It uses a specific verb ('map') and resource, and differentiates from sibling tools like maatsii_get_chart by focusing on routing symbols to IDs.
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 states when to use the tool: 'use this to route a symbol to the right ids.' It also provides a critical caveat that the printed header wins over the map, which guides correct usage. However, it does not mention explicit alternatives or when not to use it, leaving a slight gap.
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.
Each tool has a clearly distinct purpose: data fetching (get_chart, get_group), setup management (list, get, match), and reference guides (framework, chart_map, fan_guide, reading_guide, get_concept). Although several guides overlap in explaining concepts, their scopes are well-differentiated by descriptions and use cases.
All tools share the consistent `maatsii_` prefix and use lowercase snake_case, but the pattern mixes verb-first names (get_chart, list_setups, match_setup) with noun-style names (analysis_framework, chart_map, fan_guide). Minor inconsistency, yet still readable and predictable.
10 tools is squarely within the ideal range for a specialized analysis server. Each tool covers a distinct need without redundancy, and the count feels balanced for both data access and educational support.
The tool surface fully supports the workflow: fetching individual charts and groups, accessing all setups, matching candidates against visual data, and providing necessary methodology guides. No obvious missing operations or dead ends within the intended read/analysis scope.