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., "@Unusual Whales MCP Server show me recent options flow for AAPL"
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.
A Model Context Protocol (MCP) server that provides access to the Unusual Whales API for financial data, options flow analysis, and market intelligence.
š Fast and lightweight - Direct API access without heavy dependencies
š Comprehensive data - 33 tools covering 12 financial data categories
š Real-time insights - Options flow alerts, market sentiment, and live data
šļø Congressional tracking - Monitor politician trading activity
š Dark pool analysis - Track institutional block trades
š Market intelligence - ETF flows, earnings data, and volatility metrics
Related MCP server: unusual-whales-mcp
Node.js 18+
Valid Unusual Whales API key
Compatible with Claude Desktop, VS Code, and other MCP clients
The server is available as an npm package and can be installed in multiple ways:
npx unusualwhales-mcpnpm install -g unusualwhales-mcpnpm install unusualwhales-mcpObtain an API key from Unusual Whales
Set the environment variable:
export UNUSUAL_WHALES_API_KEY=your_api_key_hereOr create a .env file:
UNUSUAL_WHALES_API_KEY=your_api_key_hereAdd to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"unusualwhales": {
"command": "npx",
"args": ["unusualwhales-mcp"],
"env": {
"UNUSUAL_WHALES_API_KEY": "your_api_key_here"
}
}
}
}{
"mcpServers": {
"unusualwhales": {
"command": "npx",
"args": ["unusualwhales-mcp"]
}
}
}The server works with any MCP-compatible client. Use the command:
npx unusualwhales-mcpget_stock_info - Get comprehensive stock information
get_stock_flow_alerts - Get options flow alerts for a ticker
get_stock_flow_recent - Get recent options flows
get_stock_option_chains - Get option chains data
get_stock_greek_exposure - Get Greeks exposure analysis
get_stock_max_pain - Get max pain calculations
get_stock_iv_rank - Get IV rank percentiles
get_stock_volatility_stats - Get volatility statistics
get_market_tide - Get overall market sentiment indicator
get_market_economic_calendar - Get economic events calendar
get_market_fda_calendar - Get FDA calendar events
get_market_spike - Get SPIKE volatility indicator
get_market_total_options_volume - Get market-wide options volume
get_congress_trader - Get congress member trading data
get_congress_late_reports - Get late filing reports
get_congress_recent_trades - Get recent congressional trades
get_darkpool_recent - Get recent dark pool prints
get_darkpool_ticker - Get dark pool data for specific ticker
get_etf_exposure - Get ETF sector/geographic exposure
get_etf_holdings - Get ETF holdings breakdown
get_etf_in_outflow - Get ETF flow data
get_etf_info - Get ETF information
get_etf_weights - Get ETF sector weights
get_earnings_afterhours - Get after-hours earnings
get_earnings_premarket - Get pre-market earnings
get_earnings_ticker - Get historical earnings for ticker
get_alerts - Get triggered user alerts
get_alerts_configuration - Get alert configurations
get_option_trades_flow_alerts - Get options flow alerts
get_screener_analysts - Get analyst ratings screener
get_screener_option_contracts - Get hottest chains screener
get_screener_stocks - Get stock screener results
get_news_headlines - Get financial news headlines
// Get recent options flows for AAPL
const flows = await server.callTool("get_stock_flow_recent", {
ticker: "AAPL"
});
// Get comprehensive stock info
const info = await server.callTool("get_stock_info", {
ticker: "TSLA"
});// Get overall market sentiment
const tide = await server.callTool("get_market_tide", {});
// Get volatility spike indicator
const spike = await server.callTool("get_market_spike", {});// Get recent congressional trades for NVDA
const congressTrades = await server.callTool("get_congress_recent_trades", {
ticker: "NVDA"
});
// Get trades by specific congress member
const memberTrades = await server.callTool("get_congress_trader", {
name: "Nancy Pelosi"
});// Get recent dark pool activity
const darkPool = await server.callTool("get_darkpool_recent", {
limit: 50
});
// Get dark pool data for specific ticker
const tickerDarkPool = await server.callTool("get_darkpool_ticker", {
ticker: "SPY"
});This package can be imported and used directly in your Node.js applications, including web frameworks like Hono, Express, or Fastify.
npm install unusualwhales-mcpimport { UnusualWhalesMcp } from 'unusualwhales-mcp';
// Create MCP server instance
const mcpServer = new UnusualWhalesMcp();
// Get the server instance for integration
const server = mcpServer.getServer();
// Start with different transport types
await mcpServer.start('stdio'); // For MCP clients
await mcpServer.start('sse', { endpoint: '/sse', response: res }); // For HTTP SSE
await mcpServer.start('streamableHttp'); // For HTTP streamingimport { Hono } from 'hono';
import { cors } from 'hono/cors';
import { UnusualWhalesMcp } from 'unusualwhales-mcp';
const app = new Hono();
const mcpServer = new UnusualWhalesMcp();
// Enable CORS for MCP endpoints
app.use('/mcp/*', cors({
origin: '*',
allowHeaders: ['Content-Type'],
allowMethods: ['GET', 'POST', 'OPTIONS'],
}));
// SSE endpoint for MCP over HTTP
app.get('/mcp/sse', async (c) => {
const response = c.env?.response || c.res;
// Start MCP server with SSE transport
await mcpServer.start('sse', {
endpoint: '/mcp/sse',
response: response
});
return c.json({ status: 'SSE endpoint ready' });
});
// Streamable HTTP endpoint
app.post('/mcp/message', async (c) => {
try {
// Create streamable HTTP transport
const transport = mcpServer.createStreamableHTTPTransport({
sessionIdGenerator: () => crypto.randomUUID()
});
// Handle MCP message
const body = await c.req.json();
return c.json({
status: 'message processed',
sessionId: transport.sessionId
});
} catch (error) {
console.error('MCP endpoint error:', error);
return c.json({ error: 'Internal server error' }, 500);
}
});
// Direct API endpoints (bypassing MCP)
app.get('/api/stock/:ticker', async (c) => {
try {
const ticker = c.req.param('ticker');
const server = mcpServer.getServer();
// Call tool directly
const result = await server.callTool('get_stock_info', { ticker });
return c.json(result);
} catch (error) {
return c.json({ error: error.message }, 500);
}
});
export default {
port: 3000,
fetch: app.fetch,
};# Set your Unusual Whales API key
export UNUSUAL_WHALES_API_KEY=your_api_key_here
# Optional: Configure server settings
export MCP_SERVER_NAME=unusualwhales-mcp
export MCP_SERVER_VERSION=0.1.3import { UnusualWhalesMcp } from 'unusualwhales-mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
const mcpServer = new UnusualWhalesMcp();
// Create custom SSE transport
const customTransport = new SSEServerTransport('/custom-endpoint', response);
// Connect server with custom transport
await mcpServer.getServer().connect(customTransport);
// Or use the helper methods
const sseTransport = mcpServer.createSSETransport('/my-endpoint', response);
const httpTransport = mcpServer.createStreamableHTTPTransport({
sessionIdGenerator: () => `session-${Date.now()}`
});The package includes full TypeScript definitions:
import { UnusualWhalesMcp } from 'unusualwhales-mcp';
import type { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const mcpServer: UnusualWhalesMcp = new UnusualWhalesMcp();
const server: McpServer = mcpServer.getServer();
// Full type safety for all API calls
const stockInfo = await server.callTool('get_stock_info', {
ticker: 'AAPL'
});The server provides access to 81 API endpoints across 12 categories:
Category | Endpoints | Description |
Alerts | 2 | Custom alerts and configurations |
Congress | 3 | Congressional trading data |
Darkpool | 2 | Dark pool trading analysis |
Earnings | 3 | Earnings calendars and data |
ETFs | 5 | ETF analysis and holdings |
Group Flow | 2 | Grouped options flow data |
Insider | 4 | Insider trading information |
Institutions | 6 | Institutional holdings and activity |
Market | 9 | Market-wide data and indicators |
Net Flow | 1 | Net options flow by expiry |
News | 1 | Financial news headlines |
Option Contract | 4 | Individual contract analysis |
Option Trades | 2 | Options flow and alerts |
Screeners | 3 | Stock and options screening tools |
Seasonality | 4 | Seasonal market patterns |
Shorts | 5 | Short interest and volume data |
Stock | 27 | Comprehensive stock analysis |
# Clone the repository
git clone https://github.com/your-username/unusualwhales-mcp.git
cd unusualwhales-mcp
# Install dependencies
npm install
# Set up environment
cp .env.example .env
# Edit .env with your API key
# Build the project
npm run build
# Run the server
npm startnpm run build - Compile TypeScript and make executable
npm run watch - Watch for changes and recompile
npm run inspector - Launch MCP inspector for debugging
npm run prepare - Prepare package for publishing
unusualwhales-mcp/
āāā src/
ā āāā index.ts # Main server implementation
āāā build/ # Compiled JavaScript output
āāā package.json # Project configuration
āāā tsconfig.json # TypeScript configuration
template
āāā README.md # This filePlease be aware of Unusual Whales API rate limits. The server includes:
30-second timeout for requests
Proper error handling for rate limit responses
Retry logic for transient failures
This project is licensed under the MIT License - see the LICENSE file for details.
ā ļø Important: This software is for educational and research purposes only. Always verify data independently before making trading decisions. The authors are not responsible for any financial losses incurred from using this software.
Issues: GitHub Issues
API Documentation: Unusual Whales API Docs
Model Context Protocol - Official MCP implementation
Claude Desktop - AI assistant with MCP support
Unusual Whales - Financial data platform
Made with ā¤ļø for unusualwhales
Get triggered alerts for the user
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| page | No | Page number | |
| intraday_only | No | Only intraday alerts | |
| config_ids | No | Alert configuration IDs | |
| ticker_symbols | No | Ticker symbols | |
| noti_types | No | Notification types |
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 states the tool 'gets' alerts, implying a read-only operation, but doesn't mention any behavioral traits such as authentication requirements, rate limits, pagination behavior (implied by 'limit' and 'page' parameters but not explained), or what 'triggered alerts' entails in terms of format or scope. This is inadequate for a tool with 6 parameters and no output schema.
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 with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word earns its place, adhering to best practices for conciseness.
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 the tool's complexity (6 parameters, no annotations, no output schema, and many sibling tools), the description is incomplete. It lacks behavioral context, usage guidelines, and any explanation of return values or error handling. While the schema covers parameters well, the description doesn't add enough value to guide an agent effectively in selection and 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 has 100% description coverage, with clear parameter descriptions (e.g., 'limit' as 'Number of results to return'). The description adds no additional meaning beyond the schema, such as explaining how 'intraday_only' relates to 'triggered alerts' or what 'config_ids' represent. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with extra context.
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 'Get triggered alerts for the user' clearly states the verb ('Get') and resource ('triggered alerts'), specifying it retrieves alerts that have been triggered. However, it doesn't explicitly differentiate from sibling tools like 'get_stock_flow_alerts' or 'get_option_trades_flow_alerts', which might retrieve different types of alerts, so it lacks sibling differentiation.
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. With many sibling tools that also retrieve alerts or related data (e.g., 'get_stock_flow_alerts'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get alert configurations for the user
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states it 'gets' data, implying a read-only operation, but doesn't cover aspects like authentication needs, rate limits, response format, or whether it returns all configurations or a subset. This is a significant gap for a tool with zero annotation coverage.
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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'alert configurations' entail (e.g., settings, triggers, types) or the return format, leaving the agent uncertain about the tool's behavior and output. For a tool with no structured data support, more context is needed.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, but it could have mentioned if any implicit parameters (e.g., user context) are involved. Baseline is 4 due to the absence of 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 'Get alert configurations for the user' clearly states the verb ('Get') and resource ('alert configurations'), specifying it's for 'the user' rather than a general system. However, it doesn't distinguish this from sibling tools like 'get_alerts' or 'get_stock_flow_alerts', which might retrieve different types of alert data, leaving some ambiguity about scope.
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 doesn't mention context, prerequisites, or exclusions, and with many sibling tools like 'get_alerts' that might overlap, the agent is left without direction on selecting the appropriate tool for retrieving alert-related data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent late reports by congress members
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| date | No | Date filter (YYYY-MM-DD) | |
| ticker | No | Ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data but doesn't mention whether it's read-only, has rate limits, requires authentication, or what the output format looks like. This is a significant gap for a tool with no annotation coverage.
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 with no wasted words. It's front-loaded with the core purpose, making it easy 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?
Given no annotations, no output schema, and a tool that likely returns complex data (congressional reports), the description is inadequate. It doesn't explain what 'late reports' are, the data structure returned, or any behavioral constraints, leaving the agent with insufficient context for effective use.
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 description coverage is 100%, so the schema already documents all three parameters (limit, date, ticker). The description doesn't add any parameter-specific details beyond what's in the schema, such as how 'recent' relates to the date parameter or what 'late reports' entail. Baseline 3 is appropriate when the schema handles parameter documentation.
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 action ('Get') and resource ('recent late reports by congress members'), providing a specific purpose. However, it doesn't differentiate from sibling tools like 'get_congress_recent_trades' or 'get_congress_trader', which also involve congressional data but for different purposes.
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 doesn't mention sibling tools or contexts where this tool is preferred, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest trades by congress members
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| date | No | Date filter (YYYY-MM-DD) | |
| ticker | No | Ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like rate limits, authentication needs, pagination, or response format. It mentions 'latest' which implies recency, but doesn't specify time frames or ordering, leaving gaps in transparency.
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 with zero waste. It is front-loaded and appropriately sized for the tool's complexity, making it easy to parse without unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete. It lacks details on return values, error handling, or behavioral constraints. For a tool with 3 parameters and no structured safety hints, more context is needed to guide the agent effectively.
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 100%, so the schema already documents all parameters (limit, date, ticker). The description adds no additional meaning beyond what's in the schema, such as explaining how parameters interact or default behaviors. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb 'Get' and resource 'latest trades by congress members', making the purpose specific and understandable. It distinguishes from siblings like 'get_congress_late_reports' or 'get_congress_trader' by focusing on trades, though it could be more explicit about differentiation.
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, such as 'get_congress_late_reports' or 'get_congress_trader'. It lacks context about prerequisites, exclusions, or specific use cases, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent reports by congress member
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| date | No | Date filter (YYYY-MM-DD) | |
| ticker | No | Ticker symbol | |
| name | No | Congress member name |
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 mentions 'recent reports' but doesn't specify what 'recent' means, whether there are rate limits, authentication requirements, or what the output format looks like. This is inadequate for a tool with potential data retrieval implications.
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 that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy 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?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'recent reports' entail, how results are returned, or any behavioral traits like pagination or error handling. For a data retrieval tool with multiple parameters, this leaves significant gaps in understanding.
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 has 100% description coverage, with clear parameter documentation (limit, date, ticker, name). The description adds no additional semantic context beyond the schema, such as how parameters interact or examples of usage. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Get recent reports') and resource ('by congress member'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_congress_late_reports' or 'get_congress_recent_trades', which appear to serve similar domains, so it doesn't fully differentiate from alternatives.
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. With siblings like 'get_congress_late_reports' and 'get_congress_recent_trades' available, there's no indication of what makes this tool unique or when it should be preferred, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest darkpool trades
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results to return | |
| date | No | Date filter (YYYY-MM-DD) | |
| min_premium | No | Minimum premium | |
| max_premium | No | Maximum premium | |
| min_size | No | Minimum size | |
| max_size | No | Maximum size | |
| min_volume | No | Minimum volume | |
| max_volume | No | Maximum volume |
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 only states the basic action without detailing permissions, rate limits, data freshness, or return format. For a tool with 8 parameters and no output schema, this is inadequate, as it doesn't explain what 'latest' means or how results are structured.
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 extremely concise with a single, front-loaded sentence: 'Get latest darkpool trades.' It wastes no words and directly states the tool's purpose, making it easy 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?
Given the complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output structure. For a data retrieval tool with multiple filters, more guidance on how parameters interact or what 'latest' entails is needed to be fully helpful.
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 100%, so the schema fully documents all 8 parameters. The description adds no additional parameter semantics beyond implying 'latest' trades, which might relate to date filtering but isn't explicitly linked to the 'date' parameter. This meets the baseline for high schema coverage.
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: 'Get latest darkpool trades.' It specifies the action ('Get') and resource ('darkpool trades') with the qualifier 'latest' indicating recency. However, it doesn't explicitly differentiate from sibling tools like 'get_darkpool_ticker' or 'get_stock_flow_recent,' which might also involve trade 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 doesn't mention sibling tools, prerequisites, or specific contexts for usage. The lack of comparison to tools like 'get_darkpool_ticker' or 'get_stock_flow_recent' leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get darkpool trades for a specific ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol | |
| date | No | Date filter (YYYY-MM-DD) | |
| newer_than | No | Newer than timestamp | |
| older_than | No | Older than timestamp | |
| min_premium | No | Minimum premium | |
| max_premium | No | Maximum premium | |
| min_size | No | Minimum size | |
| max_size | No | Maximum size | |
| min_volume | No | Minimum volume | |
| max_volume | No | Maximum volume | |
| limit | No | Number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, authentication requirements, pagination (though 'limit' parameter hints at it), error handling, or data freshness. This is inadequate for a tool with 11 parameters.
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 with zero wasted words. It's front-loaded with the core purpose, making it easy 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?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral context (e.g., what the tool returns, any side effects), doesn't explain relationships with sibling tools, and provides no usage guidance. This leaves significant gaps for an agent to understand how to use it effectively.
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 100%, so the schema already documents all parameters thoroughly. The description adds no additional parameter semantics beyond implying ticker filtering, which is covered by the required 'ticker' parameter. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('Get') and resource ('darkpool trades for a specific ticker'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_darkpool_recent', which appears to be a related darkpool tool without ticker specificity.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention how it differs from 'get_darkpool_recent' (which might return recent darkpool trades without ticker filtering) or other data retrieval tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get afterhours earnings for a date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date filter (YYYY-MM-DD) | |
| limit | No | Number of results to return | |
| page | No | Page number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns paginated results, or handles errors. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 with zero wasteāit directly states the tool's function without unnecessary words. It's appropriately sized for a simple data retrieval tool and front-loaded with the core action, making it easy 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?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are needed for effective agent operation. Without annotations or output schema, more guidance would improve 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 input schema has 100% description coverage, clearly documenting all three parameters (date, limit, page) with their types and purposes. The description adds no additional semantic details beyond implying date filtering, so it meets the baseline score of 3 where the schema does the heavy lifting without extra value from the description.
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 verb ('Get') and resource ('afterhours earnings') with a specific scope ('for a date'), making the purpose understandable. However, it doesn't explicitly differentiate from its sibling 'get_earnings_premarket', which handles premarket earnings data, leaving some ambiguity about when to choose one over the other.
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 like 'get_earnings_premarket' or other earnings-related tools. It lacks context about prerequisites, such as needing a valid date, and doesn't mention any exclusions or specific use cases, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get premarket earnings for a date
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date filter (YYYY-MM-DD) | |
| limit | No | Number of results to return | |
| page | No | Page number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but fails to detail critical behaviors such as pagination handling (via 'limit' and 'page' parameters), rate limits, authentication needs, error conditions, or the format of returned earnings data. This leaves significant gaps in understanding how the tool behaves in practice.
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, direct sentence that efficiently conveys the core function without any redundant or extraneous information. It is front-loaded with the main action and resource, making it easy to parse quickly. Every word earns its place, adhering perfectly to conciseness standards.
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 the complexity of a data retrieval tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., pagination, errors), output format, and usage guidelines, leaving the agent under-informed. While the schema covers parameters well, the overall context for effective tool invocation is insufficient.
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 has 100% description coverage, with clear documentation for 'date', 'limit', and 'page' parameters. The description adds no additional semantic context beyond implying date filtering, which is already covered in the schema. According to the rules, with high schema coverage, the baseline score is 3, as the description doesn't need to compensate but also doesn't enhance parameter understanding.
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 action ('Get') and resource ('premarket earnings'), making the purpose understandable. It specifies the scope with 'for a date', which distinguishes it from other earnings tools like 'get_earnings_afterhours' or 'get_earnings_ticker' that focus on different timeframes or ticker-specific data. However, it doesn't explicitly differentiate from all siblings beyond the date focus, keeping it from a perfect score.
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 minimal guidance by implying usage is for retrieving premarket earnings on a specific date, but it lacks explicit instructions on when to use this tool versus alternatives like 'get_earnings_afterhours' or other data-fetching tools. There are no mentions of prerequisites, exclusions, or comparative contexts, leaving the agent with insufficient direction for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical earnings data for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Get historical earnings data' implies a read-only operation, it doesn't specify data format, time range, completeness, or any limitations (e.g., rate limits, authentication needs). For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing essential information.
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 no annotations, no output schema, and multiple sibling tools with overlapping domains, the description is insufficiently complete. It doesn't explain what 'historical' means (time range, granularity), what data is returned, or how it differs from other earnings tools, leaving the agent with significant uncertainty.
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 100%, with the single parameter 'ticker' clearly documented as 'Ticker symbol'. The description doesn't add any parameter details beyond what the schema provides, but with complete schema coverage, the baseline score of 3 is appropriate.
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 action ('Get historical earnings data') and resource ('for a ticker'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_earnings_afterhours' or 'get_earnings_premarket', which suggests similar earnings-related functionality but with different temporal scopes.
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. With multiple earnings-related sibling tools (e.g., 'get_earnings_afterhours', 'get_earnings_premarket'), there's no indication of what makes this tool distinct or when it's preferable to use one over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETF exposure data
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ETF ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. 'Get ETF exposure data' implies a read-only operation but doesn't specify details like data format, potential rate limits, authentication requirements, or error handling. It fails to add meaningful context beyond the basic action, leaving significant gaps in understanding how the tool behaves in practice.
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 extremely concise with just three words, making it front-loaded and free of unnecessary details. Every word contributes directly to stating the tool's purpose, with no wasted space. This efficiency aligns well with best practices for tool descriptions, though it may sacrifice completeness for brevity.
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 the complexity implied by financial data tools and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'exposure data' includes, how results are structured, or any behavioral nuances. For a tool with no structured support beyond the input schema, more context is needed to ensure the agent can use it effectively.
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 has 100% description coverage, with the 'ticker' parameter clearly documented as 'ETF ticker symbol'. The description adds no additional meaning about parameters, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra input from the description.
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 'Get ETF exposure data' clearly states the action (get) and resource (ETF exposure data), making the purpose understandable. However, it lacks specificity about what 'exposure data' entails compared to sibling tools like 'get_etf_holdings' or 'get_etf_weights', leaving room for ambiguity. It's not tautological but remains vague in distinguishing its exact scope.
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. With sibling tools such as 'get_etf_holdings' and 'get_etf_weights', it's unclear if this tool overlaps or serves a distinct purpose, and there are no explicit instructions on prerequisites or exclusions. This absence of contextual direction limits effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETF holdings information
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ETF ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action ('Get') without disclosing behavioral traits like whether it's a read-only operation, requires authentication, has rate limits, returns structured data, or handles errors. This leaves critical operational context unspecified.
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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of holdings, percentages), potential errors, or usage context, making it inadequate for an agent to confidently invoke the tool without trial and error.
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 100% with one parameter ('ticker') fully documented in the schema. The description adds no additional meaning beyond the schema, such as format examples (e.g., 'SPY') or constraints. Baseline 3 is appropriate since the schema adequately covers the parameter.
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 'Get ETF holdings information' clearly states the action (get) and resource (ETF holdings), but it's vague about what specific holdings information is provided. It distinguishes from some siblings like 'get_etf_info' or 'get_etf_weights' by focusing on holdings, but doesn't explicitly differentiate scope or detail level.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_etf_info' and 'get_etf_weights', the description doesn't indicate if this is for detailed holdings, summary data, or specific use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETF information
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ETF ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to add any context. It does not mention whether this is a read-only operation, its data source, rate limits, error handling, or output format, leaving the agent with insufficient information to invoke it correctly.
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 extremely concise with a single three-word phrase, 'Get ETF information,' which is front-loaded and wastes no words. However, this conciseness comes at the cost of clarity and completeness.
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 the lack of annotations and output schema, the description is incomplete. It does not compensate for these gaps by explaining what ETF information is returned, potential errors, or behavioral traits, making it inadequate for a tool with one parameter but no structured output information.
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 has 100% description coverage, clearly documenting the 'ticker' parameter. The description adds no additional meaning beyond the schema, such as examples or constraints, but the high schema coverage justifies a baseline score of 3.
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 'Get ETF information' is a tautology that merely restates the tool name 'get_etf_info' without specifying what information is retrieved or how it differs from sibling tools like get_etf_exposure or get_etf_holdings. It lacks a specific verb-resource combination that would clarify its unique function.
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?
No guidance is provided on when to use this tool versus alternatives such as get_stock_info or other ETF-related siblings like get_etf_holdings. The description offers no context, exclusions, or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETF inflow & outflow data
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ETF ticker symbol |
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 states the tool retrieves data, implying a read-only operation, but doesn't specify aspects like rate limits, authentication needs, data format, or potential errors. For a tool with no annotation coverage, this is a significant gap in transparency.
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 with zero wasteā'Get ETF inflow & outflow data'. It is front-loaded and appropriately sized for the tool's simple purpose, making it easy 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?
Given no annotations, no output schema, and a simple parameter set, the description is minimal. It states what the tool does but lacks context on behavior, output format, or usage relative to siblings. For a tool in a crowded namespace with many ETF-related siblings, this leaves the agent under-informed.
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 has 100% description coverage, with the parameter 'ticker' documented as 'ETF ticker symbol'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 verb 'Get' and the resource 'ETF inflow & outflow data', making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'get_etf_exposure' or 'get_etf_holdings', which also retrieve ETF-related data but for different metrics.
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. With many sibling tools for ETF data (e.g., 'get_etf_exposure', 'get_etf_holdings'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ETF sector & country weights
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ETF ticker symbol |
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 states what the tool does but omits critical details such as whether it's a read-only operation, potential rate limits, authentication requirements, or the format of returned data. For a tool with no annotations, this is a significant gap in transparency.
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 with no wasted words, clearly front-loading the core functionality. It is appropriately sized for a simple tool with one parameter, 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?
For a tool with no annotations, no output schema, and a simple input schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context. Given the low complexity, it's not entirely incomplete but leaves gaps that could hinder effective tool selection and 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 has 100% description coverage, with the 'ticker' parameter fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 action ('Get') and the resource ('ETF sector & country weights'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_etf_exposure' or 'get_etf_holdings', which also retrieve ETF-related data but for different attributes, leaving some ambiguity about when to choose this specific tool.
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?
No guidance is provided on when to use this tool versus alternatives. With multiple sibling tools for ETF data (e.g., 'get_etf_exposure', 'get_etf_holdings'), the description lacks any indication of context, prerequisites, or comparisons, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get economic calendar events
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date filter (YYYY-MM-DD) | |
| limit | No | Number of results to return |
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. 'Get' implies a read operation, but the description doesn't specify any behavioral traits like rate limits, authentication needs, data freshness, or what happens if parameters are omitted. It lacks details on return format, pagination, or error handling, which are critical for a tool with parameters.
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 ('Get economic calendar events') that is front-loaded and wastes no words. It's appropriately sized for a simple tool, though it could be slightly more informative without losing conciseness.
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 the tool has 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'economic calendar events' entail, how results are structured, or any behavioral context. For a tool with parameters and no structured output, more detail is needed to guide the agent effectively.
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 has 100% description coverage, with clear documentation for both parameters ('date' and 'limit'). The description doesn't add any meaning beyond this, such as explaining default values, parameter interactions, or example usage. Since schema coverage is high, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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 'Get economic calendar events' clearly states the verb ('Get') and resource ('economic calendar events'), making the basic purpose understandable. However, it lacks specificity about what type of economic events or data is retrieved, and it doesn't differentiate from sibling tools like 'get_market_fda_calendar' which suggests a similar calendar function for 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 doesn't mention any context, prerequisites, or exclusions, such as how it differs from other calendar-related tools in the sibling list (e.g., 'get_market_fda_calendar'). This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FDA calendar events
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Date filter (YYYY-MM-DD) | |
| limit | No | Number of results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, pagination behavior, error conditions, or what format the events are returned in. The description is minimal and lacks essential operational context for a tool with no annotations.
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 extremely concise at just three words, front-loaded with the core purpose. There's zero wasted language or unnecessary elaboration. It efficiently communicates the basic function without any structural issues.
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 no annotations, no output schema, and a read operation with 2 parameters, the description is incomplete. It doesn't explain what 'FDA calendar events' includes, what format they're returned in, or any behavioral constraints. For a tool in a financial/market context with many sibling tools, more context about the specific domain and use cases would be helpful.
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 100%, with both parameters ('date' and 'limit') well-documented in the schema. The description adds no additional parameter information beyond what the schema provides. With high schema coverage, the baseline score of 3 is appropriate since the schema does the heavy lifting.
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 'Get FDA calendar events' clearly states the verb ('Get') and resource ('FDA calendar events'), but it's vague about scope and doesn't differentiate from sibling tools like 'get_market_economic_calendar'. It specifies FDA events but doesn't clarify what types of events or what 'FDA calendar' refers to in this context.
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?
No guidance is provided about when to use this tool versus alternatives. With sibling tools like 'get_market_economic_calendar' that might overlap in domain, there's no indication of when FDA calendar events are needed versus general economic calendar events. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SPIKE data (volatility indicator)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Get' which implies a read operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, data freshness, or what 'SPIKE data' entails (e.g., format, scope). This leaves significant gaps in understanding how the tool behaves.
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 extremely concise with a single phrase 'Get SPIKE data (volatility indicator)', which is front-loaded and wastes no words. Every part earns its place by specifying the action and clarifying the resource type.
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 no annotations, no output schema, and a simple tool with 0 parameters, the description is incomplete. It doesn't explain what 'SPIKE data' returns (e.g., values, timeframes, or indicators), making it hard for an agent to use effectively without additional 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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description adds no parameter information, but since there are no parameters to document, this is acceptable and doesn't detract from usability.
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 'Get SPIKE data (volatility indicator)' states the verb 'Get' and resource 'SPIKE data', with clarification that it's a volatility indicator. However, it doesn't differentiate from siblings like 'get_stock_volatility_stats' or 'get_market_tide', which might also provide volatility-related data, making the purpose somewhat vague in context.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_stock_volatility_stats' and 'get_market_tide', the description lacks any context about specific use cases, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market tide data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Get market tide data' implies a read-only operation, but it doesn't specify any behavioral traits such as data format, freshness, rate limits, authentication needs, or potential side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 'Get market tide data' is extremely conciseāa single phrase with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. This is an example of efficient communication, though it may be overly brief for clarity.
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 the lack of annotations and output schema, the description is incomplete for effective tool use. 'Market tide data' is ambiguous without context on what data is returned, its structure, or how it differs from other market tools. For a tool in a complex domain with many siblings, more detail is needed to understand its role and output.
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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. A baseline score of 4 is appropriate as the description aligns with the absence of parameters, though it doesn't add semantic value beyond what the schema already indicates (no 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?
The description 'Get market tide data' clearly states the action (get) and resource (market tide data), which provides a basic understanding of purpose. However, it lacks specificity about what 'market tide data' entails and doesn't distinguish this tool from its many siblings that also retrieve market-related information (e.g., get_market_economic_calendar, get_market_spike). The purpose is vague but not tautological.
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. With numerous sibling tools for market data (e.g., get_market_economic_calendar, get_market_spike), there's no indication of what makes 'market tide data' unique or when it's appropriate. No exclusions, prerequisites, or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total options volume across the market
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'get' implies a read operation but doesn't disclose behavioral traits like rate limits, data freshness, authentication needs, or what 'total options volume' entails (e.g., aggregated across all tickers, timeframes). This leaves significant gaps for a tool with market-wide data.
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 that directly states the tool's function with no wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy 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?
Given the complexity of market data tools and no annotations or output schema, the description is incomplete. It doesn't explain return values, data scope, or usage context, which is inadequate for helping an agent invoke it correctly among many siblings.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is fine here, but it could hint at implicit parameters like date ranges if applicable. Baseline is 4 for 0 params, as it doesn't need to compensate for schema gaps.
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 verb 'get' and the resource 'total options volume across the market', making the purpose explicit. However, it doesn't differentiate from sibling tools like 'get_option_trades_flow_alerts' or 'get_screener_option_contracts', which might also relate to options data, so it lacks sibling distinction for a perfect score.
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. With many sibling tools related to options, market data, and flows, there's no indication of context, exclusions, or comparisons, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get latest news headlines for financial markets with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many items to return (default: 50, max: 100, min: 1) | |
| major_only | No | When set to true, only returns major/significant news (default: false) | |
| page | No | Page number (use with limit). Starts on page 0 | |
| search_term | No | A search term to filter news headlines by content | |
| sources | No | A comma-separated list of news sources to filter by (e.g., 'Reuters,Bloomberg') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'latest news headlines' but doesn't specify recency (real-time, last hour, last day), source reliability, rate limits, authentication requirements, or what format the headlines return. For a news retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 that communicates the core purpose without wasted words. It's appropriately sized for a tool with good schema documentation, though it could be slightly more informative given the lack of annotations and output schema.
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 the complexity of a news retrieval tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what format the headlines return (just headlines? with timestamps? with links?), how 'latest' is defined, source reliability, or error conditions. For a tool that presumably returns structured news data, more context is needed.
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 has 100% description coverage, with all 5 parameters well-documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'filtering options' generally, but doesn't provide additional context about parameter interactions, typical use cases, or semantic meaning beyond what's already in the parameter descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
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: 'Get latest news headlines for financial markets with filtering options'. It specifies the verb ('Get'), resource ('news headlines'), and domain ('financial markets'), which is clear and specific. However, it doesn't explicitly differentiate this tool from its many siblings (like get_market_economic_calendar or get_stock_info), which would require a 5.
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. With 30+ sibling tools on the server (including other market data tools like get_market_economic_calendar and get_stock_info), there's no indication of when this news-focused tool is appropriate versus other data sources. The description mentions 'filtering options' but doesn't explain when those filters should be applied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option flow alerts showing significant option trades and unusual activity
| Name | Required | Description | Default |
|---|---|---|---|
| all_opening | No | Boolean flag whether all transactions are opening transactions based on OI, Size & Volume (default: true) | |
| is_ask_side | No | Boolean flag whether a transaction is ask side (default: true) | |
| is_bid_side | No | Boolean flag whether a transaction is bid side (default: true) | |
| is_call | No | Boolean flag whether a transaction is a call (default: true) | |
| is_floor | No | Boolean flag whether a transaction is from the floor (default: true) | |
| is_otm | No | Only include contracts which are currently out of the money | |
| is_put | No | Boolean flag whether a transaction is a put (default: true) | |
| is_sweep | No | Boolean flag whether a transaction is a intermarket sweep (default: true) | |
| issue_types | No | An array of 1 or more issue types | |
| limit | No | How many items to return (default: 100, max: 200, min: 1) | |
| max_diff | No | The maximum OTM diff of a contract | |
| max_dte | No | The maximum days to expiry (min: 0) | |
| max_open_interest | No | The maximum open interest on that alert's contract | |
| max_premium | No | The maximum premium on that alert (min: 0) | |
| max_size | No | The maximum size on that alert (min: 0) | |
| max_volume | No | The maximum volume on that alert's contract | |
| max_volume_oi_ratio | No | The maximum ratio of contract volume to contract open interest | |
| min_diff | No | The minimum OTM diff of a contract | |
| min_dte | No | The minimum days to expiry (min: 0) | |
| min_open_interest | No | The minimum open interest on that alert's contract | |
| min_premium | No | The minimum premium on that alert (min: 0) | |
| min_size | No | The minimum size on that alert (min: 0) | |
| min_volume | No | The minimum volume on that alert's contract | |
| min_volume_oi_ratio | No | The minimum ratio of contract volume to contract open interest | |
| newer_than | No | Unix time in milliseconds/seconds or ISO date (2024-01-25) - no older results will be returned | |
| older_than | No | Unix time in milliseconds/seconds or ISO date (2024-01-25) - no newer results will be returned | |
| rule_name | No | An array of 1 or more rule names | |
| ticker_symbol | No | A comma separated list of tickers. To exclude certain tickers prefix the first ticker with a - |
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 states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify aspects like rate limits, authentication needs, data freshness, or pagination. For a tool with 28 parameters and no annotations, this is inadequate.
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 that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to parse quickly. Every part of the sentence contributes meaning.
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 the complexity (28 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the return format, data structure, or how results are filtered or sorted. For a data retrieval tool with many filtering options, more context is needed to guide effective use.
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 100%, so the schema fully documents all 28 parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining relationships between parameters or providing examples. Baseline 3 is appropriate when the schema handles all parameter documentation.
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: 'Get option flow alerts showing significant option trades and unusual activity.' It specifies the verb 'Get' and resource 'option flow alerts,' with additional context about the content. However, it doesn't explicitly differentiate from sibling tools like 'get_stock_flow_alerts,' which is a similar concept but for stocks rather than options.
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 doesn't mention sibling tools, prerequisites, or specific use cases, leaving the agent to infer usage from the name and parameters alone. This lack of contextual direction is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get analyst rating screener
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get analyst rating screener', implying a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, output format, or whether it returns a list or single item. This is a significant gap for a tool with no annotation coverage.
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 phrase with no wasted words. It's front-loaded and appropriately sized for its purpose, making it easy 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of analysts, ratings, or screening criteria), which is crucial for an agent to use it correctly. With no structured data to rely on, the description should provide more context about the tool's behavior and output.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate, earning a baseline score of 4 as it doesn't have to compensate for any schema gaps.
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 'Get analyst rating screener' specifies a verb ('Get') and resource ('analyst rating screener'), but it's vague about what exactly is being retrievedāwhether it's a list of analysts, their ratings, or a screening tool. It doesn't clearly differentiate from siblings like 'get_screener_stocks' or 'get_screener_option_contracts', which also involve screening but for different data types.
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?
No guidance is provided on when to use this tool versus alternatives. With sibling tools like 'get_screener_stocks' and 'get_screener_option_contracts', the description doesn't clarify if this is for analyst-specific data or how it relates to other screening tools, leaving usage context implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hottest chains screener (option contracts)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 implies a read-only operation ('Get'), but doesn't specify if it requires authentication, has rate limits, returns real-time or historical data, or details the output format. This leaves significant gaps in understanding how the tool behaves.
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 that directly states the tool's purpose without unnecessary words. However, it could be more front-loaded with clearer terminology (e.g., defining 'hottest chains') to improve immediate understanding.
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 the complexity implied by 'hottest chains screener' and the lack of annotations and output schema, the description is incomplete. It doesn't explain what data is returned, how it's formatted, or any behavioral traits, making it inadequate for an agent to use the tool effectively without additional 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have hinted at implicit parameters like filters or sortingāthough not required, this keeps it from a perfect score.
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 tool retrieves 'hottest chains screener (option contracts)', which clarifies it's a retrieval operation focused on option contracts. However, it's vague about what 'hottest chains screener' specifically meansāit doesn't specify if this refers to high-volume, high-activity, or trending options, nor does it distinguish from sibling tools like 'get_stock_option_chains' or 'get_option_trades_flow_alerts', leaving ambiguity in its exact function.
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?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_stock_option_chains' and 'get_option_trades_flow_alerts', the description lacks any context on use cases, prerequisites, or exclusions, offering no help in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock screener
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. 'Get stock screener' gives no information about whether this is a read-only operation, whether it requires authentication, what format the output takes, whether there are rate limits, or what happens on errors. The description is too vague to provide any meaningful behavioral context.
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 extremely concise ('Get stock screener' - three words) but this brevity comes at the cost of being under-specified. While it has zero wasted words, it fails to provide essential information that would help an agent understand the tool's purpose. Conciseness should not sacrifice clarity, making this borderline between efficient and inadequate.
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 the complexity implied by the sibling tools (which cover diverse financial data endpoints) and the absence of both annotations and an output schema, the description is completely inadequate. 'Get stock screener' doesn't explain what a 'stock screener' is in this context, what data is returned, or how this tool fits among the many data retrieval siblings. For a tool in what appears to be a financial API suite, this leaves critical gaps.
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 0 parameters with 100% schema description coverage, so there are no parameters to document. The description doesn't need to compensate for any parameter gaps. A baseline of 4 is appropriate since the schema fully covers the non-existent parameters, though the description doesn't add any parameter-specific value (which isn't needed here).
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 'Get stock screener' is a tautology that essentially restates the tool name 'get_screener_stocks'. It doesn't specify what action is performed (e.g., list, retrieve, filter) or what resource is accessed (e.g., screener results, screener definitions). Compared to siblings like 'get_screener_analysts' or 'get_screener_option_contracts', it fails to distinguish what makes this tool unique.
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. With many sibling tools focused on different data types (alerts, congress trades, dark pools, earnings, ETFs, market data, news, options, stock flows), there's no indication whether this tool returns screener configurations, screener results, or something else. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get flow alerts for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
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 states 'Get flow alerts for a ticker', implying a read-only operation, but does not specify any behavioral traits like rate limits, authentication needs, data freshness, or what 'flow alerts' entail (e.g., real-time vs. historical). This is a significant gap for a tool with no annotation coverage.
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 ('Get flow alerts for a ticker') that is front-loaded and wastes no words. It could be slightly more informative, but it is appropriately sized for its purpose without unnecessary elaboration.
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 the complexity of financial data tools and the lack of annotations and output schema, the description is incomplete. It does not explain what 'flow alerts' are, the return format, or any behavioral context, making it inadequate for an agent to fully understand the tool's operation and results.
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 has 100% description coverage, with the 'ticker' parameter clearly documented as 'Stock ticker symbol'. The description adds no additional meaning beyond this, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter semantics.
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 'Get flow alerts for a ticker' clearly states the action (get) and resource (flow alerts) with a specific scope (for a ticker), making the purpose understandable. However, it lacks differentiation from sibling tools like 'get_stock_flow_recent' or 'get_option_trades_flow_alerts', which also involve flow-related data, leaving ambiguity about what makes this tool unique.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, such as how it differs from other flow-related tools in the sibling list. This absence of usage instructions leaves the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent flows for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
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 states 'Get recent flows' but doesn't specify what 'flows' entail (e.g., trading volume, options flow, dark pool activity), the time frame for 'recent', or any operational traits like rate limits, authentication needs, or response format. This leaves significant gaps for a tool with no annotation coverage.
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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness in a tool definition.
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 the complexity of financial data tools and the lack of annotations and output schema, the description is insufficient. It doesn't explain what 'flows' are, the return format, or how it differs from siblings, leaving the agent with incomplete context to use the tool effectively in a server with many similar 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 input schema has 100% description coverage, with the 'ticker' parameter clearly documented as 'Stock ticker symbol'. The description adds no additional parameter semantics beyond implying the ticker is used to retrieve flows, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb 'Get' and the resource 'recent flows for a ticker', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_stock_flow_alerts' or 'get_darkpool_recent', which might also involve flow data, leaving some ambiguity about what specific type of flows it retrieves.
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. With many sibling tools related to stock data (e.g., 'get_stock_flow_alerts', 'get_darkpool_recent'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Greek exposure for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
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 states what the tool does but doesn't explain how it behavesāe.g., whether it returns real-time or historical data, error handling for invalid tickers, rate limits, or data freshness. This leaves significant gaps for an agent to understand operational constraints.
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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
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 the complexity of financial data tools and lack of annotations or output schema, the description is incomplete. It doesn't cover what 'Greek exposure' entails (e.g., delta, gamma, theta, vega), the format or units of the response, or any behavioral aspects like data sources or update frequency. This leaves the agent with insufficient context for reliable use.
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 100%, with the parameter 'ticker' fully documented in the schema as 'Stock ticker symbol'. The description adds no additional meaning beyond this, such as format examples (e.g., 'AAPL' vs 'AAPL.US') or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 action ('Get') and target resource ('Greek exposure for a ticker'), making the purpose understandable. It distinguishes from most siblings by focusing on Greek exposure specifically, though it doesn't explicitly differentiate from tools like 'get_stock_iv_rank' or 'get_stock_volatility_stats' which might cover related financial metrics.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, such as whether the ticker must be valid or if there are specific market conditions. It doesn't mention any sibling tools as alternatives or complementary options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stock information for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get stock information' but does not disclose behavioral traits such as what type of information is returned (e.g., price, volume, fundamentals), whether it's real-time or historical, rate limits, or error handling. This leaves significant gaps for a tool with no annotation coverage.
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 with no wasted words, making it easy to parse. It is appropriately sized for a simple tool and front-loaded with the core action, earning its place without unnecessary elaboration.
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 no annotations, no output schema, and a simple input schema, the description is incomplete. It does not explain what 'stock information' entails, return format, or any behavioral context, making it inadequate for an agent to understand the tool's full scope and usage in a server with many similar 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?
Schema description coverage is 100%, with the parameter 'ticker' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints. Baseline is 3 since the schema does the heavy lifting, but no extra value is added.
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 verb 'Get' and the resource 'stock information for a ticker', making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'get_stock_flow_recent' or 'get_stock_option_chains', which also retrieve stock-related data but for different aspects, so it lacks sibling distinction.
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. With many sibling tools focused on stocks (e.g., 'get_stock_flow_recent', 'get_stock_option_chains'), it fails to specify contexts or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get IV rank for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
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 only states what the tool does without mentioning any behavioral traits such as data freshness, rate limits, error handling, or output format. This leaves significant gaps for an agent to understand how the tool behaves in practice.
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 extremely concise with a single sentence that directly states the tool's purpose. It is front-loaded and wastes no words, making it easy 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?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what IV rank is, how it's calculated, the format of the return value, or any limitations. For a tool with no structured behavioral data, this leaves the agent with insufficient context to use it effectively.
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 description coverage is 100%, with the single parameter 'ticker' clearly documented in the schema as 'Stock ticker symbol'. The description does not add any meaning beyond this, but since the schema fully covers the parameter, a baseline score of 3 is appropriate as the description does not compensate or detract.
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 action ('Get') and resource ('IV rank for a ticker'), making the purpose understandable. However, it does not differentiate this tool from its many siblings (e.g., get_stock_info, get_stock_volatility_stats) beyond the specific metric, leaving room for ambiguity in a crowded toolset.
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?
No guidance is provided on when to use this tool versus alternatives. With numerous sibling tools for stock data (e.g., get_stock_info, get_stock_volatility_stats), the description lacks context on when IV rank is specifically needed or what distinguishes it from other stock metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get max pain data for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely safe and non-destructive, but doesn't specify any traits like rate limits, authentication needs, data freshness, or what the output format might be (e.g., JSON structure, error handling). This leaves significant gaps for a tool with unknown behavioral characteristics.
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, direct sentence with no wasted words, making it highly concise and front-loaded. It immediately states the tool's purpose without unnecessary elaboration, which is efficient for an AI 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?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'max pain data' means, how it's used, or what the return values look like (e.g., numerical value, structured data). Given the complexity implied by financial terms and lack of structured support, more context is needed to ensure the agent can use it effectively.
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 has 100% description coverage for its single parameter ('ticker'), so the schema already documents it fully. The description doesn't add any parameter-specific details beyond implying the tool operates on a ticker, which is redundant. With 0 parameters needing extra explanation, a baseline of 4 is appropriate as the description doesn't detract but also doesn't enhance parameter understanding.
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 'Get max pain data for a ticker' clearly states the verb ('Get') and resource ('max pain data'), but it's vague about what 'max pain data' entails (e.g., is it a price point, options data, or something else?). It doesn't differentiate from siblings like 'get_stock_option_chains' or 'get_stock_volatility_stats', which might overlap in financial data contexts.
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?
No guidance is provided on when to use this tool versus alternatives. Given siblings like 'get_stock_option_chains' and 'get_stock_volatility_stats' that might relate to options or stock data, the description lacks context on specific use cases, prerequisites, or exclusions, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get option chains for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states what the tool does ('Get option chains') without mentioning any behavioral traits such as data freshness, rate limits, authentication needs, or what format the option chains are returned in. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without 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?
Given the complexity of financial data tools and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'option chains' include (e.g., strike prices, expiration dates), how results are structured, or any limitations. For a tool in a server with many specialized siblings, more context is needed to ensure proper usage.
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 has 100% description coverage, with the 'ticker' parameter clearly documented as 'Stock ticker symbol'. The description adds no additional meaning beyond this, as it only repeats 'for a ticker' without elaborating on format, examples, or constraints. Given the high schema coverage, the baseline score of 3 is appropriate.
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 verb 'Get' and resource 'option chains for a ticker', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_screener_option_contracts' or 'get_stock_greek_exposure', which also relate to options data, so it doesn't reach the highest differentiation level.
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. With sibling tools like 'get_screener_option_contracts' and 'get_stock_greek_exposure' that might overlap in options-related functionality, there's no indication of context, prerequisites, or exclusions to help an agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get volatility statistics for a ticker
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
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 states 'Get volatility statistics' which implies a read-only operation, but does not specify data sources, rate limits, error handling, or output format. For a tool with no annotations, this is a significant gap in transparency about how it behaves.
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 with no wasted words, making it easy to parse. It is front-loaded with the core purpose, though it could benefit from more detail, its brevity is not a flaw in this dimension.
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 the complexity of financial data tools, no annotations, and no output schema, the description is incomplete. It lacks details on what volatility statistics are returned (e.g., metrics like standard deviation, historical volatility), data recency, or any behavioral context, making it inadequate for informed tool selection.
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 has 100% description coverage, with the parameter 'ticker' documented as 'Stock ticker symbol'. The description adds no additional meaning beyond this, as it only mentions 'for a ticker' without elaborating on format or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 'Get volatility statistics for a ticker' clearly states the action (get) and resource (volatility statistics for a ticker), making the purpose understandable. However, it does not differentiate from sibling tools like 'get_stock_iv_rank' or 'get_stock_info', which might also provide related financial data, so it lacks specificity in distinguishing its unique focus.
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. With many sibling tools for stock data (e.g., 'get_stock_iv_rank', 'get_stock_info'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on the name alone.
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.8get_alertsget_alerts_configurationget_congress_late_reportsget_congress_recent_tradesget_congress_traderget_darkpool_recentget_darkpool_tickerget_earnings_afterhoursget_earnings_premarketget_earnings_tickerget_etf_exposureget_etf_holdingsget_etf_in_outflowget_etf_infoget_etf_weightsget_market_economic_calendarget_market_fda_calendarget_market_spikeget_market_tideget_market_total_options_volumeget_news_headlinesget_option_trades_flow_alertsget_screener_analystsget_screener_option_contractsget_screener_stocksget_stock_flow_alertsget_stock_flow_recentget_stock_greek_exposureget_stock_infoget_stock_iv_rankget_stock_max_painget_stock_option_chainsget_stock_volatility_statsScored across 33 tools
Most tools have distinct purposes targeting specific financial data categories (congress trades, dark pools, earnings, ETFs, market indicators, news, screeners, stock/option analytics). Some potential overlap exists between flow-related tools (e.g., get_stock_flow_alerts vs get_stock_flow_recent) and ETF tools, but descriptions generally clarify the differences.
All tools follow a consistent 'get_[category]_[specific]' snake_case pattern, with clear and predictable naming. The structure is uniform across all 33 tools, making it easy to understand the domain and action at a glance.
33 tools is excessive for a single server, likely overwhelming for agents and suggesting poor scoping. While the domain (financial data) is broad, this many tools indicates fragmentation rather than a cohesive set, making it difficult to navigate and use effectively.
The tool set comprehensively covers the financial data domain implied by the server name and tool descriptions. It includes data on alerts, congress trades, dark pools, earnings, ETFs, market indicators, news, screeners, and detailed stock/option analytics, with no obvious gaps for the intended purpose.
Real SEC, 13F, insider, congress & macro data your AI agent can cite. Hosted MCP, 24 tools.
Unified financial infrastructure connecting AI agents directly to trade live/demo brokerage accounts, Web3 non-custodial wallets, real-time market data across equities, ETFs, crypto, forex, options, DeFi swaps, and prediction markets, institutional research feeds, and algorithmic strategy backtesters.
Aircraft intelligence for AI agents: valuations with uncertainty bands, FAA registry lookups, cost of ownership, comparable aircraft, fleet search, airworthiness directives and STCs, market metrics and forecasts, verified value reports, pre-buy diligence checklists, logbook search and a watchlist. 38 tools; free tier with OAuth or a Windsock API key.
US stock market data for AI agents: SEC filings, financials, insider trades, 13F, options, macro.
