get_market_breadthS&P 500 market breadth: the percentage of index members above their 50-day and 200-day moving averages, with RSI, trend and 52-week range for each breadth series. A gauge of how broad the current advance or decline is.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| pct_above_50d_ma | No | ||
| pct_above_200d_ma | No |
Changes observed during successful MCP inspections.
Output schema / properties / date / typePrevious value: -"string"New value: +[
+ "string",
+ "null"
+]Output schema / properties / pct_above_200d_ma / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / properties / pct_above_50d_ma / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "pct_above_200d_ma": {
+ "type": "object"
+ },
+ "pct_above_50d_ma": {
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the burden is lower. The description adds useful content about what data is returned (RSI, trend, 52-week range per series), which is context beyond the annotations. However, it doesn't add behavioral details like data freshness or scope caveats.
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 tightly written sentences: the first names the resource and lists exactly what is measured; the second supplies the interpretation. Every clause earns its place 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?
An output schema exists, so the description needn't detail return values, and with no parameters there's little else to specify. It covers what the tool is and why it matters. A minor gap is the absence of any usage routing relative to the many sibling context tools.
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 takes zero parameters, so there is nothing to document. Baseline is 4 for a parameterless tool, and the description appropriately focuses on the return content rather than nonexistent inputs.
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?
States a specific resource (S&P 500 market breadth) with exactly what it measures (percentage of members above 50/200-day MAs) and the derived metrics per series. This is clearly distinguishable from siblings like get_technical_indicators (per-instrument) and get_macro_context (macro data).
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 what the tool is used for (gauging how broad an advance/decline is) but provides no explicit when-to-use guidance or alternatives. No sibling tools are named to route the agent elsewhere.
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.