This server exposes Vanoe Market Intelligence as MCP tools an AI assistant can call for stock and macro analysis.
Get a composite 0–100 verdict with rationale for a ticker (accumulate/hold/distribute/avoid).
Get trend stage analysis (Basing, Advancing, Topping, Declining) for up to 50 tickers at a time.
Get backtest-safe weekly stage history for one ticker, with configurable lookback.
Get Point & Figure signals, breakout patterns, and relative strength vs SPY for multiple tickers.
Get sector breadth showing bullish-percent by sector.
Get the macro regime, including rates, inflation, yield curve, and positioning.
Get recent SEC insider transactions and 8-K filings for a ticker.
Get upcoming macro calendar events like FOMC, CPI, and payrolls within a configurable window.
Check current billing-period usage and remaining credit quota.
Fail gracefully by returning structured error objects instead of raising exceptions, so assistants can explain failures.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vanoe-intelligence-mcp What's the verdict on NVDA and why?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Exposes the Vanoe Market Intelligence API as tools any MCP-capable AI assistant (Claude Desktop, Claude Code, Cursor, etc.) can call directly: a composite 0–100 verdict per ticker, trend-stage analysis (current and a backtest-safe weekly history), Point & Figure signals, sector breadth, the macro risk regime, SEC insider and 8-K filings, the macro calendar, and your usage.
This is a thin authenticated client, not a free tier: every tool call is a real, metered call against your plan using your own API key, exactly like calling the REST API yourself. Get a free key (1,000 credits a month, no card) at https://api.vanoe.ai/signup.
Informational data only. Not financial advice. See https://api.vanoe.ai/terms.
The same tools are served over MCP's streamable HTTP transport by the API itself, for clients that take a URL (Claude.ai custom connectors, ChatGPT, hosted agent platforms):
https://api.vanoe.ai/mcp with Authorization: Bearer <your key>, or
https://api.vanoe.ai/mcp/k/<your key> for clients that cannot send headers
(the key page after signup prints this URL; treat it like a password).
Stateless, JSON responses, metered exactly like the REST API. Use the package below when you want the server to run on your own machine.
Related MCP server: Financial Data MCP Server
Download vanoe-market-intelligence.mcpb
and open it with Claude Desktop (macOS or Windows). It asks for your API key
once, stores it securely, and installs the server itself using the uv
runtime. Source of the bundle is in mcpb/; rebuild with
npx -ai/mcpb pack mcpb vanoe-market-intelligence.mcpb.
No install step is needed with uv — uvx fetches
and runs the package on demand:
uvx vanoe-intelligence-mcpOr install it permanently with pipx install vanoe-intelligence-mcp or
pip install vanoe-intelligence-mcp, which puts a vanoe-intelligence-mcp
command on your PATH.
Set one environment variable, VANOE_API_KEY. VANOE_API_BASE_URL is optional
and defaults to https://api.vanoe.ai.
Claude Desktop (claude_desktop_config.json) and most other clients:
{
"mcpServers": {
"vanoe": {
"command": "uvx",
"args": ["vanoe-intelligence-mcp"],
"env": { "VANOE_API_KEY": "sk_live_your_key_here" }
}
}
}Claude Code:
claude mcp add vanoe -e VANOE_API_KEY=sk_live_your_key_here -- uvx vanoe-intelligence-mcpThen ask your assistant things like "What's the verdict on NVDA and why?", "Which stage are AAPL, MSFT and AMD in?", or "Is the macro regime risk-on right now?" — it will call the tools below.
Tool | API call | Credits |
|
| 5 |
|
| 1 per ticker |
|
| 5 |
|
| 1 per ticker |
|
| 1 |
|
| 1 |
|
| 1 |
|
| 1 per ticker |
|
| 1 |
|
| 0 |
Tools never raise. Any failure — missing key, network error, quota exceeded,
an unknown ticker — comes back as {"error": {"code", "message", "http_status"}} carrying the API's own message, so the assistant can explain
what happened instead of crashing the call.
Webhook management is deliberately not exposed: it is account administration, not something to do mid-conversation. Use the REST API for that.
git clone https://github.com/peeroren/vanoe-intelligence-mcp.git
cd vanoe-intelligence-mcp
python -m venv .venv && . .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e '.[test]'
pytest tests
VANOE_API_BASE_URL=http://localhost:8000 VANOE_API_KEY=sk_live_… vanoe-intelligence-mcpSource lives at https://github.com/peeroren/vanoe-intelligence-mcp; issues and
pull requests welcome. If you also run the API server locally, install this
in its own virtualenv, separate from the API server's own
requirements.txt: the mcp SDK pulls in a newer starlette than the API's
FastAPI pin tolerates, and sharing one environment breaks the API server with
Router.__init__() got an unexpected keyword argument 'on_startup'. End users
never hit this (the MCP server runs on their machine, next to their assistant).
tests/manual_e2e_smoke.py runs the real server as a subprocess over stdio
against a reachable API with a real key; it is not part of pytest.
The MCP Python SDK is on v2: the server class is
mcp.server.mcpserver.MCPServer (older tutorials show FastMCP at a
different import path).
python -m build
twine upload dist/*Bump version in pyproject.toml first. The older INTEL_API_KEY /
INTEL_API_BASE_URL variable names are still accepted for compatibility.
Upcoming macro events (FOMC, CPI, payrolls) within a look-ahead window in days (default 10, max 60).
| Name | Required | Description | Default |
|---|---|---|---|
| within_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals the event categories, the look-ahead semantics, and the default/maximum window, which is meaningful context. It does not describe output ordering or edge cases, but the presence of an output schema reduces the need for that detail.
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, focused sentence with no filler. The key information — what events, what window, and the bounds — is front-loaded and every word contributes value.
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 single-optional-parameter tool with an output schema, the description covers the essential semantics: event types, time horizon, and parameter bounds. It is slightly incomplete in not addressing ordering or how event categories are selected, but overall it is sufficient for correct 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 schema has 0% description coverage, so the description must fully explain the parameter. It does: 'within days' is described as the look-ahead window, with default 10 and max 60, adding the maximum constraint not present in the schema.
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 resource as upcoming macro events (FOMC, CPI, payrolls) and the look-ahead window, making the tool's function apparent. However, it lacks an explicit imperative verb like 'list' or 'retrieve', and does not explicitly distinguish itself from the sibling get_macro.
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 is for fetching upcoming macro events within a configurable number of days, and gives useful default/max bounds. It does not mention when to prefer this tool over siblings such as get_macro or provide exclusions, so the routing guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent SEC insider transactions (Form 4) and 8-K filings for one ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to state whether the operation is read-only (though 'get' implies it), what 'recent' means in terms of timeframe, how many filings are returned, or any rate limits. The description is too sparse to convey behavior beyond the basic action.
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, front-loaded sentence that immediately states the core purpose. It is efficient and contains no filler, making it easy for an agent to parse quickly.
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?
While the tool is simple (one parameter) and has an output schema, the description omits critical operational details such as the exact time window for 'recent', any pagination or limit behavior, and whether both Form 4 and 8-K are always returned together. With no annotations and a sparse description, an agent would likely need to probe the tool to understand its full behavior.
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?
Schema coverage is 0%, so the description must compensate for the undocumented 'ticker' parameter. It adds 'for one ticker', which confirms the parameter is a single symbol, but this is already obvious from the parameter name and type. No additional constraints, formats, or examples are provided, so the description adds minimal value beyond the schema.
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 a specific verb ('get'), a resource ('filings'), and the scope ('one ticker'), and explicitly enumerates the types (Form 4 and 8-K). This distinguishes it from sibling tools like get_macro or get_stage, which target entirely different 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 provides no guidance on when to use this tool versus alternatives. It does not mention any preconditions, nor does it exclude any scenarios. Since the siblings are semantically unrelated, an agent might still infer usage from the domain, but no explicit direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Macro regime (risk_on/neutral/risk_off), rates, inflation, yield curve, positioning.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not specify whether the tool returns historical data, requires authentication, or has rate limits. It also doesn't describe the output schema, though an output schema exists. The description is a factual list of contents, which is standard, but it lacks depth.
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 concise, a single sentence that lists the key data categories. It is appropriately sized for a zero-parameter tool, and the main regime concept is highlighted first. However, it could be slightly more structured to separate the headline regime from the supporting data.
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?
Given that there is an output schema, the description does not need to explain return values. However, for a zero-parameter tool, the description is fairly complete in listing the data areas. The main gap is the lack of behavioral context (e.g., is this a snapshot? current or historical?), which limits full completeness.
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 parameter semantics to explain. The description covers the broad categories of data returned, but since there are no parameters, the lack of specific param info is not an issue. Baseline 4 is appropriate because the description adds context about what data is included.
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 macro regime data (risk_on/neutral/risk_off) along with rates, inflation, yield curve, and positioning. This is specific and distinguishes it from siblings like get_stage or get_sector_breadth, which focus on other aspects.
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 when to use this tool (when macro regime data is needed), but it does not explicitly state when not to use it or mention alternatives. Given the sibling tools, no direct comparison is made, so the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Point & Figure signal, breakout pattern, and relative strength vs SPY, for up to 50 tickers. Pass tickers as a comma-separated string.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It shares a scope limit (50 tickers) and the input format, but it never states whether this is a pure read-only lookup, what the response shape is beyond schema knowledge, or how errors/limit violations behave.
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 sentences front-load the core capability and then state the essential input rule. Every word adds information; no fluff. A slightly richer context about output or alternatives could add more, but the text is compact.
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?
With only one parameter, an output schema present, and the input syntax + limit stated, there are enough operational details for a basic call. The main missing piece is sibling differentiation, though that is more a usage guidance concern than a completeness one.
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?
Schema description coverage is 0%, and with a single bare string parameter the description adds critical meaning: comma-separated tickers and a 50-ticker maximum. This bridges a serious gap in the input schema and gives an agent the format it needs for a successful call.
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 names a specific resource (Point & Figure signal, breakout pattern, relative strength vs SPY) and the target tickers, so an agent can tell it apart from siblings like get_stage or get_macro without opening the schema. It does not explicitly name any sibling, but the substantive content is enough to identify its purpose.
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 text provides practical usage details: hold up to 50 tickers and pass them as a comma-separated string. It gives no when-to-use-versus-alternatives guidance or exclusions, so it leans on the agent to infer when P&F analysis is the right choice relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bullish-percent breadth by sector — the % of names in each sector on a Point & Figure buy signal.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It does clarify the core computation of the metric (buy-signal percentage), which is valuable. However, it discloses nothing about data recency, whether results are current or historical, or any limitations, leaving a noticeable gap.
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 efficient sentence, front-loaded with the metric name, followed by a concise parenthetical definition. No words are wasted and the structure makes the meaning immediately accessible.
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 parameterless tool with an output schema, the description adequately explains what the tool returns and how the metric is computed. It does not specify whether results cover all sectors in a given list or any period, but given the simplicity of the tool, the information provided is largely sufficient.
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 the schema coverage is 100% and there is no parameter documentation burden. The baseline of 4 applies because there is nothing the description needs to add about parameters.
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 states the exact resource and metric: bullish-percent breadth by sector, defined as the percentage of names on a Point & Figure buy signal. This is specific enough to distinguish it from siblings like get_pnf or get_macro, and an agent can infer exactly what data is returned.
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 no guidance on when to use this tool versus alternatives. It does not name any sibling tool, onboarding conditions, or exclusions. Because the description solely defines the metric, the usage context is left entirely to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Short pressure for up to 50 tickers: FINRA daily short-sale volume (share of volume sold short, latest, 10-day average, trend; market norm roughly 40-55%) plus the latest short-interest report (shares short, days to cover, change). Pass tickers as a comma-separated string.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose useful behavioral context: a 50-ticker cap, the data sources (FINRA daily short-sale volume plus short-interest report), and an interpretive baseline ('market norm roughly 40-55%'). However, it says nothing about error handling for invalid tickers, data staleness/lag, or partial results, which matters for a batch retrieval tool.
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 sentences, zero waste, front-loaded with the resource and its content before the input instruction. Every clause (metrics list, benchmark, format) earns its place.
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 return-value explanation is not needed, and the description covers content, limit, and input format. Only minor gaps remain (repeat vs. error behavior on bad tickers), which is acceptable for a single-parameter read tool.
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?
Schema description coverage is 0%, so the description must compensate, and it does: it specifies the required input format ('comma-separated string') and the cardinality limit (up to 50 tickers). It goes beyond the bare 'type: string' schema, though it does not address spacing, case, or invalid-ticker handling.
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 names a specific verb+resource ('Short pressure') and details exactly what data is returned: FINRA daily short-sale volume metrics and the latest short-interest report. No sibling tool (macro, stage, pnf, breadth, verdict, filings, calendar, usage) overlaps this retrieval, so an agent can uniquely identify it.
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?
It implies a use case (short-pressure analysis) but never states when to choose this tool over alternatives or any prerequisites. There is no when-not-to-use guidance and no routing to sibling tools, leaving usage entirely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stage analysis (1=Basing, 2=Advancing, 3=Topping, 4=Declining) for up to 50 tickers. Pass tickers as a comma-separated string, e.g. 'AAPL,MSFT,NVDA'.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose a meaningful constraint—'up to 50 tickers'—and the 1-4 stage semantics, which goes a little beyond the raw schema. However, it does not state that the call is read-only, what happens when more than 50 tickers are passed, how errors are handled, or how current/fresh the stage values are, so the behavioral picture is only partially painted.
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 short sentences: the first explains the tool's purpose and the stage scale, the second gives the input format and a concrete example. Every sentence earns its place; there is no filler or redundancy.
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 one-parameter tool with an output schema, the description gives enough to make the call. Yet it never states that this is the 'current stage' tool, nor does it address the >50-ticker behavior or mention when to prefer get_stage_history. These gaps mean an agent may still hesitate when selecting between get_stage and its sibling.
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 parameter schema only says 'tickers' is a string, and schema description coverage is 0%. The description materially compensates by specifying that the string must be comma-separated, giving a concrete example ('AAPL,MSFT,NVDA'), and setting the 50-ticker limit. This turns a bare schema slot into a directly actionable parameter specification.
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 states the resource ('stage analysis'), defines the output scale (1=Basing, 2=Advancing, 3=Topping, 4=Declining), and includes the 'up to 50 tickers' constraint. It is clear about what the tool computes, though it does not explicitly say 'current stage' or name sibling alternatives such as get_stage_history, so differentiation is left to the tool name.
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?
There is no guidance for when to use this tool versus get_stage_history, get_macro, or get_pnf. The description gives an input example but does not say whether to reach for this tool for current stages only, nor what an agent should use if historical stage data is needed. Selection advice is effectively absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical weekly trend-stage series for one ticker, walk-forward computed (no lookahead) — the only commercial source of trend stages as a backtest-safe data series. weeks defaults to 104, max 520.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | ||
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the important behavioral property of being walk-forward computed with no lookahead, which is critical for backtesting. It also states the weeks default and max. It does not mention authentication, rate limits, or failure modes, but the core behavioral guarantee is well covered.
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?
A single sentence packs the core purpose, the behavioral guarantee, the data cadence, and the parameter default/max. No filler, and the most important qualifier ('no lookahead') is front-loaded.
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?
Given a low-parameter tool and the presence of an output schema, the description covers the purpose, temporal scope, one-ticker constraint, lookahead behavior, and the key parameter default/max. It does not explicitly describe ticker format or failure behavior, but those are minor and likely inferable from the schema or sibling context.
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?
Schema description coverage is 0%, so the description must compensate. It explains that the series is for 'one ticker' (covering the ticker parameter) and states weeks defaults to 104 with a max of 520, giving the key constraint. The exact meaning of 'weeks' is implied by the weekly series context, which is sufficient.
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 a specific resource ('historical weekly trend-stage series'), the scope ('for one ticker'), and the key distinguishing property (walk-forward, no lookahead). This clearly differentiates it from siblings like get_stage or get_pnf even without naming them.
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 intended use case: backtest-safe historical stage data for a single ticker. It does not explicitly say 'use get_stage for current data' or list exclusions, but the 'historical' and 'backtest-safe data series' framing provides sufficient context for an agent to choose it over unlikely alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your current billing-period usage and remaining credit quota on your plan. Free — never counts against quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers on the most important trait: 'Free — never counts against quota' discloses a cost behavior an agent could not infer from the name or empty schema. For a zero-parameter informational tool, this is the key behavioral fact; only an explicit read-only/side-effect statement is absent.
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 sentences with zero waste: the first states the resource, the second adds the cost behavior. The purpose is front-loaded and every word earns its place.
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 tool with an output schema, the description is complete: it identifies what the operation returns and discloses the one non-obvious behavior (no quota consumption). An agent has everything needed to invoke it correctly.
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?
There are zero parameters (empty schema), so the baseline is 4. The description correctly focuses on what the call returns rather than on parameters, which is the only semantically meaningful content for a parameterless invocation.
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 specifies the resource precisely — 'current billing-period usage and remaining credit quota on your plan' — and the subject matter is clearly distinct from all siblings (macro, stage, pnf, filings, calendar), none of which touch billing. However, it is phrased as a noun phrase rather than an explicit verb phrase, so the verb is only implied by the tool name 'get_usage'.
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 'Free — never counts against quota' note provides useful context that this call has no cost, implying it can be invoked without reservation. But the description never explicitly frames when to use this tool versus alternatives, and no alternative for checking plan status is named. Usage is implied by the subject matter rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Composite verdict for one ticker: fuses trend stage, Point & Figure, insider-transaction clusters, and macro regime into a 0-100 score, an accumulate/hold/distribute/avoid enum, and a plain-English rationale. One call replaces separately calling stage, pnf, filings, and macro.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden of behavioral disclosure. It conveys that the tool is read-only in nature (it only fuses and evaluates) and is transparent about what it produces (a score, an enum, and a rationale) and that it makes a single tangentially aggregating call. It does not disclose any rate limits or data freshness caveats, but for a get-style tool the description is sufficiently open about the inner aggregation behavior.
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 exactly two sentences. The first sentence packs the purpose, the fused signals, and the output format, and the second sentence gives the usage trade-off. Every phrase earns its place; there is no repetition or 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?
Despite the conceptual complexity (composite of five signals), the description is complete for an agent to decide and call. It covers the input (one ticker), the output (score, enum, rationale), and the key trade-off with siblings, all in two sentences. An output schema exists, so the detailed return structure need not be repeated in the description. Nothing an agent needs to know before calling 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?
Schema description coverage is 0%, so the description must compensate for the single parameter. It adds 'one ticker' to the schema's bare `ticker` string, which clarifies the tool is per-ticker (not batch – other tools might accept multiple). However, it does not add formatting, validation, or example values. Given the extreme simplicity of the parameter, this is an adequate but not enriched compensation.
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 states a specific verb ('fuses') and resource ('composite verdict') for a single ticker, enumerates the exact inputs (trend stage, Point & Figure, insider-transaction clusters, macro regime), the output (score, accumulate/hold/distribute/avoid enum, rationale), and explicitly names the four alternatives when saying 'one call replaces separately calling stage, pnf, filings, and macro.' This leaves no doubt about what the tool does and how it differs from its siblings.
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?
It clearly tells the agent to use this tool when it needs a composite verdict and lists the sibling calls it replaces ('stage, pnf, filings, and macro'), providing a clear rationale for choosing get_verdict over them. It does not explicitly state when not to use it (e.g., when only a single underlying signal is needed), but the context is clear and the recommendation is direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.4get_short_pressurev0.1.2get_calendarget_filingsget_macroget_pnfget_sector_breadthget_stageget_stage_historyget_usageget_verdictScored across 10 tools
Most tools are distinct, but get_verdict clearly overlaps with get_stage, get_pnf, get_filings, and get_macro, as its description explicitly says it replaces calling them separately. An agent may still choose individual tools for customization, but the boundary is blurred.
All 10 tools follow a consistent get_<noun> pattern (get_macro, get_stage, get_short_pressure, etc.), making the naming predictable and easy to scan.
10 tools is well within the ideal 3-15 range for a financial intelligence server. The count feels slightly heavy due to the composite verdict tool, but no tool seems entirely redundant.
Covers macro, technicals, short data, filings, breadth, calendar, and account usage with good CRUD-like coverage for the domain. Minor gaps exist, such as no tool for historical filing retrieval or custom date ranges on most endpoints, but core workflows are supported.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Real-time market events, sentiment, and technical analysis as MCP tools, backed by real data.
100+ MCP tools for AI agents: content metadata, trade intelligence, business-expertise analysis.
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
