MaverickMCP is a personal stock analysis MCP server offering 100+ professional-grade financial tools across these areas:
Stock Data Access – Fetch historical/real-time prices, fundamentals, news sentiment, Adanos market sentiment (Reddit, X, news, Polymarket), and chart links. Intelligent caching with batch fetching.
Technical Analysis – Calculate 20+ indicators (RSI, MACD, Bollinger Bands, support/resistance), generate full technical analysis reports and chart visualizations.
Stock Screening – Pre-seeded with 520 S&P 500 stocks. Screen for Maverick Bullish/Bearish setups, supply/demand breakouts, and filter by momentum score, sector, price, and volume. Schedule recurring screens and track history.
Portfolio Management – Add/remove/update positions with automatic cost basis averaging, live P&L, fractional shares, and multi-portfolio support (IRA, 401k, taxable, etc.).
Portfolio Analysis & Risk – Correlation matrix, side-by-side ticker comparison, risk dashboard (VaR, sector concentration, drawdown), pre-trade risk checks, regime-adjusted position sizing, and risk alerts.
Backtesting – VectorBT-powered backtests with 15+ built-in strategies (SMA cross, RSI, MACD, momentum, etc.) plus ML-enhanced, ensemble, and regime-aware algorithms. Includes walk-forward optimization, Monte Carlo simulations, parameter grid search, and multi-strategy comparison.
AI-Powered Research – Parallel AI agents for company deep-dives, market sentiment analysis, and multi-source research. Supports configurable personas, streaming analysis, and cost-optimized model selection.
Signals & Alerts – Create persistent price/indicator alerts (RSI, volume, SMA, price), backtest signal conditions against historical data, and manage market regime detection (bull, bear, choppy).
Trade Journal – Log and close trades with PnL tracking, strategy tags, rationale, and notes. Get aggregated performance metrics (win rate, expectancy, profit factor) per strategy.
Watchlists – Create named watchlists, add/remove symbols, generate scored intelligence briefs with catalyst flags (earnings, ex-dividend, FDA, etc.).
System Health & Performance – Monitor Redis cache, database performance, circuit breakers, resource usage (CPU, memory, disk), rate limits, and agent audit logs. Clear/optimize caches for maintenance.
Capability Discovery – List all available tools, strategies, and get detailed help on any tool or strategy.
Provides optional integration for AI-powered financial analysis features using OpenAI's language models
Supports PostgreSQL as a backend database option for storing financial data and analysis results
Uses Redis for intelligent caching of stock data and analysis results to improve performance
Uses SQLite as the default database backend for storing financial data and S&P 500 stock information
Click on "Install 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., "@MaverickMCP show me technical indicators for Apple over the last month"
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.
MaverickMCP is a personal-use FastMCP server that provides financial data analysis, technical indicators, stock screening, and portfolio tracking tools to any MCP client -- Claude Desktop, Claude Code, Cursor, VS Code, Codex CLI, Antigravity CLI, OpenCode, and others. Built for individual traders and investors, it runs entirely on your own machine with no authentication or billing complexity.
Core tools need no API key: market data comes from yfinance. Two optional
extras add more: [backtesting] (VectorBT-powered strategy backtesting) and
[research] (LangGraph-based deep research, bring-your-own LLM key).
Self-hosting MaverickMCP means Python, uv, and MCP client config (Redis and a research LLM key are optional). If you just want the analysis, Capital Companion is the hosted product built on the same engine: AI technical analysis, trade-plan review sheets with outcome tracking, and price alerts. 25 free analyses, no credit card.
Self-hosting instructions continue below.
Related MCP server: Trading MCP Server
Key Benefits:
No Setup Complexity: make dev gets the server running; no database
migrations, no seed scripts, no API key required for core tools.
Modern Python Tooling: Built with uv for fast dependency management.
Works With Any MCP Client: Standard MCP server over STDIO or Streamable HTTP -- no client-specific code. See Connect Your MCP Client.
37 Core Tools: Market data, technical analysis, screening, portfolio tracking with a risk dashboard, watchlists, and a trade journal.
Optional Extras: 12 backtesting tools and 3 research tools, each fully
opt-in via pip install/uv sync extras.
Smart Caching: Tiered cache (memory, then Redis or SQLite) with graceful fallback when Redis isn't running.
Open Source: MIT licensed.
Stock Data Access: Historical and real-time quotes with intelligent
caching (yfinance, no API key required).
Technical Analysis: RSI, MACD, support/resistance, and a combined full-analysis tool.
Stock Screening: Maverick bullish, bearish, and supply/demand strategies, computed over the tickers you've already queried.
Portfolio Tracking: Positions with average cost-basis, live P&L, a risk dashboard, watchlists, and a trade journal.
Backtesting ([backtesting] extra): VectorBT engine, 12 rule-based
strategy templates plus 8 ML strategy classes, optimization, walk-forward
analysis, and Monte Carlo simulation.
Research ([research] extra): LangGraph-based deep research over
companies, sectors, and market sentiment, backed by Exa web search and a
bring-your-own LLM.
Multi-Transport Support: STDIO and Streamable HTTP, so any MCP client can connect.
Python 3.12+: Core runtime environment
uv: Modern Python package manager (recommended)
Redis (optional, for enhanced caching)
PostgreSQL or SQLite (optional, for data persistence; SQLite is the default)
# macOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
# Alternative: via pip
pip install uvNote: The package is not on PyPI yet. The name
maverick-mcp-serveris held by a dormant, unrelated project, and a PEP 541 name-transfer request is pending with PyPI. Until this note is gone, do notpip install maverick-mcp-serveroruvx --from maverick-mcp-server: that name is not ours, and whatever its current owner publishes is what you would get. Use Option 1 (uvx from the release tag), Option 2 (the GHCR image), or Option 3 (from source).
# Runs the v1.1.0 tag straight from GitHub via uvx, invoking its
# maverick-mcp console script (no checkout, nothing from PyPI)
uvx --from "git+https://github.com/wshobson/maverick-mcp@v1.1.0" maverick-mcp --transport stdio
# With the backtesting and research extras
uvx --from "maverick-mcp-server[backtesting,research] @ git+https://github.com/wshobson/maverick-mcp@v1.1.0" maverick-mcp --transport stdio# Streamable HTTP on port 8000 inside the container, mapped to 8003 here;
# --env-file is optional (core tools need no keys)
docker run --rm -p 8003:8000 --env-file .env ghcr.io/wshobson/maverick-mcp:1.1.0Drop [backtesting,research] for a smaller, core-only install (37 tools,
no backtesting/research tools registered).
# Clone the repository
git clone https://github.com/wshobson/maverick-mcp.git
cd maverick-mcp
# Install dependencies and create virtual environment in one command
uv sync --extra dev
# Or, for the full tool surface:
uv sync --extra dev --extra backtesting --extra research
# Copy environment template
cp .env.example .env
# Configure DATABASE_URL / LLM_PROVIDER / EXA_API_KEY as needed (all optional)make dev # Streamable HTTP on http://localhost:8003/mcp
make dev-stdio # STDIO on this terminalClients configured for STDIO launch the server themselves -- you do not need
make dev running for those.
MaverickMCP is a standard MCP server with no client-specific behavior. Any client that speaks the Model Context Protocol can use it: Claude Desktop, Claude Code, GitHub Copilot, Codex CLI, Cursor, OpenCode, Antigravity CLI, and others.
Setup is one decision -- which transport -- followed by pasting the right config shape for your client.
STDIO | Streamable HTTP | |
Who starts the server | Your client, as a subprocess | You, via |
Endpoint | n/a |
|
Best for | A single local client | Several clients sharing one server, or remote access |
Config shape |
|
|
STDIO is the default and the simplest path for one local client. Use Streamable HTTP when several clients should share a single server process.
The HTTP endpoint hasno trailing slash: http://localhost:8003/mcp.
/mcp/ returns a 307 redirect, and clients that do not follow redirects on
POST will fail to register tools.
Client | STDIO | HTTP | Config location |
Claude Desktop | Yes (incl. | Via |
|
Claude Code | Yes | Yes |
|
VS Code (Copilot) | Yes | Yes |
|
GitHub Copilot CLI | Yes | Yes |
|
Codex CLI | Yes | Yes |
|
Cursor | Yes | Yes |
|
OpenCode | Yes | Yes |
|
Antigravity CLI | Yes | Yes |
|
Zed, LM Studio, Goose, Cline, Continue | Yes | Varies | Client-specific |
Clients not listed still work -- give them the STDIO command or the HTTP endpoint in whatever shape their config expects.
Full reference:
docs/runbooks/mcp-clients.mdcovers every client below in more depth, plus the.mcpbbundle, LAN binding, and per-client troubleshooting. The sections below are the common cases.
claude_desktop_config.json launches local STDIO servers only. Using the
release tag via uvx (no checkout needed, nothing from PyPI):
{
"mcpServers": {
"maverick-mcp": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/wshobson/maverick-mcp@v1.1.0",
"maverick-mcp",
"--transport",
"stdio"
]
}
}
}Running from a local source checkout instead:
{
"mcpServers": {
"maverick-mcp": {
"command": "uv",
"args": [
"run",
"python",
"-m",
"maverick.server",
"--transport",
"stdio"
],
"cwd": "/path/to/maverick-mcp"
}
}
}Config File Location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Always fully quit and restart Claude Desktop after making configuration changes.
Donot paste http://localhost:8003/mcp into Claude Desktop's "custom
connector" dialog. Custom connectors are brokered from Anthropic's cloud
rather than from your machine, so they cannot reach your localhost. For
Claude Desktop, local means STDIO or a .mcpb bundle (make bundle).
Claude Desktop's config file cannot express an HTTP server directly. To use the
HTTP transport there, bridge it with mcp-remote
(config). It is
the main client that still needs that bridge -- every client below speaks
Streamable HTTP natively, so do not wrap them in mcp-remote.
Windows Claude Desktop Users
Claude Desktop on Windows currently has a bug where it ignores the "cwd" configuration parameter, which can cause the server to crash with a ModuleNotFoundError when running via uv.
To bypass this, wrap the command in cmd.exe to force the directory change:
"maverick-mcp": {
"command": "cmd.exe",
"args": [
"/c",
"cd /d C:\\Path\\To\\maverick-mcp && uv run python -m maverick.server --transport stdio"
]
}# Streamable HTTP, against a running `make dev`
claude mcp add --transport http maverick-mcp http://localhost:8003/mcp
# STDIO. The `--` separator is required: without it, `claude mcp add`
# consumes `--transport stdio` as its own flag.
claude mcp add maverick-mcp -- \
uv run --directory /path/to/maverick-mcp python -m maverick.server --transport stdioAdd --scope user to register the server outside the current project. Verify
with claude mcp list.
Config Location: ~/.cursor/mcp.json (global) or .cursor/mcp.json (project)
{
"mcpServers": {
"maverick-mcp": {
"url": "http://localhost:8003/mcp"
}
}
}Config Location: .vscode/mcp.json. The key is servers, not
mcpServers, and type is required.
{
"servers": {
"maverick-mcp": {
"type": "http",
"url": "http://localhost:8003/mcp"
}
}
}Config Location: ~/.copilot/mcp-config.json (user) or .mcp.json in the
repository. tools filters which tools Copilot exposes; "*" is the default.
{
"mcpServers": {
"maverick-mcp": {
"type": "http",
"url": "http://localhost:8003/mcp",
"tools": ["*"]
}
}
}Or: copilot mcp add --transport http maverick-mcp http://localhost:8003/mcp
Config Location: ~/.codex/config.toml (global) or .codex/config.toml
(trusted projects). Shared by the ChatGPT desktop app, Codex CLI, and the IDE
extension.
[mcp_servers.maverick-mcp]
url = "http://localhost:8003/mcp"Or: codex mcp add maverick-mcp --url http://localhost:8003/mcp
Config Location: ~/.config/opencode/opencode.json (global) or
opencode.json in the project root. Servers live under mcp, and each entry
declares type as remote or local.
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"maverick-mcp": {
"type": "remote",
"url": "http://localhost:8003/mcp",
"enabled": true
}
}
}Google's replacement for Gemini CLI, which stopped serving individual accounts on 2026-06-18.
Config Location: ~/.gemini/config/mcp_config.json (global) or
.agents/mcp_config.json (workspace). Remote servers use serverUrl -- the
legacy Gemini CLI keys url and httpUrl are not used.
{
"mcpServers": {
"maverick-mcp": {
"serverUrl": "http://localhost:8003/mcp"
}
}
}Or: agy mcp add maverick-mcp http://localhost:8003/mcp
Nothing client-specific is required: supply either the STDIO command or the
HTTP endpoint above. See
docs/runbooks/mcp-clients.md
for the exact command/args values to paste.
MaverickMCP registers 37 core tools with a base install. Two optional
extras add more. Every tool is read-only (readOnlyHint: true) unless noted
otherwise. Full behavior detail lives in ARCHITECTURE.md,
docs/features/portfolio.md, docs/features/deep-research.md, and
docs/api/backtesting.md.
Tool | Description |
| OHLCV price history for a ticker, smart-cached. |
| Price history for multiple tickers at once. |
| A single quote, TTL-cached. |
| Valuation, financials, and trading stats. |
| Indices, sector performance, top movers, and volatility. |
| Static external chart links for a ticker. |
| Clear cached quotes (mutates cache state). |
Tool | Description |
| RSI reading and signal label. |
| MACD reading, signal label, and crossover state. |
| Support/resistance levels. |
| Full technical analysis: trend, outlook, every indicator. |
Tool | Description |
| Top Maverick bullish-momentum results, latest snapshot. |
| Top bearish setup results, latest snapshot. |
| Top supply/demand breakout results, latest snapshot. |
| Latest snapshot across all three screens. |
| Bullish results filtered by arbitrary criteria. |
| Recompute one screen (or all three) and persist it (mutates). |
Screens run over the local universe of tickers you've already queried via
market-data tools; there is no pre-seeded S&P 500 database. See
docs/runbooks/database-setup.md.
Tool | Description |
| Add/average into a position (mutates). |
| Full portfolio snapshot with live P&L. |
| Remove shares from a position (mutates). |
| Remove every position; requires |
| ATR-based position sizing/stop/target. |
| Side-by-side ticker comparison (auto-uses your portfolio). |
| Correlation matrix and diversification metrics. |
| Total value, sector exposure, and risk metrics. |
| Pre-trade risk check for a hypothetical trade. |
| Position size scaled by detected market regime. |
| Current sector/position/portfolio risk alerts. |
| Create a named watchlist (mutates). |
| Add a ticker to a watchlist (mutates). |
| Remove a ticker from a watchlist (mutates). |
| Intelligence brief for every symbol on a watchlist. |
| Log a new open trade (mutates). |
| Close an open trade; PnL computed automatically (mutates). |
| List journal trades, optionally filtered. |
| Full detail for a single journal trade. |
| Strategy performance analytics, with optional comparison. |
All analysis tools auto-detect your portfolio positions when no explicit
tickers are supplied. See docs/features/portfolio.md for the cost-basis
method and precision rules.
[backtesting] extra)Tool | Description |
| Run a single-strategy backtest: metrics, trades, analysis. |
| Grid-search a strategy's parameters. |
| Rolling optimize/test windows to gauge robustness. |
| Bootstrap-resample trades for a return/drawdown distribution. |
| Backtest multiple strategies on the same symbol and rank them. |
| List every rule-based strategy template with default parameters. |
| Backtest one strategy across multiple symbols. |
| Parse a natural-language description into a strategy + parameters (BYOK LLM). |
| Backtest an ML-enhanced strategy (adaptive, ensemble, regime-aware). |
| Train a random-forest ML predictor for trading signals. |
| Detect bear/sideways/bull regimes for a symbol. |
| Backtest a weighted ensemble of base strategies. |
12 rule-based strategy templates plus 8 ML strategy classes. Install with
uv sync --extra backtesting or pip install "maverick-mcp-server[backtesting] @ git+https://github.com/wshobson/maverick-mcp@v1.1.0".
Absent the extra, the server still boots and registers zero
backtesting_* tools.
[research] extra)Tool | Description |
| Comprehensive web-search-backed research on a financial topic. |
| Comprehensive research on a specific company. |
| Market sentiment analysis for a topic or sector. |
Requires a search backend (EXA_API_KEY for Exa, the default, or
RESEARCH_SEARCH_BACKEND=searxng plus SEARXNG_BASE_URL for a self-hosted
SearXNG instance) and a configured BYOK LLM
(LLM_PROVIDER/LLM_API_KEY/LLM_MODEL; see Configuration).
Install with uv sync --extra research or
pip install "maverick-mcp-server[research] @ git+https://github.com/wshobson/maverick-mcp@v1.1.0". Absent the extra, the server
still boots and registers zero research_* tools.
portfolio://my-holdings - a passive AI-context snapshot of your default
portfolio, automatically available to the assistant.
analyze_stock(ticker) - full technical + screening workflow for one ticker.
review_portfolio(portfolio_name) - portfolio + risk review workflow.
run_backtest_workflow(ticker, strategy) - strategy backtesting workflow
(registered only with the [backtesting] extra).
Configure MaverickMCP via .env file or environment variables. See
.env.example for the complete, code-verified list.
Essential Settings:
DATABASE_URL - PostgreSQL connection or sqlite:///maverick.db for SQLite (default).
REDIS_HOST - enables Redis caching when set; caching falls back to
in-memory/SQLite otherwise.
LOG_LEVEL - Logging verbosity (default: INFO).
No API key is required to run the core server; stock data comes from yfinance.
Optional (research extra, bring your own key):
LLM_PROVIDER - anthropic, openai, openrouter, or openai_compatible.
LLM_API_KEY - API key for the configured LLM_PROVIDER.
LLM_MODEL - Model name for the configured LLM_PROVIDER.
LLM_BASE_URL - Base URL override, required when LLM_PROVIDER=openai_compatible.
LLM_TEMPERATURE - Sampling temperature (default: 0.0).
EXA_API_KEY - Web search for the research tools (get at exa.ai).
RESEARCH_SEARCH_BACKEND - exa (default) or searxng.
SEARXNG_BASE_URL - Base URL of a self-hosted SearXNG instance with the JSON format enabled; used when the backend is searxng.
Migrating an older .env (legacy OPENROUTER_API_KEY-style auto-detection,
TIINGO_API_KEY, etc.)? See docs/runbooks/migrating-to-v1.md.
Once connected to Claude Desktop, use natural language:
"Show me the RSI and MACD analysis for NVDA"
"Identify support and resistance levels for MSFT"
"Get full technical analysis for AAPL""Run the Maverick bullish screen"
"Show me the top supply/demand breakout setups""Add 10 shares of AAPL I bought at $150.50"
"Show me my portfolio with current prices"
"Analyze correlation in my portfolio" # Auto-detects your positions
"Get my risk dashboard"
"Add AAPL to my watchlist"[backtesting] extra)"Run a backtest on AAPL using the momentum strategy for the last 6 months"
"Compare mean reversion vs trend following strategies on SPY"
"Optimize the RSI strategy parameters for TSLA"[research] extra)"Research the current state of the AI semiconductor industry"
"Provide comprehensive research on NVDA"
"Analyze market sentiment for the energy sector"make dev # Start server (streamable HTTP transport)
make dev-stdio # Start server (STDIO transport)
make stop # Stop services
make test # Unit tests (fast, default marker filter)
make test-all # All tests, including integration/slow/external
make test-specific TEST=test_name
make test-watch # Auto-run tests on file changes
make lint # ruff check + lint-imports
make format # ruff format + ruff check --fix
make typecheck # ty (Astral), same gate as CI
make check # lint + typecheck
make docs-check # validate the documentation catalog# Using uv directly
uv run pytest # Unit tests only
uv run pytest --cov=maverick # With coverage
uv run pytest -m "" # All tests (requires PostgreSQL/Redis for some)
uv run ruff check . # Linting
uv run ruff format . # Formatting
uv run ty check maverick # Type checking (Astral's ty); same scope as CIFor containerized deployment:
# Copy and configure environment
cp .env.example .env
# Using uv in Docker (recommended for faster builds)
docker build -t maverick-mcp-server .
docker run -p 8003:8000 --env-file .env maverick-mcp-server
# Or start with docker-compose
docker-compose up -dNote: The Dockerfile uses uv for fast dependency installation. The
image ships the [backtesting] and [research] extras by default; drop
--extra backtesting --extra research from the uv sync line in the
Dockerfile for a smaller, core-only image. There is no HTTP /health
endpoint or HEALTHCHECK -- this is an MCP server, not a REST API.
Tools missing or disappearing in your client:
Solution: Use the streamable HTTP endpoint with no trailing slash:
http://localhost:8003/mcp
/mcp/ returns a 307 redirect to /mcp; clients that do not follow
redirects on POST fail to register tools
Also confirm the transport matches: a client configured for STDIO against a running HTTP server (or the reverse) fails silently in most clients
Per-client troubleshooting: docs/runbooks/mcp-clients.md
Research Tool Timeouts:
Research tools have adaptive timeouts (120s-600s) based on requested depth
Deep research may take several minutes depending on complexity
Monitor progress in server logs with make tail-log
Research Tools Not Available:
Ensure the research extra is installed: pip install "maverick-mcp-server[research] @ git+https://github.com/wshobson/maverick-mcp@v1.1.0"
Ensure LLM_PROVIDER, LLM_API_KEY, and LLM_MODEL are set in .env
Ensure EXA_API_KEY is set for web search, or RESEARCH_SEARCH_BACKEND=searxng with SEARXNG_BASE_URL
Backtesting Tools Not Available:
Ensure the backtesting extra is installed: pip install "maverick-mcp-server[backtesting] @ git+https://github.com/wshobson/maverick-mcp@v1.1.0"
Empty screening results:
There is no pre-seeded universe; fetch price history for the tickers you
care about first (market_data_get_price_history), then run
screening_run_screens. See docs/runbooks/database-setup.md.
# Common development issues
make tail-log # View server logs
make stop # Stop services if ports are in use
make clean # Clean up cache files
# Quick fixes:
# Port 8003 in use → make stop
# Redis connection refused → brew services start redis / unset REDIS_HOST
# Tests failing → make test (unit tests only)Add custom financial analysis tools with simple decorators, following the
same pattern used throughout maverick/:
@mcp.tool()
def my_custom_indicator(ticker: str, period: int = 14):
"""Calculate custom technical indicator."""
# Your analysis logic here
return {"ticker": ticker, "signal": "buy", "confidence": 0.85}For issues or questions:
Check Documentation: Start with this README, AGENTS.md,
and docs/INDEX.md.
Search Issues: Look through existing GitHub issues
Report Bugs: Create a new issue with details
Request Features: Suggest improvements via GitHub issues
Contribute: See our Contributing Guide for development setup
MaverickMCP builds on these excellent open-source projects:
FastMCP - MCP framework powering the server
yfinance - Market data access
VectorBT - Backtesting engine ([backtesting] extra)
LangGraph - Research workflow orchestration ([research] extra)
The entire Python open-source community
MIT License - see LICENSE file for details. Free to use for personal and commercial purposes.
If you find MaverickMCP useful:
Star the repository
Report bugs via GitHub issues
Suggest features
Improve documentation
Built for traders and investors. Happy Trading!
Read the full build guide: How to Build an MCP Stock Analysis Server
This software is for educational and informational purposes only. It is NOT financial advice.
Investment Risk Warning: Past performance does not guarantee future results. All investments carry risk of loss, including total loss of capital. Technical analysis and screening results are not predictive of future performance. Market data may be delayed, inaccurate, or incomplete.
No Professional Advice: This tool provides data analysis, not investment recommendations. Always consult with a qualified financial advisor before making investment decisions. The developers are not licensed financial advisors or investment professionals. Nothing in this software constitutes professional financial, investment, legal, or tax advice.
Data and Accuracy: Market data provided by third-party sources (Yahoo Finance, and optionally Capital Companion/finviz for market movers). Data may contain errors, delays, or omissions. Technical indicators are mathematical calculations based on historical data. No warranty is made regarding data accuracy or completeness.
Regulatory Compliance: US Users - This software is not registered with the SEC, CFTC, or other regulatory bodies. International Users - Check local financial software regulations before use. Users are responsible for compliance with all applicable laws and regulations. Some features may not be available in certain jurisdictions.
Limitation of Liability: Developers disclaim all liability for investment losses or damages. Use this software at your own risk. No guarantee is made regarding software availability or functionality.
By using MaverickMCP, you acknowledge these risks and agree to use the software for educational purposes only.
Add a position to your portfolio with automatic cost basis averaging.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| shares | Yes | Number of shares purchased | |
| purchase_price | Yes | Price per share at purchase | |
| purchase_date | No | Date of purchase (YYYY-MM-DD format, optional) | |
| notes | No | Optional notes about the position |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions automatic cost basis averaging, a behavioral trait, but does not disclose side effects (e.g., overwriting existing position), authentication needs, or error conditions. With no annotations, the description partially meets the burden.
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?
Single sentence, front-loaded with core action and key behavior. Efficient, though could benefit from structured elements like bullet points.
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 presence of an output schema and full parameter descriptions, the description provides core purpose and a key behavior. However, missing context about prerequisites and error handling leaves some 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?
Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific meaning beyond the schema; 'automatic cost basis averaging' is general 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 'Add a position to your portfolio with automatic cost basis averaging' clearly states the verb and resource, including a key feature. However, it does not distinguish from the sibling tool 'portfolio_add_position', which appears to have similar functionality, causing potential confusion for the agent.
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 when-to-use or when-not-to-use guidance is provided. Prerequisites (e.g., portfolio existence) are not mentioned, and there is no comparison to alternatives like 'portfolio_add_position'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze market conditions using an AI agent with specified persona and strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| persona | No | moderate | |
| screening_strategy | No | momentum | |
| max_results | No | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral traits. It fails to disclose side effects, auth requirements, rate limits, or whether the agent analysis is deterministic. The single sentence provides no behavioral context beyond the basic purpose.
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 overly terse with a single sentence that fails to provide enough information. It is under-specified rather than concise, missing critical details about usage and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, 0% schema coverage, no annotations, and an output schema, the description adds no value beyond the tool name. It is completely inadequate for an AI agent to effectively invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should clarify parameter meanings. It mentions persona and screening_strategy but does not explain their roles or valid values, leaving significant ambiguity. The defaults are given but without 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 clearly states the tool uses an AI agent to analyze market conditions with specified persona and strategy, providing a specific verb+resource combination. However, it does not distinguish this tool from sibling agent tools like agents_compare_multi_agent_analysis or agents_orchestrated_analysis.
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 any context for when a single-agent analysis is appropriate compared to multi-agent or deep research options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare analysis results from multiple agent types side by side.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| agent_types | No | ||
| persona | No | moderate | |
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits, but it only states 'Compare analysis results... side by side.' It does not disclose whether the tool fetches new results or uses cached data, whether it is computationally expensive, or any side effects. Behavioral transparency is poor.
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 short (8 words), which is concise but at the expense of crucial information. It lacks structure and fails to earn its place by providing meaningful guidance. Under-specification is not 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 four undocumented parameters, many sibling analysis tools, and an existing output schema, the description is grossly incomplete. It does not explain what data is compared, how to specify agents, or what the output contains. The tool's complexity demands a richer description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (query, agent_types, persona, session_id). Parameter names alone are insufficient for correct usage, especially for 'persona' which defaults to 'moderate' but is not explained.
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 uses the verb 'compare' and specifies the resource 'analysis results from multiple agent types', clearly distinguishing it from siblings like agents_analyze_market_with_agent (single agent analysis) and agents_compare_personas_analysis (personas instead of agent types). The phrase 'side by side' adds concreteness.
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 on when to use this tool versus alternatives (e.g., agents_orchestrated_analysis). The description does not specify prerequisites, exclusions, or context beyond the tool's generic purpose. A user must infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare analysis results across different investor personas.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output 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 fails to disclose any behavioral traits such as required inputs, output format, side effects, or permissions. The brief statement does not add value beyond the tool name.
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 very short (one sentence) which is concise, but it is too minimal to provide sufficient information for an AI agent to use effectively.
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 presence of an output schema and two parameters, the description is incomplete. It does not clarify what 'investor personas' are, how they relate to the query, or what the analysis results look like, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'query' or 'session_id' parameters. The agent gets no additional meaning about how to use these 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 clearly states 'Compare analysis results across different investor personas', which specifies a verb (compare) and a resource (analysis results across personas). This distinguishes it from the sibling 'agents_compare_multi_agent_analysis', though not explicitly.
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 on when to use this tool versus alternatives such as 'agents_compare_multi_agent_analysis' or other comparison tools. The description lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform deep financial research on a topic with AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| research_topic | Yes | ||
| persona | No | moderate | |
| research_depth | No | comprehensive | |
| focus_areas | No | ||
| timeframe | No | 30d | |
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output 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 mentions 'AI agents' but fails to disclose behaviors like required permissions, asynchronicity, data handling, or what happens during research.
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 sentence (10 words) but is under-specified rather than concise. It lacks critical information and does not earn its place as a standalone description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no schema descriptions, no annotations, and no output schema details, the description is entirely inadequate. It does not explain the research process, outputs, or how to configure the tool 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 6 parameters with 0% description coverage. The description adds no explanation for parameters like research_topic, persona, or research_depth, forcing agents to rely solely on names.
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 'Perform deep financial research on a topic with AI agents,' providing a verb and resource. However, 'deep financial research' is vague and does not distinguish this tool from numerous sibling tools like research_company_comprehensive or research_comprehensive_research.
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 on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or context compared to other research tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get streaming analysis from an AI agent for real-time updates.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| persona | No | moderate | |
| stream_mode | No | updates | |
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'real-time updates' but does not explain how streaming works, whether connections are persistent, or any side effects (e.g., resource consumption). No mention of authentication or rate limits.
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 sentence, which is concise but lacks structure. It vaguely describes the purpose without sectioning or providing key details. It is not as efficient as it could be given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to explain returns), the description is insufficient. It does not cover parameter details or streaming behavior. For a tool with four parameters and real-time streaming, the description is too sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema has no parameter descriptions. The tool description does not explain any of the four parameters (query, persona, stream_mode, session_id), leaving the agent to infer their semantics from names and defaults.
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 'Get streaming analysis from an AI agent for real-time updates.' It specifies the action (get) and resource (streaming analysis). The term 'streaming' differentiates from non-streaming agent tools like agents_analyze_market_with_agent, but does not elaborate on the type of analysis.
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 agents_orchestrated_analysis or agents_compare_personas_analysis. There are no prerequisites, when-not-to-use instructions, or context on typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available LangGraph agents and their capabilities.
Returns: Information about available agents and personas
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the action and output. It does not disclose potential side effects, costs, or any behavioral traits beyond the basic listing operation.
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 two sentences with no extraneous information, front-loading the purpose. It is concise and well-structured.
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 simplicity (no parameters, no filtering), the description adequately covers the purpose and return value. The presence of an output schema reduces the need to explain return format, so it is mostly complete.
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 no parameters, so the description does not need to add param meaning. The baseline for zero parameters is 4, and the description confirms it returns information about agents and personas.
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 'List all available LangGraph agents and their capabilities' with a specific verb and resource, and it distinguishes from sibling tools like agents_analyze_market_with_agent by focusing on listing rather than analysis.
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 on when to use this tool versus alternatives or when not to use it. The description only states the action without any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform orchestrated multi-agent analysis with intelligent routing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| persona | No | moderate | |
| routing_strategy | No | llm_powered | |
| max_agents | No | ||
| parallel_execution | No | ||
| session_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only offers a vague hint of multi-agent orchestration. It does not disclose any behavioral traits such as side effects, permissions, or rate limits.
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 very concise (7 words) but under-specifies the tool's behavior. Conciseness is not beneficial when it comes at the cost of necessary detail.
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, output schema, many siblings), the description is completely inadequate. It lacks explanation of output, how routing works, or how parameters affect analysis.
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 0%, and the description itself provides no elaboration on any of the 6 parameters (query, persona, routing_strategy, etc.), adding no value beyond parameter names.
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 'Perform orchestrated multi-agent analysis with intelligent routing', indicating a verb and resource. However, it fails to differentiate from sibling tools like agents_analyze_market_with_agent or agents_compare_multi_agent_analysis, which also involve multiple agents.
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 on when to use this tool vs alternatives. There is no mention of use cases, prerequisites, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze market regimes for a stock using ML methods.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to analyze | |
| start_date | No | Start date for analysis | |
| end_date | No | End date for analysis | |
| method | No | Detection method (hmm, kmeans, threshold) | hmm |
| n_regimes | No | Number of regimes to detect | |
| lookback_period | No | Lookback period for regime detection |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'using ML methods' without detailing what those methods are, what the tool does internally, or any side effects. This is insufficient for a complex analytical tool with multiple 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 sentence with no unnecessary words. It is as concise as possible while still conveying the core 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 tool has 6 parameters and an output schema, the description is too brief. It does not explain the return format, the significance of the 'method' parameter, or how to interpret results. More context is needed 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?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description does not add any additional meaning beyond what the schema provides. Baseline 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 tool analyzes market regimes for a stock using ML methods. It specifies the resource (stock market regimes) and the action (analyze). However, it does not differentiate from siblings like 'get_market_regime' which may have similar 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 such as 'get_market_regime' or 'backtest_signal'. It lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backtest a strategy across multiple symbols (portfolio).
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | List of stock symbols | |
| strategy | No | Strategy type to apply | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| initial_capital | No | Starting capital | |
| position_size | No | Position size per symbol (0.1 = 10%) | |
| fast_period | No | ||
| slow_period | No | ||
| period | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether the tool is read-only, requires authentication, or has side effects. The agent is left unaware of potential impacts.
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 very concise at one sentence, but it sacrifices necessary detail. While efficient, it could be more informative without becoming verbose.
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 9 parameters and multiple sibling tools, the description is too sparse. It does not explain return values, strategy options, or how parameters like period relate to the backtest, even though an output schema exists.
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 description adds no parameter context beyond the schema. Critical parameters like fast_period, slow_period, and period are undocumented in the schema, and the description does not clarify them, leaving gaps in 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 tool backtests a strategy across multiple symbols, distinguishing it from single-symbol backtesting tools like backtest_signal. However, it could be more specific about strategy types or the portfolio 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?
No guidance is provided on when to use this tool versus alternatives like run_backtest, compare_strategies, or backtest_signal. The agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Backtest a saved signal definition against historical OHLCV data. Walks the data bar-by-bar through the live signal evaluation engine so the entry/exit edges match what the signal would produce in production. Returns trade list and summary metrics (total return, win rate, Sharpe, max drawdown).
| Name | Required | Description | Default |
|---|---|---|---|
| signal_id | Yes | ID of the persisted signal whose condition will be replayed. | |
| start_date | Yes | Backtest window start (YYYY-MM-DD). | |
| end_date | Yes | Backtest window end (YYYY-MM-DD). | |
| initial_capital | No | Starting cash for the simulated portfolio. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It clearly explains the bar-by-bar walkthrough using the live evaluation engine, ensuring production matching, and lists key output metrics. Minor omission: no mention of data prerequisites or performance 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?
Two sentences that front-load the purpose and efficiently cover the evaluation method and output. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (returns trade list and summary metrics), the description appropriately lists specific metrics (total return, win rate, Sharpe, max drawdown). Lacks mention of error states or required data availability, but overall covers the essential context for correct tool 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?
Schema coverage is 100%, and parameter descriptions in the schema are adequate. The tool description adds overarching context (bar-by-bar engine) but does not enhance individual parameter meanings beyond what the schema already provides.
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 uses a specific verb ('backtest') and resource ('saved signal definition'), explicitly contrasting with sibling tools like 'backtest_portfolio' or 'run_backtest' by emphasizing bar-by-bar live engine simulation for signal fidelity.
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?
Implies usage context (requires a saved signal ID and date range) but does not explicitly state when to prefer this tool over alternatives like 'backtest_portfolio' or 'walk_forward_analysis'. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger evaluation of all active signals against current market data. Returns a list of evaluation results including which signals triggered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the tool triggers evaluation and returns results, but fails to mention side effects (e.g., state changes, logging), authorization requirements, or rate limits. This is insufficient for a mutation-like operation.
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 two sentences, front-loaded with the action and result, with no extraneous information. Every sentence is essential and concise.
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 no parameters and an output schema (not provided), the description adequately covers the purpose and return format. However, it could mention whether the results are persisted or available for later retrieval, especially given the many sibling 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 zero parameters, and schema coverage is 100%. As per guidelines, 0 parameters yields a baseline of 4. The description adds no parameter information, which is acceptable since there are none.
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: manually triggering evaluation of all active signals against current market data and returning results. It distinguishes from siblings like list_signals (which lists without triggering) and backtest_signal (which evaluates historically).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies on-demand use but does not explicitly state when to use versus alternatives like automated evaluation, nor does it mention any prerequisites or exclusions. No guidance is provided for when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare multiple strategies on the same symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol | |
| strategies | No | List of strategy types to compare (defaults to all) | |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention any side effects, permissions, or data mutability. The output schema exists but is not referenced. The description adds minimal behavioral context beyond the name.
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 sentence, making it concise, but it is too vague and lacks structure. It could benefit from additional clarifying information without becoming verbose. The sentence earns its place but is minimally informative.
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 (4 params, output schema, many siblings), the description is insufficiently complete. It does not clarify what comparison entails, how results are returned, or how it differs from overlapping tools like 'get_strategy_comparison'. The output schema exists but is not leveraged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description does not add meaning beyond the schema—it simply restates the concept of comparing strategies. No extra semantics for parameters like 'strategies' defaults or date formats.
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 compares multiple strategies on the same symbol, which is a specific action. However, it lacks differentiation from similar siblings like 'get_strategy_comparison' and doesn't specify what aspect (performance, parameters) is compared.
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. There is no mention of prerequisites, exclusions, or context like when to prefer this over 'get_strategy_comparison' or other strategy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare stocks side-by-side with technical metrics.
If no tickers provided, automatically compares all portfolio holdings.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | No | List of ticker symbols to compare (optional, auto-uses portfolio) | |
| days | No | Number of days for comparison period (default 90) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses auto-fallback behavior but does not explicitly state read-only nature or other side effects. Given the safe nature of comparison, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and front-loaded. No wasted words, efficiently conveys core functionality and key conditional behavior.
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?
Has output schema and 100% schema coverage. Description covers the main use case and the auto-fallback behavior. For a tool with only two optional parameters, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context about auto-using portfolio for tickers parameter but does not add significant new meaning beyond schema descriptions.
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?
Description clearly states it compares stocks using technical metrics. However, it does not differentiate itself from sibling tools like portfolio_compare_tickers or compare_strategies, which have similar 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?
Description implies usage: use when needing stock comparison with technical metrics, and notes auto-fallback to portfolio. But no explicit when-not or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a persistent price/indicator alert signal. The condition dict must specify 'indicator' (price, rsi, volume, sma), 'operator' (lt, gt, lte, gte, spike, crosses_above, crosses_below), and 'threshold' (numeric, not needed for spike).
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | ||
| ticker | Yes | ||
| condition | Yes | ||
| interval_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It mentions persistence and condition requirements but does not detail what happens upon creation (e.g., automatic monitoring, notifications) or limitations on signal count.
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?
Single sentence that is front-loaded with action and efficiently conveys condition requirements. Slightly long but still concise.
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?
Output schema exists, so return values need not be explained. The description covers the condition parameter well but omits practical details like activation timing, notification behavior, and signal limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It thoroughly explains the condition parameter structure (indicator, operator, threshold), but does not add meaning to label, ticker, or interval_seconds beyond their names.
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?
Description clearly states it creates a persistent price/indicator alert signal, specifying the resource and action. It distinguishes from sibling tools like update_signal, delete_signal, and list_signals.
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 explains the condition dict requirements but does not explicitly state when to use this tool over alternatives like check_signals_now or update_signal. However, the sibling context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create and backtest a strategy ensemble across multiple symbols.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | Yes | List of stock symbols | |
| base_strategies | No | List of base strategy names to ensemble | |
| weighting_method | No | Weighting method (performance, equal, volatility) | performance |
| start_date | No | Start date for backtesting | |
| end_date | No | End date for backtesting | |
| initial_capital | No | Initial capital per symbol |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It only states the action without revealing side effects (e.g., data persistence), performance implications, or any state changes. The output schema exists but is not referenced.
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, well-structured sentence of 10 words. It is front-loaded with the purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema exists), the description is minimal. It does not explain what an ensemble is, how weighting methods work, or what the backtest produces. The output schema likely covers return values, but the description could still be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully documented in the schema. The description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate as the description is not misleading but contributes nothing extra.
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 ('Create and backtest') and the resource ('strategy ensemble') and specifies the scope ('across multiple symbols'). It distinguishes this tool from siblings like 'create_signal' or 'optimize_strategy' which focus on individual strategies.
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 'optimize_strategy', 'compare_strategies', or 'backtest_signal'. It lacks context about prerequisites or complementary tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear cached data for a specific ticker or all tickers.
This tool helps manage the local cache by removing stored data, forcing fresh data retrieval on the next request.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Specific ticker to clear (None to clear all) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions clearing cache and forcing fresh retrieval, but lacks details on side effects (e.g., temporary performance impact). Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading key information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple action, description is complete for usage purpose. However, with an output schema existing, it does not mention return values, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description already stating 'Specific ticker to clear (None to clear all)'. Description adds minimal extra meaning beyond repeating the scope.
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?
Description clearly states the action: clearing cached data for a specific ticker or all tickers. It uses a specific verb and resource, and distinguishes from siblings like data_fetch_stock_data or data_get_cached_price_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?
Explains that it forces fresh data retrieval on next request, giving clear context for use. However, it does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch historical stock data for a given ticker symbol.
This is the primary tool for retrieving stock price data. It uses intelligent caching to minimize API calls and improve performance.
Updated to use separated services following Single Responsibility Principle.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The ticker symbol of the stock (e.g., AAPL, MSFT) | |
| start_date | No | Start date for data in YYYY-MM-DD format (default: 1 year ago) | |
| end_date | No | End date for data in YYYY-MM-DD format (default: today) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions 'intelligent caching' but omits critical details such as rate limits, authentication requirements, error handling, or whether the tool is read-only.
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 three sentences long, but the second and third sentences add minor value ('intelligent caching', SRP) that could be omitted without loss of 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 the presence of an output schema, return values need not be detailed, but the description lacks clarity on what exactly constitutes 'historical stock data' and how it differs from batch variants.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for ticker, start_date, and end_date. The description adds no additional meaning or examples beyond what the schema provides.
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 it fetches historical stock data and calls it the 'primary tool' for this purpose. However, it does not distinguish itself from siblings like data_fetch_stock_data_batch or fetch_stock_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 labels it as the 'primary tool' but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch historical data for multiple tickers efficiently.
This tool fetches data for multiple stocks in a single call, which is more efficient than calling fetch_stock_data multiple times.
Updated to use separated services following Single Responsibility Principle.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | Yes | List of ticker symbols (e.g., ["AAPL", "MSFT", "GOOGL"]) | |
| start_date | No | Start date in YYYY-MM-DD format | |
| end_date | No | End date in YYYY-MM-DD format |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only mentions that it 'fetches data for multiple stocks in a single call' and includes an irrelevant implementation detail about SRP. There is no information on error handling, rate limits, caching, or return format, which is insufficient 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 consists of three sentences. The first two are concise and relevant. The third sentence about 'Single Responsibility Principle' is an implementation detail that does not help an AI agent and could be removed. It is not overly long but has minor waste.
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?
The tool fetches multiple tickers in batch, which is moderately complex. The description mentions efficiency but lacks details on output format, error handling, or limits (e.g., maximum tickers). An output schema exists but is not shown; the description could still add context on typical behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema's parameter descriptions. It reinforces efficiency for multiple tickers but does not clarify constraints or format beyond what the schema already provides.
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 'Fetch historical data for multiple tickers efficiently', specifying the verb (fetch), resource (historical data), and scope (multiple tickers). It also explicitly distinguishes from siblings like fetch_stock_data by highlighting efficiency, which helps the agent select the appropriate 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?
The description provides explicit guidance on when to use this tool: 'more efficient than calling fetch_stock_data multiple times'. It does not mention scenarios where batch fetching is not suitable or any prerequisites, but the core usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get optional Adanos market sentiment data for stocks.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional stock ticker. If omitted, returns market-wide sentiment. | |
| days | No | Lookback window in days. | |
| sources | No | Optional list of Adanos sources: reddit, x, news, polymarket. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It does not disclose behavioral traits such as read-only, data freshness, rate limits, or any side effects. The name hints at read-only, but the description adds nothing beyond basic purpose.
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 short sentence, which is concise but lacks informative structure. It could be improved by front-loading key differentiators or usage tips. It is not overly verbose, but it sacrifices clarity 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 tool's complexity (3 parameters, output schema exists, many sibling tools), the description is insufficient. It does not explain what 'Adanos market sentiment' encompasses, how the output is structured, or how this tool fits among alternatives. The description leaves the agent with significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters (ticker, days, sources). The tool description adds no additional parameter meaning beyond the schema. Baseline 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 states a specific verb ('Get') and resource ('Adanos market sentiment data for stocks'), but fails to differentiate from siblings like 'data_get_news_sentiment' or 'research_analyze_market_sentiment'. The term 'optional' is unclear. Purpose is clear at a high level but not uniquely identifying.
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 on when to use this tool versus similar tools (e.g., get_adanos_market_sentiment, data_get_news_sentiment). No when-not or alternative suggestions. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cached price data directly from the database.
This tool retrieves data from the local cache without making external API calls. Useful for checking what data is available locally.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| start_date | Yes | Start date in YYYY-MM-DD format | |
| end_date | No | End date in YYYY-MM-DD format (optional, defaults to today) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It clearly states it reads from a local cache and does not make external API calls. This is sufficient for a simple read operation, though it could mention what happens on missing or empty 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 very concise with two sentences. The first sentence immediately conveys the main action and resource ('Get cached price data directly from the database'). Every sentence adds value 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 tool's simplicity (3 parameters, straightforward read operation), the description covers the core purpose and usage context. An output schema exists, so return values need not be detailed. It could be slightly improved by noting the behavior if data is not found, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 3 parameters (ticker, start_date, end_date). The description does not add additional meaning beyond the schema's parameter descriptions, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get cached price data directly from the database' and 'retrieves data from the local cache without making external API calls', clearly identifying the resource (cached price data) and action (get). It also distinguishes from sibling tools like data_fetch_stock_data by highlighting the cache vs external call difference.
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 includes 'Useful for checking what data is available locally', providing clear context for when to use this tool. While it does not explicitly state when not to use or list alternatives, the contrast with external fetching is implied by mentioning 'without external API calls'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide links to various financial charting websites.
This tool generates URLs to popular financial websites where detailed stock charts can be viewed, including:
TradingView (advanced charting)
Finviz (visual screener)
Yahoo Finance (comprehensive data)
StockCharts (technical analysis)
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The ticker symbol of the stock |
| Name | Required | Description |
|---|---|---|
No output 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 the tool 'generates URLs' and lists the sites, implying a read-only operation. It is clear about its functionality, though it does not disclose potential restrictions like API keys or rate limits, which is acceptable for a simple link-generating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: two short paragraphs with a bulleted list. It front-loads the primary purpose and adds detail without redundancy. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema present. The description covers the purpose and examples adequately. It could mention the structure of the returned data, but since an output schema exists, this is not a major gap.
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% coverage with a description for the 'ticker' parameter. The tool description does not add any additional semantics, such as format or case sensitivity, beyond what the schema already provides. Baseline 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 tool's purpose: providing links to financial charting websites. It lists specific examples (TradingView, Finviz, Yahoo Finance, StockCharts), differentiating it from sibling tools like data_fetch_stock_data or generate_backtest_charts that handle raw data or chart generation.
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 explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. It implies usage when chart links are needed but lacks comparisons to sibling tools or conditions for avoidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get news sentiment analysis for a stock using Tiingo News API or LLM analysis.
This enhanced tool provides reliable sentiment analysis by:
Using Tiingo's news API if available (requires paid plan)
Analyzing sentiment with LLM (Claude/GPT)
Falling back to research-based sentiment
Never failing due to missing EXTERNAL_DATA_API_KEY
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| timeframe | No | Time frame for news (1d, 7d, 30d, etc.) | 7d |
| limit | No | Maximum number of news articles to analyze |
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 discloses behavioral traits: uses multiple sources (Tiingo, LLM, research), has fallback logic, and never fails due to missing API key. This is good transparency for a data retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but not overly long, uses bullet points to list features, and is front-loaded with the main purpose. Some repetition could be trimmed, but overall it is appropriately sized.
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 output schema and no annotations, the description does a good job explaining the tool's behavior, reliability, and inputs. It covers error handling (never failing due to missing API key). Could mention output format, but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds value by explaining the tool's behavior with parameters (limit, timeframe) and fallback logic, but does not add significant meaning beyond the schema descriptions.
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 gets news sentiment analysis for a stock using Tiingo News API or LLM analysis, specifying the resource (stock) and action (get news sentiment). It distinguishes itself from siblings through its emphasis on enhanced reliability and fallback mechanisms.
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 explains reliability features and fallback options, but does not explicitly state when to use this tool versus alternatives like get_news_sentiment or research_analyze_market_sentiment. It provides context about never failing due to missing API key, but lacks explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed fundamental information about a stock.
This tool retrieves comprehensive stock information including:
Company description and sector
Market cap and valuation metrics
Financial ratios
Trading information
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output 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 fails to disclose whether the tool is read-only, has authentication requirements, rate limits, or any side effects beyond returning 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 concise with a front-loaded purpose and a bullet list. Minor improvement could integrate the bullet list more tightly, but overall efficient.
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 one parameter and an output schema (not shown), the description adequately outlines the scope of returned data. It covers key categories, making it sufficient for agent 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?
Schema coverage is 100%, so baseline 3. The description does not add additional meaning beyond the schema's 'Stock ticker symbol', such as format or exchange details.
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 retrieves detailed fundamental stock information and lists categories like company description, sector, market cap, etc. It distinguishes from sibling tools focused on price data or other types of information.
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 on when to use this tool versus alternatives, especially given the sibling 'get_stock_info' which shares a similar name. The description does not provide context-dependent usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a signal alert by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive action ('delete') but lacks details on side effects, permissions, or permanence. With no annotations, the description should bear the burden of transparency; it does the minimum by stating the action but omits behavioral specifics.
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 sentence with no excess words. It conveys the essential information efficiently.
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 only one parameter and an output schema (not shown), the description is fairly complete. It covers the action and the required input. However, it could mention return value confirmation or note that deletion is irreversible.
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 only parameter signal_id is mentioned as 'by ID' in the description, which clarifies its purpose. However, schema description coverage is 0%, so the description adds only marginal meaning. The integer type is self-explanatory, but no format or context (e.g., where to get the ID) is provided.
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 (delete) and the specific resource (signal alert) with a clear identifier (by ID). It is specific enough to understand the tool's function, though it does not explicitly differentiate from sibling tools like update_signal or create_signal.
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. There is no mention of prerequisites, best practices, or when not to use it. The sibling list contains many related tools, but the description offers no comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover all available capabilities of the MaverickMCP server.
This tool provides comprehensive information about:
Available strategies (traditional and ML)
Tool categories and their functions
Parameter requirements for each strategy
Example usage patterns
Use this as your first tool to understand what's available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output 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 accurately describes the tool's behavior: it returns comprehensive information about server capabilities. Since it has no side effects and is a safe read-only operation, the description is sufficient. A slightly higher score could mention that it returns a list, but it's already clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a bullet list. It front-loads the core purpose, then details what is discovered, and ends with usage instruction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and the existence of an output schema (as indicated by context signals), the description is complete. It clearly explains the tool's purpose, what it provides, and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100% by default. The description adds value by explaining what the tool returns, which is beyond the schema's capability. Baseline 4 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 tool's purpose: 'Discover all available capabilities of the MaverickMCP server.' It lists specific information provided (strategies, tool categories, parameter requirements, example usage), which distinguishes it from the many siblings focused on specific tasks.
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?
Explicitly advises 'Use this as your first tool to understand what's available.' This provides clear guidance on when to use it and establishes it as an introductory tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch historical OHLCV price data for a stock.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| start_date | No | Start date (YYYY-MM-DD format, optional) | |
| end_date | No | End date (YYYY-MM-DD format, optional) |
| Name | Required | Description |
|---|---|---|
No output 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 does not mention rate limits, data source, pagination, or behavior with large date ranges. Only states it fetches historical data, which is minimal.
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?
Single sentence with no unnecessary words. Front-loaded with the key action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. However, missing details like default date range, data frequency, and usage guidelines. For a data retrieval tool, these are gaps, but the presence of output schema raises the baseline.
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?
Input schema covers all three parameters with clear descriptions (ticker symbol, dates in YYYY-MM-DD). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate given 100% 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?
Description clearly states the verb 'Fetch', the resource 'historical OHLCV price data', and the scope 'for a stock'. This distinguishes it from sibling tools like 'data_fetch_stock_data_batch' and 'data_get_cached_price_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?
No guidance on when to use this tool versus alternatives like batch fetch or cached data. The sibling list is large but no hints are provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate comprehensive charts for a backtest.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol | |
| strategy | No | Strategy type | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| theme | No | Chart theme (light or dark) | light |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'generate charts' but omits details like whether it requires a prior backtest, if it modifies state, or output characteristics. The description is too thin for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded but could benefit from a brief example or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and an output schema, the description lacks necessary context about prerequisites (e.g., a backtest must exist), return format, or how it fits with sibling tools. It is incomplete 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?
Schema coverage is 100%, and the description adds no extra meaning beyond the parameter names and default values. Baseline 3 is appropriate as the schema already documents parameters sufficiently.
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 generates charts for a backtest, which distinguishes it from pure backtesting or optimization tools. However, it does not specify the type or scope of charts, leaving minor ambiguity.
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 on when to use this tool versus alternatives like generate_optimization_charts or data_get_chart_links. The description lacks context for appropriate use cases and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate chart for strategy parameter optimization.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol | |
| strategy | No | Strategy type | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| theme | No | Chart theme (light or dark) | light |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits like whether it creates files, requires permissions, or the nature of its output. It is too minimal.
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. It earns its place but lacks structure; could benefit from front-loading key behavioral info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and a missing output description despite the tool having an output schema, the description is incomplete. It does not explain what the chart output looks like or any side effects.
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 parameters. The description adds no extra meaning beyond the schema, providing a baseline with no degradation.
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 generates charts for strategy parameter optimization, using a specific verb and resource. It distinguishes from siblings like generate_backtest_charts and optimize_strategy.
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 on when to use this tool versus alternatives such as generate_backtest_charts or optimize_strategy. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get optional Adanos sentiment from Reddit, X / FinTwit, News, and Polymarket.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | No | Optional stock ticker. Omit for market-wide sentiment. | |
| days | No | Lookback window in days. | |
| sources | No | Optional sources: reddit, x, news, polymarket. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states 'Get' which implies a read operation. It does not disclose behavioral traits like rate limits, caching, authentication requirements, or whether the data is live or delayed.
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 sentence that efficiently conveys the tool's purpose. It is front-loaded with the key verb and resource. However, it could be slightly expanded to include more context 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 existence of an output schema (not shown), the description does not need to explain return values. It covers the basic purpose and parameters. However, with many sibling sentiment tools, the description lacks context on uniqueness, making it less complete for choosing the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The description adds no additional meaning beyond listing sources. Baseline 3 is appropriate as the schema already provides sufficient detail.
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 'Adanos sentiment' with specific sources (Reddit, X/FinTwit, News, Polymarket). It also notes optionality for ticker. However, it does not differentiate from sibling sentiment tools like data_get_news_sentiment or research_analyze_market_sentiment.
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 explicit guidance on when to use this tool versus alternatives. The description implies it aggregates multiple sources, but does not state when to choose this over other sentiment tools or exclude other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run all screening strategies and return combined results.
Returns bullish, bearish, and breakout candidates in a single response.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It does not disclose potential performance impact, data recency, or whether the operation is read-only, leaving behavioral traits unclear.
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 two sentences long, concise, and front-loaded with the core action and result, with no extraneous content.
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 absence of parameters and presence of an output schema, the description minimally covers the tool's functionality. It mentions output categories but lacks context on side effects or operational scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter details, but with no parameters, a baseline of 4 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 tool runs all screening strategies and returns combined results, specifying outputs as bullish, bearish, and breakout candidates. This distinctly sets it apart from sibling screening tools.
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 on when to use this tool versus alternatives like get_maverick_stocks or get_supply_demand_breakouts. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of all circuit breakers.
Returns information about circuit breaker states, failure counts, and performance metrics for all external API connections.
Returns: Dictionary containing circuit breaker status information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states what is returned, not side effects, rate limits, or safety (e.g., read-only). The 'get' verb implies read-only, but the description does not explicitly confirm or provide additional 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 concise (3 sentences) and front-loaded with the main purpose. The 'Returns:' section is slightly redundant but not harmful. Could be slightly tighter without the Returns section.
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 no parameters and the output schema exists (though not shown), the description sufficiently explains what the tool does and the general nature of the response. It is complete for a simple status retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds meaning by explaining the return structure (dictionary with status info), which aids understanding. Baseline for 0 params is 4.
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 'Get status of all circuit breakers' with specific verb and resource. It further details the return content (states, failure counts, performance metrics). There is no ambiguity and it distinguishes itself from sibling tools that target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking circuit breaker status but provides no explicit guidance on when to use vs alternatives or when not to use. No exclusions or context about alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status of a specific component or all components.
| Name | Required | Description | Default |
|---|---|---|---|
| component_name | No | Name of the component to check (optional). If not provided, returns status of all components. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It states 'Get status' implying read-only behavior, but does not disclose any side effects, permissions, or what status data means. With no annotations, this is insufficient for behavioral clarity.
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?
Single sentence with no redundant words. Perfectly concise.
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 simplicity (one optional param, output schema exists), the description is minimally adequate. However, it does not explain what a 'component' is or the format of the status, leaving some gap. The presence of an output schema partly mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by clarifying that omitting 'component_name' returns status for all components, which is not explicit in the schema. This goes beyond the schema's 'optional' note.
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 status') and the resource ('component'), with a clear distinction between specific and all components. This distinguishes it from many sibling tools that target other entities like 'system_health' or 'circuit_breaker_status'.
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 on when to use this tool versus alternative status-checking tools like 'get_system_health' or 'get_circuit_breaker_status'. The description implies a general purpose but lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the agent decision audit trail.
Returns recent decision records showing query classifications, agent routing, token usage, cost estimates, and outcomes.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Optional session ID to filter by. If omitted, returns the most recent decisions across all sessions. | |
| limit | No | Maximum number of records to return (default 20, max 100). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states it queries the audit trail and returns records, but does not mention if it is read-only, any rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, clearly front-loaded with action and return data. No superfluous text, though could be more structured with usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and only two optional parameters, the description covers the basic behavior. However, it lacks usage guidelines and behavioral transparency, making it incomplete for fully informed 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?
Schema coverage is 100%, so the input schema already documents both parameters. The description adds a summary of return values but does not provide additional semantic meaning beyond what the schema descriptions convey.
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 queries the agent decision audit trail and lists specific return fields (query classifications, agent routing, token usage, cost estimates, outcomes). It is a specific verb+resource with no ambiguous sibling overlap.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or comparison to sibling tools like get_health_history or get_resource_usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get upcoming economic events and indicators.
Provides full access to economic calendar data.
| Name | Required | Description | Default |
|---|---|---|---|
| days_ahead | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It merely says 'full access' without specifying authentication needs, rate limits, or data freshness. Lacks transparency about what the tool does beyond retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff, though the second sentence is redundant. Overall efficient but could be slightly more informative without adding length.
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 output schema exists, the description does not need to detail return values, but it omits any context about the scope of 'events' or 'indicators,' and does not explain the single parameter's effect. Incomplete for a tool with minimal annotations.
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 sole parameter 'days_ahead' has no description in the schema (0% coverage) and the description does not explain its meaning or default value. The agent gets no additional guidance on how to use this 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 clearly states it gets upcoming economic events and indicators, which defines the resource and action. However, it does not differentiate from similar sibling tools like get_upcoming_catalysts, lacking specificity in 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?
No guidance on when to use this tool versus alternatives or prerequisites. The description is generic and does not help an agent decide between this and other data retrieval tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full technical analysis: RSI, MACD, Bollinger Bands, SMA/EMA, volume, S/R levels.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| days | No | Number of days of historical data (default 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits (e.g., that it reads data, is safe, or any rate limits, caching, or output size). The description only lists indicators.
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?
Single sentence listing indicators is very concise. No wasted words, though it could be slightly more structured (e.g., bullet points). Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal. It does not explain the format or scope of the analysis (e.g., across all days? summary?). For a multi-indicator tool, more context on what is returned 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?
Schema coverage is 100% with clear descriptions for ticker and days. The tool description adds no extra meaning to parameters beyond the list of indicators, which is not parameter-specific. 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 states 'Full technical analysis' and lists multiple indicators (RSI, MACD, etc.), clearly indicating it combines these analyses. It distinguishes from sibling tools like get_rsi_analysis which are single-indicator, but does not explicitly state this aggregation.
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 on when to use this tool vs. the many individual indicator tools (e.g., get_rsi_analysis, get_support_resistance). No when-not scenarios or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical health data for trend analysis.
Returns recent health check history including component status changes, resource usage trends, and system performance over time.
Returns: Dictionary containing historical health information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It states the tool returns historical data but omits details like data retention limits, request frequency, or authentication requirements. The read-only nature is implied but not stated.
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?
Three sentences, front-loaded purpose, no redundant information. Every sentence adds value: purpose, contents, return 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 zero parameters and an output schema, the description covers essential aspects: historical scope, included data types, and return format. It omits specifics like time range or pagination, but these may be in the output schema or unnecessary for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (trivially). Description adds no parameter semantics, which is appropriate; baseline 4 is justified.
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 retrieves historical health data for trend analysis, differentiating it from current status tools like get_system_health. However, it does not explicitly name siblings or contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for trend analysis via 'trend analysis', but provides no explicit guidance on when to use this tool versus siblings like get_system_health or get_resource_usage, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MACD crossover signals and divergence analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| fast_period | No | Fast EMA period (default 12) | |
| slow_period | No | Slow EMA period (default 26) | |
| signal_period | No | Signal line period (default 9) | |
| days | No | Number of days of historical data (default 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden but fails to disclose important behaviors such as data refresh behavior, historical vs real-time, or any side effects. It only states what it does, not 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, concise sentence that gets the point across with no wasted words. However, it could be slightly more informative without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value details are covered. However, given the tool's complexity and the presence of sibling tools like technical_get_macd_analysis, the description leaves ambiguity about what exactly is returned (e.g., signal dates, strength). Minimal but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the parameter descriptions in the schema. It does not explain how parameter values affect analysis or provide examples.
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 gets MACD crossover signals and divergence analysis, using a specific verb and resource. It distinguishes from sibling technical analysis tools like get_rsi_analysis or get_support_resistance.
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 on when to use this tool over alternatives, no when-not-to-use instructions, and no mention of prerequisites or context like whether real-time data is used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive market overview including indices, sectors, and market breadth.
Provides full market data without restrictions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior like data freshness, caching, or limits. It only states 'full market data without restrictions' but lacks specifics on what that entails operationally, leaving significant 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?
Two concise sentences, front-loaded with the core purpose and complemented by a value statement. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description adequately indicates content (indices, sectors, breadth). However, it could provide a touch more detail on what constitutes 'market breadth'.
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 zero parameters, so schema coverage is 100%. The description adds no parameter details, which is appropriate as none exist. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a comprehensive market overview including indices, sectors, and market breadth. It distinguishes itself from siblings like 'get_market_regime' which focus on a specific aspect, but does not explicitly name 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 implies it is a broad, unrestricted data tool but does not explicitly guide when to use it versus other market analysis tools. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect the current market regime (bull, bear, choppy, or transitional) using SPY price data and a composite multi-factor scoring model.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It states it uses SPY price data and a composite model, but omits details like side effects, data freshness, or permissions. Adequate but not thorough.
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?
Single sentence with no wasted words. Front-loads core purpose and method. Ideal length for a parameterless tool.
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 zero parameters and the presence of an output schema, the description is complete. It tells agents what the tool does, how it works, and what it returns, sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%. Description adds meaning by explaining the tool's output and methodology, exceeding the schema's empty properties.
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?
Description clearly states the tool detects the current market regime with specific outputs (bull, bear, choppy, transitional) using SPY data and a multi-factor model. It distinguishes from sibling tools like 'analyze_market_regimes' which may offer broader analysis.
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 explicit guidance on when to use this tool vs alternatives. It does not mention prerequisites, limitations, or when not to use it, which is a gap given the many related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen for bearish/short setup candidates from S&P 500.
EDUCATIONAL USE ONLY - not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default 20) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states screening and a disclaimer, but does not disclose behavioral traits like being read-only, authorization needs, or rate limits.
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 short (two sentences) and to the point, with no wasted words. However, it lacks a structured front-loading of key information beyond the first sentence.
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 simple input and existence of an output schema, the description adequately informs about the tool's purpose. However, behavioral transparency is lacking, but overall it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'limit' parameter with a description. The tool description does not add any extra meaning beyond the schema, so baseline 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 it screens for bearish/short setup candidates from S&P 500, using specific verb and resource. It distinguishes from sibling tools like get_maverick_stocks which likely screen for bullish setups.
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 explicit guidance on when to use this tool vs alternatives. The description does not mention when not to use or provide context for selection among many screening siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen S&P 500 for bullish momentum setups.
EDUCATIONAL USE ONLY - not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default 20) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It does not disclose any behavioral traits such as whether the tool is read-only, requires authentication, has rate limits, or returns partial results. The description only names the action without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for disclaimer. No unnecessary words. Front-loaded with the core action.
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?
Output schema exists, so return values need not be explained. However, given the tool's complexity (screening stocks), the description lacks context on what 'momentum setups' means or how results are presented. It is minimally complete but leaves 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 one parameter 'limit' is already well-documented in the schema (default 20, integer). The description adds no extra meaning beyond the schema, so baseline 3 applies due to 100% 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 it screens the S&P 500 for bullish momentum setups, which is a specific verb+resource. However, it does not differentiate from the sibling tool 'screening_get_maverick_stocks', which likely has identical functionality.
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 on when to use this tool versus alternatives (e.g., 'get_maverick_bear_stocks' or other screening tools). The only extra statement is a disclaimer about educational use, which does not provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current MCP connection status for debugging connection stability issues.
Returns detailed information about active connections, tool registration status, and connection health metrics to help diagnose disappearing tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses that the tool is read-only and returns detailed information about active connections, tool registration status, and health metrics, setting appropriate expectations for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. The first sentence states the purpose and context, the second expands on returns. Highly efficient.
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 simplicity (no parameters, informational only) and the existence of an output schema, the description provides sufficient context for an agent to understand usage and expected return 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?
With zero parameters and schema coverage at 100%, the description doesn't need to add parameter details. The baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'MCP connection status', and specifies the purpose 'for debugging connection stability issues'. It distinguishes itself from sibling get_* tools by focusing on MCP connection.
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 clear context for when to use the tool ('debugging connection stability issues', 'diagnosing disappearing tools'), but does not explicitly state when not to use it or offer alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all portfolio positions with live P&L calculations.
| Name | Required | Description | Default |
|---|---|---|---|
| include_current_prices | No | Include real-time prices and P&L (default True) |
| Name | Required | Description |
|---|---|---|
No output 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 mentions 'live P&L calculations', implying real-time data, but does not disclose potential latency, rate limits, or whether it requires authentication. The behavioral detail is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and efficient. No unnecessary words or padding. It front-loads the key action and object.
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 low complexity (one optional param, high schema coverage, and an output schema), the description is largely sufficient. It covers the core functionality. The presence of an output schema reduces the need to explain return values. However, with many sibling tools, a bit more context on its specific use case would be beneficial.
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% coverage (one boolean param documented). The description adds 'live P&L calculations', which gives context to the 'include_current_prices' parameter but does not explain the default behavior or what happens when false. Since schema already documents the param, description adds modest value.
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 'Get all portfolio positions with live P&L calculations', using a specific verb and resource. It effectively differentiates from sibling tools like 'add_portfolio_position' and 'remove_portfolio_position' which are for mutation.
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 explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of context, prerequisites, or exclusions. Among many sibling portfolio tools, this would benefit from stating its scope (e.g., fetching vs. analyzing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get news sentiment analysis for a stock.
Uses Tiingo News API or LLM-based analysis with fallback.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| timeframe | No | Time frame for news (1d, 7d, 30d) | 7d |
| limit | No | Maximum number of articles to analyze (default 10) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses fallback mechanism (Tiingo vs LLM), but no annotations are provided. Lacks details on rate limits, latency, cost implications, or behavior on failure. For a tool without annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first states core function, second adds method detail. No filler, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and method, but does not describe return format or how the sentiment is presented. Output schema likely covers this, but the description could briefly mention output nature (e.g., score, label). Still sufficient for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond the schema. It mentions the method context but does not enhance parameter understanding. Baseline 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?
Description clearly states 'Get news sentiment analysis for a stock', specifying verb (get), resource (news sentiment), and target (stock). It also mentions the method (Tiingo News API or LLM with fallback), distinguishing it from siblings like data_get_stock_info or technical tools.
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 explicit guidance on when to use this tool vs alternatives like research_analyze_market_sentiment or data_get_news_sentiment. Does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a full risk dashboard for the named portfolio. Returns total value, sector concentration, parametric VaR (95 and 99 confidence), and total unrealised P&L.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio_name | No | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It states it computes and returns data, implying a read-only operation, but does not disclose authentication needs, performance impact, or whether the portfolio must exist. Adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wordiness. Every sentence adds meaningful information about the tool's output.
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 an output schema and one optional parameter, the description covers the main return metrics. It is fairly complete, though lacking sibling differentiation. The presence of output schema lessens the need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate. The only parameter, portfolio_name, is mentioned as 'named portfolio' in the description but not explained further. The schema provides a default but no description; the tool adds minimal value beyond the parameter name.
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 computes a risk dashboard for a named portfolio, listing specific metrics. It effectively conveys the action and resource, but does not explicitly differentiate from sibling risk tools.
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 on when or when not to use this tool compared to alternatives. With many sibling tools like get_risk_alerts, get_position_risk_check, etc., the description lacks any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-trade risk check: shows how adding a new position would affect portfolio risk. Returns current vs projected metrics including sector concentration and VaR.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| shares | Yes | ||
| entry_price | Yes | ||
| portfolio_name | No | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool 'shows' metrics, implying it is read-only and non-destructive. The 'get' prefix reinforces this. It also discloses what specific metrics are returned (sector concentration, VaR). This is adequate behavioral transparency for a read-side tool, though an explicit 'does not modify' statement would be ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and efficiently convey the tool's function and output. No redundant information. Every sentence serves a clear 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?
The description covers the core purpose and output metrics but omits prerequisites (e.g., does the portfolio need to exist?), the optional portfolio_name parameter's role, and a reference to the output schema. Given the tool's complexity (4 params, output schema present), the description leaves some gaps for the agent to infer.
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 4 parameters (ticker, shares, entry_price, portfolio_name) with 0% description coverage. The description does not explain what each parameter means beyond the tool's overall purpose. While parameter names are somewhat self-explanatory, the description fails to add semantic value such as clarifying that 'shares' is the number of shares to hypothetically add or that 'entry_price' is the assumed purchase price. This lack of guidance forces the agent to rely solely on naming conventions.
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?
Clearly states it's a pre-trade risk check that shows how a new position affects portfolio risk, returning current vs projected metrics like sector concentration and VaR. This specific verb-resource pairing distinguishes it from siblings like add_portfolio_position (which actually adds) and get_portfolio_risk_dashboard (which shows overall risk without hypothetical addition).
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 opens with 'Pre-trade risk check', clearly implying it should be used before adding a position. It provides context for when to use, but does not explicitly mention when not to use or name alternatives among the many sibling tools. However, the purpose is contextually clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate position size adjusted for current market regime. Detects regime from SPY data, then scales risk percentage accordingly: bull = full risk, choppy/transitional = 75%, bear = 50%.
| Name | Required | Description | Default |
|---|---|---|---|
| account_size | Yes | ||
| entry_price | Yes | ||
| stop_loss | Yes | ||
| risk_pct | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: regime detection from SPY data and risk scaling percentages. However, it omits potential failure modes (e.g., if SPY data is unavailable), prerequisites, and whether the scaling is applied to the whole risk or variable percentage.
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 sentence that conveys the essential purpose and behavior with no extraneous words. It is front-loaded with the main action and efficiently packs in the regime detection and scaling rules.
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 complex behavior (regime detection, scaling) and 4 parameters, the description covers the core logic but lacks details on edge cases (e.g., what if regime is unknown?), error messages, or data dependencies (e.g., SPY data availability). Since an output schema exists, return values are less critical, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not define any of the four parameters (account_size, entry_price, stop_loss, risk_pct). The description mentions 'risk percentage' but does not clarify its relationship to the parameters. This is insufficient for correct parameter usage.
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: calculating position size adjusted for market regime. It specifies the action ('Calculate position size'), the resource ('current market regime'), and distinguishes itself from sibling tools like 'get_market_regime' by integrating regime detection with scaling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for regime-aware sizing) and provides scaling factors (bull=100%, choppy/transitional=75%, bear=50%). However, it does not explicitly state when not to use this tool or mention alternatives such as 'get_position_risk_check' for non-regime-based sizing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve recorded market regime events from the database.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states a basic retrieval operation, omitting details like read-only nature, potential pagination, or response format.
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, concise sentence. It is front-loaded with core intent, but lacks detail. While efficient, it sacrifices 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 parameter description and annotations, the description is too sparse. It does not explain the tool's behavior regarding the 'days' parameter, ordering, or output format, making it inadequate 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?
The single parameter 'days' has no description in the schema (0% coverage). The tool description does not explain what 'days' controls (e.g., lookback period from today), so the agent has no semantic guidance.
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 'Retrieve', the resource 'recorded market regime events', and the source 'from the database'. It effectively differentiates from siblings like 'get_market_regime' (current regime) and 'analyze_market_regimes' (analysis).
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 offers no guidance on when to use this tool versus alternatives, no prerequisites, nor when not to use it. The agent must 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 current system resource usage.
Returns information about CPU, memory, disk usage, and other system resources being consumed by the backtesting system.
Returns: Dictionary containing resource usage information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 fails to mention any traits like read-only nature, impact on system, rate limits, or cost, leaving the agent without essential 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: two short sentences plus a return type line. It is front-loaded with the core purpose, immediately followed by relevant details. Every word contributes value 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 no parameters, the presence of an output schema, and the tool's simplicity, the description fully covers what the tool does. It specifies the resource types and system context, and the output schema handles the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema has 100% coverage. The description does not add parameter meaning, but the baseline for 0 parameters is 4, and the description's mention of return content suffices for this simple case.
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 returns current system resource usage (CPU, memory, disk) for the backtesting system. The verb 'Get' combined with the specific resource makes the purpose unambiguous and distinguishes it from sibling tools that focus on other aspects like health or performance.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks information on prerequisites, when not to use it, or comparisons to other monitoring tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate current risk alerts for the named portfolio. Checks for sector concentration (>30% warning, >50% critical), oversized positions (>20%), and portfolio drawdown (>10% loss).
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio_name | No | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses specific behavioral thresholds (e.g., >30% sector concentration warning), adding useful context beyond the schema. However, it could mention read-only nature or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and specifics, with no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter with a default and an existing output schema, the description covers the core behavior well. It could mention the response format briefly, but the output schema likely fills that gap.
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 only parameter, portfolio_name, has no description in the schema (0% coverage). The tool description does not explain what the parameter expects (e.g., valid portfolio names) beyond the default value, leaving ambiguity.
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 generates risk alerts for a named portfolio and specifies three specific checks with thresholds, making its purpose distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for portfolio risk assessment but provides no explicit guidance on when to use this tool versus alternatives like get_portfolio_risk_dashboard or get_position_risk_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get RSI analysis with overbought/oversold signals.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol (e.g. 'AAPL') | |
| period | No | RSI period (default 14) | |
| days | No | Number of days of historical data (default 365) |
| Name | Required | Description |
|---|---|---|
No output 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. The description only states what the tool does, without revealing any behavioral traits such as side effects, permissions, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is efficient, though it could briefly mention key parameters or output without becoming verbose.
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 technical analysis tool, the description lacks important context about output format, overbought/oversold thresholds, and how parameters affect the analysis. An output schema exists but its details are not provided, leaving 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?
Schema description coverage is 100%, with clear descriptions for each parameter. The description adds no extra meaning beyond what is already in the schema, so baseline 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 the resource 'RSI analysis', and adds the specific outcome 'overbought/oversold signals'. However, it does not differentiate from the sibling tool 'technical_get_rsi_analysis', which appears to serve the same purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or explicit context for using RSI analysis over other indicators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent screening changes (symbol entries and exits). Optionally filter by screen_name. Returns up to limit changes, ordered newest-first.
| Name | Required | Description | Default |
|---|---|---|---|
| screen_name | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions ordering and limit but, due to no annotations, fails to explicitly state read-only nature or other behavioral traits such as no side effects or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with no redundant words, front-loaded with 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?
For a two-parameter tool with an output schema, the description adequately covers what the tool does, though more detail on output fields could be added.
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?
Adds basic meaning to parameters: screen_name is a filter, limit controls maximum results. However, no details on acceptable values or examples, and schema coverage is 0%.
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 gets recent screening changes specifically symbol entries and exits, and distinguishes it from siblings like get_screening_history and get_all_screening_recommendations by focusing on changes.
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?
Implies usage for fetching recent changes with optional filters but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get screening run history for a specific symbol — showing each run in which the symbol appeared. Optionally filter by screen_name.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| screen_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states what it does (shows runs) but omits details like read-only nature, pagination, ordering, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and optional filter, though a bit more structure could help.
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 only 2 parameters and an output schema exists, the description covers the purpose and optional filter but lacks details like output format or any caveats, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that 'symbol' is required and 'screen_name' is optional for filtering, but doesn't explain the format or constraints of these parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get screening run history' and resource 'for a specific symbol', clearly distinguishing it from sibling tools like 'get_all_screening_recommendations' or 'get_screening_changes' which focus on different aspects of screening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking history of a symbol with optional screen name filter, but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return overall status of the screening pipeline — latest run per screen, result counts, and any configured scheduled jobs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output 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 indicates a read operation ('Return overall status'), but does not disclose any potential side effects, prerequisites, performance impact, or caching behavior. Adequate but minimal.
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 sentence that is front-loaded and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description sufficiently covers what the tool returns. It is complete for a simple status-retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds meaningful context by listing what the status includes (latest run, result counts, scheduled jobs), which is valuable given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the overall status of the screening pipeline, including latest run per screen, result counts, and scheduled jobs. This is specific and distinguishes it from siblings like get_screening_changes or get_screening_history.
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 does not provide explicit guidance on when to use this tool versus alternatives like get_screening_changes or schedule_screening. It only implies its use for overall status, missing explicit when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive status dashboard data.
Returns aggregated health status, performance metrics, alerts, and historical trends for the entire backtesting system.
Returns: Dictionary containing complete dashboard information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only lists returned data without mentioning side effects, authentication needs, rate limits, or performance impact. The minimal description does not adequately inform an agent about potential costs or restrictions.
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 short and front-loaded with the purpose, but the final line about returning a dictionary is somewhat redundant with the second sentence. Slight repetition, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter dashboard retrieval tool with an output schema, the description adequately outlines the scope (comprehensive dashboard data). It could mention whether the data is real-time or cached, but the output schema likely covers structure, so this is acceptable.
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 zero parameters, so the description adds no parameter details. Schema coverage is 100% (trivially), and the baseline for 0 parameters is 4. The description correctly avoids redundant parameter information.
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 retrieves comprehensive status dashboard data for the entire backtesting system, including health, performance, alerts, and trends. This differentiates it from more specific tools like get_component_status or get_system_health, though it could be more explicit about distinctions.
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 siblings such as get_system_health, get_component_status, or get_health_history. The description lacks usage context, which is a significant gap given the large number of overlapping 'get' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fundamental data: market cap, P/E ratio, sector, industry, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol |
| Name | Required | Description |
|---|---|---|
No output 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 only mentions data retrieval and does not disclose potential behaviors like error handling for invalid tickers, rate limits, or whether it's purely read-only. The description is too minimal for a tool with no other 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 a single sentence of 10 words, highly concise with no filler. It front-loads the purpose. However, it could be slightly expanded to include basic behavioral context without harming 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?
With an output schema present, the description need not explain return values. The tool is simple (1 required param, no enums), so the description plus schema cover the basics. However, missing usage guidelines and behavioral transparency reduce 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?
Schema description coverage is 100%, with a clear description for the single parameter 'ticker'. The description adds value by hinting at the output specifics (e.g., market cap, P/E ratio), but does not enhance parameter meaning beyond the schema. Baseline 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 the resource 'fundamental data' with specific examples (market cap, P/E ratio, sector, industry). It distinguishes from other data-fetching tools like data_fetch_stock_data by focusing on fundamental metrics, though it doesn't explicitly differentiate from the sibling 'data_get_stock_info'.
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 on when to use this tool versus alternatives. The description only states what it does, with no mention of prerequisites, when-not-to-use, or comparisons to similar tools like data_fetch_stock_data or data_get_stock_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare all strategies ranked by expectancy (highest first). Shows win/loss counts, total PnL, and key metrics for each strategy tag.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read-only query (no parameters, no destructive language). It does not disclose any behavioral traits beyond the obvious, but does not contradict any expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded with the main action ('Compare all strategies ranked by expectancy') followed by what it shows. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema exists, the description sufficiently explains what the tool does. It could mention if it includes all strategy tags or only active ones, but overall complete for its simplicity.
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 zero parameters, the baseline is 4. The description adds value by explaining the output (metrics and ranking) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it compares all strategies ranked by expectancy, and lists the metrics shown (win/loss counts, total PnL, key metrics). This distinguishes it from siblings like get_strategy_performance (individual strategy) or list_all_strategies (just listing).
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 on when to use this tool vs alternatives like compare_strategies or get_strategy_performance. The description does not specify prerequisites or when it is appropriate to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed help for a specific strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_type | Yes | Name of the strategy (e.g., 'sma_cross', 'online_learning') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only implies a read operation ('get detailed help') but omits details such as idempotency, side effects, authentication requirements, or rate limits. This minimal transparency burdens the agent.
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 sentence of six words, perfectly concise and front-loaded with the verb and resource. No wasted text.
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 simple single-parameter schema and presence of an output schema, the description is minimally adequate. However, it lacks details on what 'help' entails (e.g., text explanation, structure), which might be clarified by the output schema but is not evident here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema's description of 'strategy_type' is adequate ('Name of the strategy...'). The tool description adds no extra meaning beyond the schema, so it meets the baseline but provides no additional semantic enrichment.
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 detailed help for a specific strategy' clearly specifies the action (get) and the resource (help for a strategy). It distinguishes itself from siblings like list_strategies (which lists strategies) and get_strategy_performance (which retrieves performance data), making the tool's role unambiguous.
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 prerequisites, when-not-to-use, or reference sibling tools like list_strategies or get_strategy_performance, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return aggregated performance metrics for a strategy tag: win/loss count, total PnL, average win/loss, expectancy, and profit factor. Metrics are based on all closed trades tagged with this strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| strategy_tag | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses metrics come from closed trades, implying a read-only operation, but lacks details on permissions, caching, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no wasted words. Highly concise and structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description lists the computed metrics and data source, making it fairly complete. Lacks mention of time range or calculation specifics, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds context by linking the parameter 'strategy_tag' to trades tagged with that strategy. However, it does not specify format, allowed values, or constraints.
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 returns aggregated performance metrics (win/loss count, total PnL, etc.) for a strategy tag, using closed trades. This specific verb and resource list distinguishes it from sibling tools like compare_strategies or list_all_strategies.
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 on when to use this tool vs alternatives (e.g., compare_strategies for comparisons). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen for accumulation/breakout patterns in S&P 500.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default 20) | |
| filter_moving_averages | No | Only show stocks above key moving averages (default False) |
| Name | Required | Description |
|---|---|---|
No output 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 does not disclose any behavioral traits (e.g., read-only, rate limits, output nature) beyond the minimal screening statement.
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?
Extremely concise (one sentence) but lacks structure and depth. While it is short, it sacrifices informative content, which reduces overall value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what accumulation/breakout patterns entail or how the tool works. Given the complexity of screening, this minimal description is incomplete.
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?
Both parameters are well-described in the schema (100% coverage), so the description adds no extra meaning. Baseline 3 applies as schema does the heavy lifting, but no additional context is provided.
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 screens for accumulation/breakout patterns in the S&P 500, with a specific verb and resource. However, it does not differentiate from sibling screening tools like get_all_screening_recommendations or get_maverick_stocks, leaving ambiguity.
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 on when to use this tool versus alternatives. The description does not provide context, prerequisites, or exclusions, which is insufficient given the many sibling screening tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get key support and resistance price levels.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| days | No | Number of days of historical data to analyze (default 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the purpose. It fails to disclose that the tool is read-only, requires no specific permissions, or how it computes levels from historical 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, clear sentence with no redundant words, achieving maximum 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 an output schema exists, return values need not be explained. However, the minimal description lacks context on what constitutes 'key' levels or that it uses historical data, which could help distinguish from 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?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's param descriptions for 'ticker' and 'days'.
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 key support and resistance price levels' uses a specific verb ('Get') and resource ('support and resistance price levels'), clearly distinguishing it from siblings like get_macd_analysis or get_rsi_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like get_supply_demand_breakouts or other technical analysis tools, and lacks any when-not or contextual hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive system health status.
Returns detailed information about all system components including:
Overall health status
Component-by-component status
Resource utilization
Circuit breaker states
Performance metrics
Returns: Dictionary containing complete system health information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It lists what information is returned (health status, circuit breaker states, etc.), but does not disclose side effects, permissions, rate limits, or any other behavioral traits. Minimal disclosure beyond return content.
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 paragraph with bullet points but includes a redundant 'Returns:' line. It is adequately concise but could be shorter by merging the bullet points and the return statement.
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 zero parameters and the existence of an output schema (which documents return value structure), the description provides a good overview of the information categories returned. It is complete enough for the tool's simplicity, though it could mention that it aggregates data from other health 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?
There are zero parameters and schema coverage is 100%. As per guidelines, baseline for 0 parameters is 4. The description does not need to add parameter info, and it does not.
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 retrieves comprehensive system health status, using a specific verb and resource. It lists covered components, but does not explicitly differentiate from sibling tools like get_component_status or get_circuit_breaker_status.
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 the many more specific health-related sibling tools (e.g., get_component_status, get_resource_usage). No when-to-use, when-not-to-use, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get tool registry status including rate limits and available tool categories.
Returns current rate limit usage and configuration for every tool category. Useful for monitoring tool availability and diagnosing rate-limit issues.
Returns: Dictionary with rate_limits (current usage) and tool_categories (config).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains that the tool returns a dictionary with 'rate_limits' and 'tool_categories', which is good. However, it does not disclose whether the data is cached, how recent it is, or any side effects (though likely none). The description is adequate but not thorough.
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 three short sentences/paragraphs, totaling about 40 words. It front-loads the purpose and adds usage and return info without fluff. It could be slightly more streamlined (e.g., merging the first two lines), but it is still concise.
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 parameters and the presence of an output schema (not shown but assumed), the description adequately covers what the tool returns and when to use it. It doesn't address error conditions or authentication, but for a simple status tool, this is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema (0 params), so schema coverage is effectively 100%. The description naturally adds no parameter specifics. According to guidelines, 0 parameters yields a baseline of 4, which 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 'Get tool registry status including rate limits and available tool categories.' This directly tells the agent the verb (Get) and resource (tool registry status), and it distinguishes itself from sibling status tools like get_system_health or get_resource_usage by being specific to the tool registry.
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 states 'Useful for monitoring tool availability and diagnosing rate-limit issues.' This gives clear context for when to use it. However, it does not mention when not to use it or provide explicit alternatives among the many sibling tools, so it misses some exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming catalyst events (earnings, ex-dividend, FDA decisions, etc.) within a given number of days from today. Optionally filter to a specific list of ticker symbols.
| Name | Required | Description | Default |
|---|---|---|---|
| symbols | No | ||
| days_ahead | No |
| Name | Required | Description |
|---|---|---|
No output 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 reveals the tool is a read-only list operation, but lacks details on data source, caching, pagination, or rate limits. However, it sufficiently indicates non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences covering purpose and parameters. Every word earns its place; no 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 an output schema exists, the description adequately covers core usage. It could mention the maximum allowed days or data source, but for a simple list tool it is sufficiently complete.
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% schema description coverage, the description adds meaning for both parameters: 'symbols' as optional ticker filter and 'days_ahead' as the time horizon. It clarifies the purpose beyond the raw schema, though it could be more explicit about parameter formats.
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 lists upcoming catalyst events such as earnings, ex-dividends, and FDA decisions, with a specific timeframe and optional ticker filter. It uses a specific verb ('list') and resource ('catalyst events'), and the examples differentiate it from siblings like 'get_economic_calendar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving catalyst events within a time range but does not explicitly state when to use this tool over alternatives like 'get_economic_calendar' or provide when-not-to-use guidance. No exclusions or preconditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get basic portfolio summary and stock analysis capabilities.
Returns available features and sample stock data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only states 'Returns available features and sample stock data' – no mention of read-only nature, side effects, authentication, or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, short, but the first sentence is unclear and combines two ideas. Could be more direct and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return format, but it fails to explain what 'available features' means or how the tool fits into a workflow. Incomplete for a capabilities summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters defined; baseline is 4 for zero-parameter tools. Description adds no parameter info, but none is needed.
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?
Description states 'Get basic portfolio summary and stock analysis capabilities' which is a verb+resource, but the phrase 'stock analysis capabilities' is vague and does not clearly differentiate from many sibling tools like get_my_portfolio, portfolio_get_my_portfolio, or capabilities discovery tools.
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 on when to use this tool versus alternatives. Does not mention prerequisites, when-not-to-use, or suggest other tools for more specific portfolio data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get sample watchlist with real-time stock data.
Provides stock data for popular tickers to demonstrate functionality.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It indicates a read operation for a sample watchlist, but omits details like whether the data is cached, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose. No wasted words, though the second sentence is slightly redundant.
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 simple parameter and presence of an output schema, the description is adequate but does not clarify that the watchlist is a fixed set of 'popular tickers' rather than user-defined, which could be important 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 only parameter 'limit' is not mentioned in the description, and the schema has 0% coverage. The description adds no meaning beyond the schema's default and type.
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 ('sample watchlist'), and distinguishes it as a demonstration tool rather than a user-specific watchlist, which differentiates it from sibling watchlist tools like watchlist_add or watchlist_create.
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 (e.g., watchlist_brief for personal watchlists). It does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an open trade to the journal. Record the symbol, side (long/short), entry price, and number of shares. Optionally include a rationale, strategy tags, and notes. Entry date defaults to now.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | ||
| side | Yes | ||
| entry_price | Yes | ||
| shares | Yes | ||
| rationale | No | ||
| tags | No | ||
| notes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions default entry date to 'now' but does not explain validation, side effects, error handling, or return values. The output schema is not referenced.
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: two sentences. The first sentence clearly states the action and required parameters, and the second adds optional fields and a default behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, 0% coverage, no annotations, many siblings), the description is adequate but incomplete. It covers core functionality but lacks usage guidance, behavioral details, and output information. Context signals indicate a need for more depth.
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% schema description coverage, the description should compensate. It lists the required and optional parameters and specifies that side is 'long/short', adding meaning beyond the schema. However, it does not explain formats for symbol, entry_price, or shares beyond their listing.
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: 'Add an open trade to the journal.' It lists the required fields (symbol, side, entry price, shares) and optional ones, distinguishing it from siblings like journal_close_trade and journal_list_trades.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for recording new open trades but does not explicitly state when to use it versus alternatives (e.g., journal_close_trade). No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close an existing open trade by entry ID. Provide the exit price; exit date defaults to now. PnL is automatically computed (long: exit-entry, short: entry-exit). Strategy performance metrics are recomputed for all tags on this trade.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes | ||
| exit_price | Yes | ||
| notes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses exit date defaults to now, automatic PnL computation with clear formulas for long/short, and strategy performance recalc for all tags. No annotations exist, so description provides necessary 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?
Two sentences, each conveying essential information: purpose/defaults and side effects. No 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?
With output schema present, description adequately covers behavior and side effects. Could mention that entry_id must reference an open trade, but minimal gap given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description explains exit_price meaning and default for exit date, but does not describe entry_id or notes parameter. Adds PnL formula context but lacks full parameter descriptions.
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?
Clearly states the tool closes an open trade by entry ID, distinguishing it from siblings like journal_add_trade (adds a trade) and journal_list_trades (lists trades). The verb 'close' and resource 'trade' are specific.
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?
Implies usage is for closing open trades when exit price is available, but lacks explicit when-not-to-use or alternatives. No comparison with sibling tools like journal_trade_review.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List trades from the journal. Optionally filter by symbol, status (open/closed), or strategy tag. Returns up to limit trades (default 50), newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | ||
| status | No | ||
| strategy_tag | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It specifies read-only behavior, sorting (newest first), and default limit, but does not mention pagination, valid status values explicitly, or error handling. Some gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key information: purpose, filters, and ordering. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core usage and filtering, but could mention that it returns all matching trades up to limit, and that output schema exists. Missing pagination details, but acceptable for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining each parameter's purpose (filter by symbol, status, strategy tag) and default behavior (limit defaults to 50). This compensates well.
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 (List), the resource (trades from the journal), and provides filtering and ordering details, distinguishing it from siblings like journal_add_trade and journal_close_trade.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to list trades) but lacks explicit comparison to other list tools or guidance on when not to use it. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return full details for a trade entry by ID, including all computed metrics. Shows entry/exit prices, PnL, tags, rationale, and notes.
| Name | Required | Description | Default |
|---|---|---|---|
| entry_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 traits. It implies a read-only operation ('Return full details') but does not explicitly state that it is non-destructive, require no authentication, or describe any side effects. Lacks details on data freshness, rate limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core action and scope, the second enumerates returned metrics. No filler, information is front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema (presumably detailing return structure), the description covers purpose, input, and output. It lacks usage guidelines and explicit behavioral transparency, but is otherwise complete for basic functionality.
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 provides only an 'entry_id' integer parameter with no description. The tool description adds meaning by stating 'by ID' and listing the returned fields, clarifying what the parameter represents and what the response includes. This compensates for the 0% schema description 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 verb 'Return', the resource 'trade entry by ID', and specifies the scope 'full details including all computed metrics'. It lists specific fields (entry/exit prices, PnL, tags, rationale, notes) which distinguishes it from sibling tools like journal_list_trades that likely provide only summaries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single trade's details, but does not provide explicit guidance on when to use this tool versus siblings like journal_list_trades, journal_add_trade, or journal_close_trade. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available backtesting strategies with their parameters.
Returns detailed information about each strategy including:
Strategy name and description
Required and optional parameters
Default parameter values
Example usage
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool returns detailed information about strategies including name, description, parameters, defaults, and examples. It is transparent about the read-only nature and return content, though it does not mention potential performance implications for large lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses bullet points for clarity. Every sentence adds value 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 no required parameters and an output schema that likely details the return structure, the description is largely complete. It could improve by noting that the tool is safe and idempotent, but it sufficiently covers the tool's functionality.
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 no parameters, so schema coverage is 100% by nature. The description adds value by explaining what the output contains (parameter info, defaults, etc.), which is relevant beyond the empty input schema. Per guidelines, 0-parameter tools baseline at 4.
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 lists all available backtesting strategies with their parameters, using a specific verb and resource. It distinguishes from sibling tools like 'get_strategy_help' by focusing on listing all strategies rather than providing help on a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing strategies but provides no explicit guidance on when to use this tool versus alternatives like 'get_strategy_help' or 'compare_strategies'. It lacks 'when to use' and 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured signals, optionally filtering to active-only.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It indicates a read operation ('list') but does not disclose behavioral traits such as whether 'active' status is defined, pagination, or any side effects. Output schema helps but description could add more 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 a single concise sentence of 10 words with no wasted information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one optional parameter and an output schema, the description is sufficiently complete for an agent to understand its basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains the sole parameter 'active_only' by stating 'optionally filtering to active-only,' which adds meaning beyond the schema's boolean type and default value.
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 lists all configured signals with an optional filter. The verb 'list' and resource 'signals' are specific, and it distinguishes from sibling tools like create, delete, update, and check signals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing signals but lacks explicit guidance on when to use this tool versus alternatives like check_signals_now or other query tools. No when-not or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available VectorBT strategies with descriptions.
Returns: Dictionary of available strategies and their information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it returns a dictionary of strategies and their information, implying a read operation, but it does not explicitly state side effects, permissions, or performance characteristics. With no annotations, this is adequate but minimal.
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 two sentences: the first states the action, the second clarifies the return type. No extraneous words, front-loaded, and efficient.
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 simplicity (no parameters, no complexity) and the presence of an output schema, the description is sufficient. It covers what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details, but it is not required.
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 'List all available VectorBT strategies with descriptions', which specifies the verb and resource. However, it does not differentiate from the sibling tool 'list_all_strategies', which appears to have identical functionality.
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 like 'list_all_strategies' or other strategy-related tools. No context about prerequisites or limitations is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Monte Carlo simulation on backtest results.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol | |
| strategy | No | Strategy type | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| num_simulations | No | Number of Monte Carlo simulations | |
| fast_period | No | ||
| slow_period | No | ||
| period | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior, but it only states the action. It does not mention whether the tool mutates state, requires specific permissions, or what the output contains (despite an output schema existing). Key behavioral traits like simulation assumptions or performance implications are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is efficient, but it omits essential details that could have been included without verbosity. Front-loading is fine, but the content is too sparse to be fully useful.
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 (8 parameters, output schema) and the rich sibling context, the description fails to provide enough context. It does not explain what the simulation does with backtest results, how to interpret results, or how it relates to other analysis 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?
With 63% schema coverage, the description adds no parameter-level information. It does not explain how parameters like symbol, strategy, or num_simulations relate to the simulation, nor does it compensate for parameters lacking schema descriptions (e.g., fast_period, slow_period).
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 runs a Monte Carlo simulation on backtest results, using a specific verb ('Run') and resource ('Monte Carlo simulation on backtest results'). It distinguishes from sibling backtesting tools by focusing on simulation rather than backtest execution, though it could be more specific about the inputs and outputs.
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 like backtest_portfolio or walk_forward_analysis. The description does not mention prerequisites (e.g., having prior backtest results) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Optimize strategy parameters using VectorBT grid search.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to optimize | |
| strategy | No | Strategy type to optimize | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| optimization_metric | No | Metric to optimize (sharpe_ratio, total_return, win_rate, etc.) | sharpe_ratio |
| optimization_level | No | Level of optimization (coarse, medium, fine) | medium |
| top_n | No | Number of top results to return |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the optimization method (grid search) but does not disclose side effects (e.g., does it modify anything?), computational intensity, or whether it requires pre-fetched data. Critical behavioral context is missing.
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 sentence that directly states the core functionality. It is concise without being overly brief, though it could include a bit more context 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 the tool's complexity (7 parameters, grid search optimization), the description is minimal. It does not explain what the output contains (though output schema exists), potential runtime, or how results are used. This is insufficient for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and parameter descriptions in the schema are clear. The description adds no extra meaning beyond the schema; it merely summarizes the action. Baseline score of 3 is appropriate when schema descriptions are complete.
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: optimizing strategy parameters using VectorBT grid search. The verb 'optimize' and resource 'strategy parameters' are specific, and the method 'VectorBT grid search' distinguishes it from other backtesting or optimization tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parameter optimization but lacks explicit guidance on when to use this tool versus alternatives like walk_forward_analysis, backtest_signal, or run_ml_strategy_backtest. No 'when not to use' or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse natural language strategy description into VectorBT parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | Natural language description of trading strategy |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes input and output but does not disclose side effects or constraints (e.g., no mutation, format requirements). Adequate but minimal.
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?
Single sentence of 8 words, extremely concise, directly states purpose with no superfluous content. Front-loaded and efficient.
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 simplicity (single parameter) and the existence of an output schema, the description adequately covers the transformation from natural language to VectorBT parameters. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds slight context ('into VectorBT parameters') but largely restates the schema's parameter description. Baseline 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 'Parse natural language strategy description into VectorBT parameters.' clearly states the specific verb (parse) and resource (strategy description), and effectively distinguishes it from sibling tools like 'create_strategy_ensemble' or 'compare_strategies'.
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 explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for converting natural language strategies, but does not mention alternatives or exclusions among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze database index usage and provide optimization recommendations.
This tool examines database index usage statistics, identifies missing indexes, analyzes table scan patterns, and provides specific recommendations for database performance optimization. Use this for database tuning.
Returns: Database index analysis and optimization recommendations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It discloses that the tool examines statistics, identifies missing indexes, and analyzes patterns, but does not clarify if it is read-only or if any modifications occur. The description is adequate but not explicit about side effects.
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 four sentences and includes a 'Returns:' line that may be redundant given the output schema. It could be more concise by removing the returns description.
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 simplicity (no parameters, output schema exists), the description covers what the tool does and its purpose. It lacks details on error handling or prerequisites, but overall it is sufficiently complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description does not need to explain parameters. Baseline for zero parameters is 4, which 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 tool's verb ('analyze'), resource ('database index usage'), and outcome ('optimization recommendations'). It distinguishes itself from sibling tools like performance_get_database_performance_status by focusing specifically on index usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case ('Use this for database tuning') but does not specify when not to use it or mention alternative tools. It lacks explicit guidance on exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear specific performance caches for maintenance or testing.
This tool allows selective clearing of different cache types:
stock_data: Stock price and company information caches
screening: Maverick and trending stock screening caches
market_data: High volume and market analysis caches
all: Clear all performance caches
Use this for cache maintenance, testing, or when stale data is suspected.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Cache clearing request with specific cache types |
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks annotations, so the full burden falls on the text. It conveys the destructive nature ('clear') and lists cache types, but does not disclose potential side effects (e.g., performance impact during clearance), required permissions, or rate limits. The behavioral description is adequate but shallow.
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 very concise, using bullet points for cache types and a short usage sentence. Every sentence adds value, and the structure is front-loaded with the action and followed by details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (clearing caches) and the presence of an output schema for return values, the description covers the essential aspects: what caches can be cleared and when to use it. It lacks details on side effects or prerequisites, but is otherwise complete for a maintenance tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with a single nested parameter 'cache_types'. The description adds meaning by explaining each cache type (stock_data, screening, etc.) and their purpose, going beyond the schema's minimal description. This helps the agent understand what each type represents.
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: clearing specific performance caches. It lists the cache types in a structured manner, distinguishing it from sibling tools like performance_get_cache_performance_status which are for status checking. The verb 'clear' is specific and the resource is well-defined.
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 explicit usage context: 'Use this for cache maintenance, testing, or when stale data is suspected.' This guides the agent on when to invoke the tool. However, it does not mention when NOT to use it or suggest alternative tools for related tasks, which would enhance clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cache performance metrics and optimization suggestions.
This tool provides cache hit/miss ratios, operation latencies, Redis memory usage, and performance test results. Use this to optimize caching strategies and identify cache bottlenecks.
Returns: Cache performance metrics and test results
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes what metrics are returned but does not state whether the tool is read-only or has side effects. No annotations provided to fill the gap, leaving behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs plus a returns line, each sentence serving a purpose: stating purpose, detailing metrics, suggesting use, and listing output structure. No fluff.
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 parameters and an output schema, the description covers the essential context: what metrics are provided and why to use it. Minor gap: no mention of prerequisites or cache scope.
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?
Tool has no parameters (schema coverage 100%), so the description adds value by explaining the output metrics, which helps the agent understand what to expect beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides cache performance metrics and optimization suggestions, but does not explicitly differentiate from sibling tools like performance_get_database_performance_status or performance_get_redis_health_status beyond naming.
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?
Provides a use case ('to optimize caching strategies and identify cache bottlenecks') but lacks explicit when-not-to-use guidance or comparison to alternative performance tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get database query performance metrics and connection pool status.
This tool provides database query statistics, slow query detection, connection pool metrics, and database health tests. Use this to identify database performance bottlenecks and optimization opportunities.
Returns: Database performance metrics and query statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It discloses that the tool retrieves metrics but does not mention any potential limitations, rate limits, or permissions. For a read-only monitoring tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs. It front-loads the purpose and lists key deliverables. The 'Returns:' line is slightly redundant but adds clarity. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately covers what the tool does and what it returns. It mentions query statistics, slow queries, connection pool, and health tests, which is sufficient for this 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 tool has zero parameters, so the baseline score is 4. The description adds no parameter information, which is appropriate since there are none.
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 uses a specific verb 'Get' and resource 'database query performance metrics and connection pool status'. It clearly distinguishes from siblings like 'performance_analyze_database_index_usage' and 'performance_get_cache_performance_status' by focusing on database performance 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 states 'Use this to identify database performance bottlenecks and optimization opportunities', providing clear context. It does not explicitly list alternatives or when not to use, but given the sibling tools, the usage is sufficiently clear for a zero-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Redis connection pool health and performance metrics.
This tool provides detailed information about Redis connectivity, connection pool status, operation latency, and basic health tests. Use this when diagnosing Redis-related performance issues.
Returns: Redis health status and connection metrics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses it provides connectivity, pool status, latency, and health tests as read-only information. No contradictions.
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?
Very concise: three short paragraphs that front-load the purpose, usage, and return value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a zero-parameter health check tool: explains what it does, when to use it, and what it returns. Output schema exists but description also summarizes return content.
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?
No parameters in schema, so description is not required to add parameter details. Baseline of 4 applies, and description adds no unnecessary information.
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 retrieves Redis connection pool health and performance metrics, distinguishing it from sibling performance tools like performance_get_cache_performance_status or performance_get_database_performance_status.
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?
Explicitly says 'Use this when diagnosing Redis-related performance issues,' providing clear context for when to use. It implies not for other components but does not explicitly list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive system performance health report.
This tool provides an overall health assessment of the MaverickMCP system, including Redis connectivity, cache performance, database query metrics, and index usage analysis. Use this for general system health monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Performance health check request |
| Name | Required | Description |
|---|---|---|
| overall_health_score | Yes | Overall system health score (0-100) |
| component_scores | Yes | Individual component scores |
| recommendations | Yes | Performance improvement recommendations |
| detailed_metrics | Yes | Detailed metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It mentions the report covers Redis, cache, database, index usage but does not disclose side effects, permissions, rate limits, or output structure beyond the 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?
Two sentences, front-loaded with the core purpose, no extraneous information. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's comprehensive nature and presence of output schema, the description provides adequate context for general monitoring. Could include more detail on metric types, but sufficient for 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?
Schema coverage is 100% (both fields described). The description adds no additional meaning beyond the schema, meeting the baseline for high 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 'Get comprehensive system performance health report' and enumerates components (Redis, cache, database, index usage). It distinguishes from sibling tools like performance_get_cache_performance_status by being an overall assessment.
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 says 'Use this for general system health monitoring,' implying usage context but does not explicitly state when to avoid this tool or when to use specific alternatives for focused queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze cache usage patterns and recommend optimal configuration.
This tool analyzes current cache hit rates, memory usage, and access patterns to recommend optimal TTL values, cache sizes, and configuration settings for maximum performance. Use this for cache tuning.
Returns: Cache optimization analysis and recommended settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| metrics | Yes | Performance metrics data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It indicates the tool 'recommends' settings, implying no destructive side effects, but does not explicitly state read-only nature or potential impacts. Lack of explicit safe-operation statement reduces 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 concise: three sentences covering purpose, analysis details, and return value. No unnecessary words, well-structured with clear sections, and front-loaded with key action.
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 parameters and an output schema exists, the description adequately covers the tool's function and return. It details what is analyzed and recommended. Minor gap: no mention of prerequisites (e.g., existing cache usage) or limitations, but overall complete for a zero-param analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%, so the description need not add parameter details. Baseline 3 applies; the description adds no parameter meaning beyond what schema provides, but this is sufficient given no parameters exist.
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 specifies the tool's function: analyzing cache usage patterns (hit rates, memory usage, access patterns) and recommending optimal configuration (TTL, cache sizes, settings). The phrase 'Use this for cache tuning' explicitly identifies its purpose, distinguishing it from siblings like performance_get_cache_performance_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cache tuning but does not explicitly state when not to use it or mention alternative tools (e.g., performance_get_cache_performance_status for monitoring). No exclusions or context for selection among sibling performance tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a stock position to your portfolio.
This tool adds a new position or increases an existing position in your portfolio. If the ticker already exists, it will average the cost basis automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol (e.g., "AAPL", "MSFT") | |
| shares | Yes | Number of shares (supports fractional shares) | |
| purchase_price | Yes | Price per share at purchase | |
| purchase_date | No | Purchase date in YYYY-MM-DD format (defaults to today) | |
| notes | No | Optional notes about this position | |
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior of averaging cost basis when ticker exists, but with no annotations and 7 parameters, more details on side effects or constraints would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs, front-loading the purpose. No unnecessary words, but could be slightly more structured.
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 7 parameters and no annotations, the description covers the core action and averaging but omits details about portfolio existence or return values. Output schema exists, reducing need for return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not elaborate on parameters beyond the schema, offering no additional semantic value.
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 adds a stock position, either new or increasing existing, with automatic cost basis averaging. However, it does not differentiate from the nearly identical sibling 'add_portfolio_position'.
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 context on when to use (adding positions) and the averaging behavior, but lacks guidance on when not to use or alternatives like removing and re-adding for a different cost basis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear all positions from your portfolio.
CAUTION: This removes all positions from the specified portfolio. This action cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| confirm | No | Must be True to confirm deletion (safety check) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the destructive nature and irreversibility ('This action cannot be undone'). It adds context about removing all positions from the specified portfolio, though it does not mention the confirm parameter requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with efficient wording and a clear caution format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and warning. It omits the requirement for the confirm flag, but the output schema exists and the tool is simple. A minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameters are fully described in the schema. The description adds no extra meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Clear all positions from your portfolio,' which is a specific verb (clear) and resource (positions in portfolio). It distinguishes from siblings like remove_portfolio_position which likely removes a single position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for clearing all positions with a caution about irreversibility, but does not explicitly provide when-to-use or when-not-to-use guidance or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare multiple tickers using technical and fundamental metrics.
This tool provides side-by-side comparison of stocks including:
Price performance
Technical indicators (RSI, trend strength)
Volume characteristics
Momentum strength ratings
Risk metrics
Portfolio Integration: If no tickers are provided, automatically compares all positions in your portfolio, making it easy to see which holdings are performing best.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | No | List of ticker symbols to compare (minimum 2). If None, uses portfolio holdings. | |
| days | No | Number of days of historical data to analyze (default: 90) | |
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output 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 discloses what metrics are compared but does not mention side effects, permissions, or whether it is read-only. The tool likely does not modify data, but that is not stated, limiting 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?
Description is concise and well-structured with bullet points, making it easy to scan. Every sentence adds information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description focuses on input and behavior. It covers all key aspects: what is compared, the metrics, and the portfolio fallback. No gaps identified.
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?
All 4 parameters have schema descriptions (100% coverage). The description reinforces the behavior of the tickers parameter (null uses portfolio). This adds some value, but the schema already conveys this information.
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 compares multiple tickers using technical and fundamental metrics, and lists specific categories (price performance, RSI, etc.). It distinguishes from siblings like compare_tickers by highlighting portfolio integration.
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?
Provides clear guidance: if no tickers provided, automatically uses portfolio holdings. This tells the agent when to use it (for portfolio overview or specific ticker comparisons). However, it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze correlation between all portfolio holdings.
Auto-detects your portfolio positions. No need to specify tickers.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of trading days for correlation window (default 252 = ~1 year) |
| Name | Required | Description |
|---|---|---|
No output 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 states 'auto-detects your portfolio positions' (a key behavior) but does not disclose auth needs, side effects, or output format. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, then usage clarification. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown but indicated), the description needs only to cover basic behavior. It does so adequately for a simple tool, though could elaborate on the nature of the correlation analysis (e.g., pairwise matrix).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'days' fully described. The description adds no extra meaning beyond the schema. Baseline 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 'analyze correlation' and resource 'all portfolio holdings'. It further distinguishes from siblings by emphasizing auto-detection and no need to specify tickers, setting it apart from tools like portfolio_compare_tickers or portfolio_risk_adjusted_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when correlation analysis of the entire portfolio is desired. It does not explicitly state when not to use it (e.g., for subset analysis) or mention alternatives, but given the simplicity, the implied guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your complete portfolio with all positions and performance metrics.
This tool retrieves your entire portfolio including:
All stock positions with cost basis
Current market values (if prices available)
Profit/loss for each position
Portfolio-wide performance metrics
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| include_current_prices | No | Whether to fetch live prices for P&L (default: True) |
| Name | Required | Description |
|---|---|---|
No output 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 key behaviors (returns positions, cost basis, market values if available, P&L, performance metrics) but does not disclose whether it reads only, requires authentication, or has any side effects. The 'if prices available' caveat is helpful.
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 relatively concise at about 80 words, split into two paragraphs. It front-loads the purpose and uses bullet points for clarity. Some minor redundancy could be trimmed, but overall efficient.
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 presence of an output schema and the tool's low complexity (3 optional parameters), the description is reasonably complete. It covers the main data returned. However, it could mention any limits on length or performance implications of fetching live prices.
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?
All three parameters have descriptions in the input schema (100% coverage). The description adds no additional parameter-specific meaning beyond what the schema already provides, so baseline 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 tool retrieves a complete portfolio with positions and performance metrics, listing specific data included. However, it does not explicitly differentiate from similar sibling tools like get_my_portfolio or portfolio_get_my_portfolio, leaving ambiguity about when to use this one over others.
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 on when to use this tool vs alternatives. The description does not specify prerequisites, exclusions, or scenarios where other tools might be preferred. Given the many portfolio-related siblings, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze correlation between multiple securities.
DISCLAIMER: This correlation analysis is for educational purposes only. Past correlations do not guarantee future relationships between securities. Always diversify appropriately and consult with financial professionals.
This tool calculates the correlation matrix for a portfolio of stocks, helping to identify:
Highly correlated positions (diversification issues)
Negative correlations (natural hedges)
Overall portfolio correlation metrics
Portfolio Integration: If no tickers are provided, automatically analyzes correlation between all positions in your portfolio, helping you understand diversification and identify concentration risk.
| Name | Required | Description | Default |
|---|---|---|---|
| tickers | No | List of ticker symbols to analyze. If None, uses portfolio holdings. | |
| days | No | Number of days for correlation calculation (default: 252 for 1 year) | |
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It includes a disclaimer about educational purposes and past correlations, but does not mention whether the tool is read-only, destructive, or any authentication/rate limit implications. The behavioral impact is unclear.
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 well-structured with bullet points and a separate 'Portfolio Integration' section. It is concise but includes a necessary disclaimer. Some sentences could be trimmed, but overall it is appropriately sized.
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 high schema coverage, presence of an output schema, and the description's explanation of the output concept (correlation matrix) and default behavior, the description is fairly complete. It does not cover edge cases like empty portfolios or invalid tickers, but overall it provides sufficient 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?
All four parameters are described in the schema (100% coverage). The description adds value by explaining the default behavior of the 'tickers' parameter (auto-analyzes portfolio holdings) and the 'days' parameter (default 252 for 1 year). This goes beyond the schema descriptions.
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: 'Analyze correlation between multiple securities.' It elaborates on what the tool does (calculates correlation matrix, identifies correlations) and distinguishes from sibling tools like portfolio_risk_adjusted_analysis by focusing on correlation analysis and portfolio integration.
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 clear context on when to use the tool (identify diversification issues, natural hedges) and includes the important note that if no tickers are provided, it automatically uses portfolio holdings. However, it does not explicitly state when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove shares from a position in your portfolio.
This tool removes some or all shares of a stock from your portfolio. If no share count is specified, the entire position is removed.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| shares | No | Number of shares to remove (None = remove entire position) | |
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses core behavior (removes shares, optional entire position) but does not mention side effects, prerequisites (e.g., position existence), or whether the operation is destructive. Adequate but not detailed.
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?
Three sentences, front-loaded with purpose, no redundancy. Every sentence adds value: purpose, general behavior, conditional detail. Highly efficient.
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 removal tool with output schema present, the description covers core functionality. Lacks info on error conditions or reversibility, but given schema covers return values and schema coverage is high, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value by explaining the behavior of the nullable 'shares' parameter (if null, remove entire position). Other parameters are well-documented in schema, so description provides marginal extra meaning.
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 removes shares from a portfolio position, distinguishing it from sibling tools like add_portfolio_position or portfolio_clear_portfolio. It specifies the verb 'remove' and the resource 'position', and clarifies the optional share count behavior.
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 conditional guidance (remove entire position if shares omitted) but does not explicitly contrast with other removal methods or state when to use this tool over portfolio_clear_portfolio or similar. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform risk-adjusted stock analysis with position sizing.
DISCLAIMER: This analysis is for educational purposes only and does not constitute investment advice. All investments carry risk of loss. Always consult with qualified financial professionals before making investment decisions.
This tool analyzes a stock with risk parameters tailored to different investment styles. It provides:
Position sizing recommendations based on ATR
Stop loss suggestions
Entry points with scaling
Risk/reward ratio calculations
Confidence score based on technicals
Portfolio Integration: If you already own this stock, the analysis includes:
Current position details (shares, cost basis, unrealized P&L)
Position sizing relative to existing holdings
Recommendations for averaging up/down
The risk_level parameter (0-100) adjusts the analysis from conservative (low) to aggressive (high).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The ticker symbol to analyze | |
| risk_level | No | Risk tolerance from 0 (conservative) to 100 (aggressive) | |
| user_id | No | User identifier (defaults to "default") | default |
| portfolio_name | No | Portfolio name (defaults to "My Portfolio") | My Portfolio |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description describes the analysis outputs but does not disclose behavioral traits such as read-only nature, authorization requirements, or side effects. The disclaimer is legal, not behavioral. The tool appears to be a read operation, but this is not explicit.
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 well-structured with sections for overview, outputs, and portfolio integration. It is not overly verbose, though the disclaimer could be considered extraneous for agent consumption.
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?
The description covers the tool's function and outputs adequately, but does not address prerequisites (e.g., requiring portfolio data for integration) or limitations. Given the output schema exists, return values are not needed, but completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The description adds context about 'risk_level' adjusting analysis from conservative to aggressive, and implies portfolio parameters relate to existing holdings, providing moderate additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs risk-adjusted analysis with position sizing and lists specific outputs like stop loss and risk/reward ratios. However, it does not explicitly differentiate from the sibling 'risk_adjusted_analysis' tool, which may lead to confusion.
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 explicit guidance on when to use this tool versus alternatives. The description mentions portfolio integration, implying usage when the user already owns the stock, but does not state when not to use it or provide comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove or reduce a portfolio position.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| shares | No | Number of shares to remove (None = remove entire position) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It only states the action but omits important details: whether changes are immediate, destructive, reversible, or require authorization. The effect of reducing shares when the position doesn't exist is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with an output schema (not shown), the description is adequate but lacks context on side effects, error handling, or preconditions. It fulfills minimal completeness given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra meaning beyond stating the tool's purpose; the schema already explains the 'shares' parameter's role for reducing vs removing.
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 'Remove or reduce a portfolio position' clearly indicates the action (remove/reduce) and resource (portfolio position). It is specific enough to distinguish from tools that add positions or perform other operations.
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 like add_portfolio_position or portfolio_remove_position. There is no mention of prerequisites (e.g., position must exist) or conditions for reducing vs removing entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze market sentiment for a specific topic or sector.
Features:
Real-time sentiment extraction
News and social media analysis
Investor opinion aggregation
Trend identification
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | Topic for sentiment analysis | |
| timeframe | No | Time frame for analysis | 1w |
| persona | No | Investor persona | moderate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only lists broad features like 'Real-time sentiment extraction' but does not disclose any behavioral traits such as rate limits, authentication requirements, error conditions, or what happens if the topic is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-line action followed by a bullet list. It is front-loaded with the main purpose, though the bullet list is somewhat vague and could be more structured.
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?
Output schema exists, covering return values, but the description lacks detail on interpretation, edge cases, or prerequisites. It is adequate but leaves gaps in understanding the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters. The description adds no additional meaning beyond the schema, so a 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 'Analyze' and the resource 'market sentiment for a specific topic or sector'. It distinguishes from sibling tools like 'get_news_sentiment' by listing features like 'News and social media analysis' and 'Investor opinion aggregation'.
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 'data_get_adanos_market_sentiment' or 'get_news_sentiment'. There is no mention of scenarios or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive research on a specific company.
Features:
Financial metrics analysis
Market sentiment assessment
Competitive positioning
Investment recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock ticker symbol | |
| include_competitive_analysis | No | Include competitive analysis | |
| persona | No | Investor persona for analysis perspective | moderate |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It outlines the tool's capabilities (financial metrics, sentiment, competitive positioning, recommendations) but lacks specifics on side effects, auth needs, or rate limits. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three bullet points) and front-loaded with the purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is generic for a comprehensive research tool. It lists features but lacks detail on input constraints or output specifics. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description does not elaborate on parameter meanings beyond the feature list. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs comprehensive research on a specific company, listing four features. It is specific but does not distinguish from sibling tool 'research_comprehensive_research' which may be similar.
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 on when to use this tool versus alternatives like 'research_analyze_market_sentiment' or 'agents_deep_research_financial'. The description only lists features without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform comprehensive research on any financial topic using web search and AI analysis.
Enhanced features:
Generous timeout (basic: 120s, standard: 240s, comprehensive: 360s, exhaustive: 600s)
Intelligent source optimization
Parallel LLM processing
Progressive token budgeting
Partial results on timeout
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Research query or topic | |
| persona | No | Investor persona (conservative, moderate, aggressive, day_trader) | moderate |
| research_scope | No | Research scope (basic, standard, comprehensive, exhaustive) | standard |
| max_sources | No | Maximum sources to analyze (1-50) | |
| timeframe | No | Time frame for search (1d, 1w, 1m, 3m) | 1m |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior by mentioning timeouts, parallel processing, and partial results. However, it lacks details on side effects like API costs, rate limits, or data freshness.
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 front-loaded with the main purpose and uses a clear bullet list for features. It is somewhat verbose but still efficient, with no unnecessary fluff.
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 complexity (5 parameters, output schema exists), the description covers overall purpose and key features but lacks usage guidance and edge-case behavior. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions research scope and persona but adds no meaningful detail beyond the schema descriptions. It does not explain parameter interactions or format expectations.
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 it performs comprehensive research on financial topics using web search and AI analysis. It lists enhanced features that distinguish it from siblings, but could be more explicit about its scope compared to other research tools.
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 explicit guidance on when to use this tool versus alternatives. It lists features but does not specify contexts or conditions for using different research scopes (basic, standard, etc.).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset a specific circuit breaker.
| Name | Required | Description | Default |
|---|---|---|---|
| breaker_name | Yes | Name of the circuit breaker to reset |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full behavioral disclosure. It only states 'Reset', which implies a mutation but does not mention side effects (e.g., what changes occur, whether it acknowledges success/failure, or any permission requirements).
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 one sentence, which is efficient but lacks structure. It could benefit from front-loading the purpose and adding brief guidelines or behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to explain what happens after a reset, possible states, or error conditions. For a mutation tool, this is insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'breaker_name', which already has a description. The tool description adds no additional semantic value beyond the schema. Baseline 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 ('reset') and resource ('circuit breaker'), and implies specificity via 'a specific'. However, it does not explicitly differentiate from sibling 'get_circuit_breaker_status' by clarifying that this tool performs a mutation.
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 usage guidelines are provided. There is no indication of when to reset a circuit breaker versus checking its status with get_circuit_breaker_status, nor any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ATR-based position sizing and risk analysis with portfolio context.
Shows existing portfolio position if you hold this stock.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| risk_level | No | Risk tolerance 0-100 (default 50.0, higher = more aggressive) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral traits. It mentions ATR-based analysis and portfolio position display, but does not disclose side effects, required permissions, or whether it modifies any data. The output schema exists but is not described.
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 two front-loaded sentences. The first sentence states the core purpose, and the second adds context about portfolio positions. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details about return format, how portfolio context is used, and prerequisites (e.g., needing a portfolio). For a risk analysis tool, this is adequate but leaves gaps compared to more complete 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 coverage is 100% with both parameters described. The description adds no additional meaning beyond the schema (ticker and risk_level). It does not elaborate on how risk_level influences the analysis, so 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 it performs 'ATR-based position sizing and risk analysis with portfolio context', specifying the verb (analysis) and resource (position sizing/risk). It distinguishes itself from sibling tools like 'get_position_risk_check' or 'get_risk_alerts' by focusing on ATR-based sizing and portfolio 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?
The description implies usage for risk analysis with portfolio context and notes it shows existing positions, but does not explicitly state when to use this tool versus alternatives (e.g., get_position_risk_check) or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a VectorBT backtest with specified strategy and parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to backtest | |
| strategy | No | Strategy type (sma_cross, rsi, macd, bollinger, momentum, etc.) | sma_cross |
| start_date | No | Start date (YYYY-MM-DD), defaults to 1 year ago | |
| end_date | No | End date (YYYY-MM-DD), defaults to today | |
| initial_capital | No | Starting capital for backtest | |
| fast_period | No | ||
| slow_period | No | ||
| period | No | ||
| oversold | No | ||
| overbought | No | ||
| signal_period | No | ||
| std_dev | No | ||
| lookback | No | ||
| threshold | No | ||
| z_score_threshold | No | ||
| breakout_factor | No |
| Name | Required | Description |
|---|---|---|
No output 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 only states what the tool does without revealing behavioral traits such as side effects, required permissions, parameter conflict behavior, or output format. This is insufficient for a tool with 16 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 concise (one sentence) and front-loaded. However, it sacrifices essential information for brevity. It is not overly verbose, but a bit more structure could improve clarity 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 complexity (16 parameters, low schema coverage, no annotations) and many sibling tools, the description is incomplete. It does not explain output expectations, when to use this tool, or parameter dependencies. The presence of an output schema is not leveraged to reduce the burden.
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 only 31%, meaning many parameters lack documentation. The description adds no extra meaning beyond 'specified strategy and parameters,' failing to explain what each strategy parameter (e.g., fast_period, oversold) does or how they interact. This leaves the agent underinformed.
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 ('Run a VectorBT backtest') and mentions 'specified strategy and parameters,' which gives a basic understanding of what the tool does. However, it does not differentiate this tool from sibling tools like 'backtest_portfolio' or 'backtest_signal', lacking 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 numerous sibling tools performing backtesting (e.g., compare_strategies, optimize_strategy, walk_forward_analysis), the agent has no criteria to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run comprehensive health diagnostics.
Performs a complete system health check including all components, circuit breakers, resource usage, and generates a diagnostic report with recommendations.
Returns: Dictionary containing diagnostic results and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains what the tool does (runs health checks, generates report) but does not explicitly state whether it is read-only, has side effects, or requires permissions. The scope of components is mentioned, but more detail on operational impact would improve 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 concise with three sentences: a clear title sentence, a sentence elaborating scope, and a sentence describing return value. It is front-loaded and contains no fluff.
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 zero parameters and a described return value (dictionary with results and recommendations), the description is fairly complete. It does not detail the output structure or potential errors, but for a tool of this complexity it provides sufficient 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?
There are no parameters (0 params, 100% schema coverage). The description adds value by explaining the scope of the diagnostics (components, circuit breakers, resource usage) beyond the empty schema, achieving the baseline of 4 for parameter-less tools.
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 'Run comprehensive health diagnostics' and lists specific components (all components, circuit breakers, resource usage) and outputs (diagnostic report with recommendations). It distinguishes itself from sibling getter tools like 'get_system_health' by emphasizing comprehensiveness and active diagnostics.
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 explicit guidance on when to use this tool versus alternatives like 'get_status_dashboard' or 'get_component_status'. It does not include when-not-to-use scenarios or mention any prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run backtest using ML-enhanced strategies.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to backtest | |
| strategy_type | No | ML strategy type (ml_predictor, adaptive, ensemble, regime_aware) | ml_predictor |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| initial_capital | No | Initial capital amount | |
| train_ratio | No | Ratio of data for training (0.0-1.0) | |
| model_type | No | random_forest | |
| n_estimators | No | ||
| max_depth | No | ||
| learning_rate | No | ||
| adaptation_method | No | gradient |
| Name | Required | Description |
|---|---|---|
No output 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 fails to disclose any behavioral traits such as resource consumption, side effects, or required permissions. The nature of ML training is implied but not clarified.
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?
While the single sentence is brief, it is insufficiently informative for a tool with 11 parameters. The conciseness comes at the cost of completeness, making it under-specified rather than efficient.
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 (many parameters, sibling tools, and an ML component), the description is far too sparse. It provides no context about output, training behavior, or relationship to other backtesting 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 description does not mention any parameters or add meaning beyond the schema. With 55% schema coverage, the description fails to compensate for the missing parameter descriptions, leaving agents uninformed about many 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 clearly states the action (run backtest) and the specific domain (ML-enhanced strategies), but it does not differentiate from sibling tools like 'run_backtest' or 'backtest_signal', which are likely simpler 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 others, no prerequisites, and no alternatives. It only states what the tool does, not the context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register scheduling intent for a named screen. Records the screen name and interval in the database for future integration with the scheduler. Actual periodic execution is wired during the integration pass.
| Name | Required | Description | Default |
|---|---|---|---|
| screen_name | Yes | ||
| interval_minutes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool only registers intent and does not execute, and that actual execution is wired later. This is good transparency, but lacks details on side effects or permissions.
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?
Three concise sentences with no superfluous information. The verb 'Register' is front-loaded, making the purpose immediately clear.
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 low complexity and the presence of an output schema, the description is fairly complete but lacks parameter details. It explains the tool's purpose and behavior adequately for a simple registration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The description mentions 'screen name and interval' but does not explain the meaning of 'screen_name' or the unit/format of 'interval_minutes'. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers scheduling intent for a screen, distinguishing it from execution tools. It specifies 'Records the screen name and interval in the database for future integration with the scheduler', which is a specific verb-resource pair.
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 does not explicitly state when to use this tool versus alternatives. While it implies it's for setting up future periodic execution, there is no guidance on when not to use it or mention of sibling tools like 'check_signals_now'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive screening results from all strategies.
This tool returns the top stocks from each screening strategy:
Maverick Bullish: High momentum growth stocks
Maverick Bearish: Weak stocks for short opportunities
Supply/Demand Breakouts: Stocks breaking out from accumulation phases
Returns: Dictionary containing all screening results organized by strategy
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states it returns top stocks organized by strategy, but does not disclose data freshness, permissions, rate limits, or potential side effects. Adequate but could be more comprehensive.
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?
Description is concise and front-loaded with purpose. Uses bullet points to list strategies clearly. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema existing, the description adequately covers what the tool does and its return structure. Missing details like ordering or limits, but still fairly complete for a simple list retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline 4 per guidelines. Description adds nothing about parameters, but none are needed. Schema coverage is 100%.
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 it returns comprehensive screening results from all strategies, listing three specific strategies (Maverick Bullish, Maverick Bearish, Supply/Demand Breakouts). This distinguishes it from sibling tools like screening_get_maverick_stocks that return only one strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need all strategies at once, but does not explicitly state when to use this vs alternative specific tools. No direct 'when-not-to-use' or mention of alternatives, but context from the list makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top Maverick Bear stocks from the screening results.
DISCLAIMER: Bearish screening results are for educational purposes only. This is not advice to sell short or make bearish trades. Short selling involves unlimited risk potential. Always consult financial professionals before trading.
The Maverick Bear screening identifies stocks with:
Weak momentum strength
Bearish technical patterns
Distribution characteristics
High bear scores
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default: 20) |
| Name | Required | Description |
|---|---|---|
No output 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 clearly identifies this as a read operation ('Get') and explains the screening criteria. The disclaimer notes educational purpose, but lacks details on data freshness or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose. The disclaimer and criteria explanation add some length but are relevant. Could be slightly more concise by condensing the disclaimer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It adequately explains the nature of the stocks returned and includes a mandatory disclaimer. Missing details on result ordering or data freshness are minor 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?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema. The 'limit' parameter is already described in the schema, so the description provides no new semantic value.
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 tool name and description clearly state it retrieves 'top Maverick Bear stocks' from screening results. This distinguishes it from siblings like 'screening_get_maverick_stocks' (bullish) and other screening tools.
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 does not provide any guidance on when to use this tool versus alternative screening tools. It only explains the screening criteria without specifying preferred contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top Maverick stocks from the screening results.
DISCLAIMER: Stock screening results are for educational and research purposes only. This is not investment advice. Past performance does not guarantee future results. Always conduct thorough research and consult financial professionals before investing.
The Maverick screening strategy identifies stocks with:
High momentum strength
Technical patterns (Cup & Handle, consolidation, etc.)
Momentum characteristics
Strong combined scores
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default: 20) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It includes a disclaimer but does not disclose authentication needs, rate limits, or what happens if screening data is stale. Minimal behavioral context beyond the strategy criteria.
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?
Front-loaded with purpose, but includes a lengthy disclaimer and strategy bullet points. While the disclaimer is important, it could be more concise. Adequate but not optimally structured.
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 presence of an output schema, the description does not need to detail return values. It covers the core purpose and strategy. Lack of annotations is partly mitigated by the description, but could mention prerequisites or data freshness. Overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described as 'Maximum number of stocks to return (default: 20)'. Description adds no additional semantics beyond the schema, so baseline 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?
Description clearly states it retrieves top Maverick stocks from screening results, with specific strategy criteria. It distinguishes from sibling tools like screening_get_maverick_bear_stocks (bearish) and screening_get_all_screening_recommendations (all).
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 explicit guidance on when to use this tool vs alternatives like get_maverick_stocks or screening_get_screening_by_criteria. The description provides strategy details but lacks when/when-not context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks filtered by specific screening criteria.
This tool allows custom filtering across all screening results based on:
Momentum score rating
Volume requirements
Price constraints
Sector preferences
| Name | Required | Description | Default |
|---|---|---|---|
| min_momentum_score | No | Minimum momentum score rating (0-100) | |
| min_volume | No | Minimum average daily volume | |
| max_price | No | Maximum stock price | |
| sector | No | Specific sector to filter (e.g., "Technology") | |
| limit | No | Maximum number of results |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as data freshness, authentication requirements, or whether it is a read-only operation. Given the absence of annotations, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose. It lists categories efficiently. Minor improvement could be a shorter lead-in, but it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to detail return values. However, it omits information about result ordering, pagination, or default behavior beyond the limit parameter. It is adequate but not fully context-rich.
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 description groups parameters into meaningful categories (momentum, volume, price, sector) that are not fully captured by the individual parameter descriptions. This adds semantic value beyond the schema, which already has 100% 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 'Get stocks filtered by specific screening criteria', which defines the verb and resource. It lists categories of criteria, distinguishing it from sibling tools that return specific lists (e.g., maverick stocks). However, it could more explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when custom filtering is needed ('allows custom filtering across all screening results'), but it does not specify when not to use it or mention alternative sibling tools that might be more appropriate for specific screening types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get stocks showing supply/demand breakout patterns from accumulation.
This screening identifies stocks in the demand expansion phase with:
Price above all major moving averages (demand zone)
Moving averages in proper alignment indicating accumulation (50 > 150 > 200)
Strong momentum strength showing institutional interest
Market structure indicating supply absorption and demand dominance
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of stocks to return (default: 20) | |
| filter_moving_averages | No | If True, only return stocks above all moving averages |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explains the screening criteria but omits behavioral details like potential errors, rate limits, or data dependencies. The tool is non-destructive, and the description adequately conveys its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence for purpose followed by bullet points for criteria. It is front-loaded with the core action. Minor redundancy in listing criteria that could be integrated, but overall efficient.
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 presence of an output schema, the description sufficiently covers what the tool does. It defines the criteria and parameters. No mention of edge cases or prerequisites, but for a screening tool with explicit criteria, it is complete enough.
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% (both parameters have descriptions and defaults). The tool description does not add new meaning beyond the schema, such as clarifying how filter_moving_averages interacts with the criteria. Baseline 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 tool retrieves stocks with supply/demand breakout patterns from accumulation. It lists specific criteria (price above major moving averages, moving average alignment, momentum strength), distinguishing it from sibling tools like get_maverick_stocks or get_all_screening_recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for identifying accumulation-based breakouts but does not explicitly compare to alternatives or provide when-not-to-use guidance. Siblings like get_screening_by_criteria could be similar, but no context is given for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive technical analysis for a given ticker with enhanced logging and timeout handling.
This enhanced version provides:
Step-by-step logging for debugging
25-second timeout to prevent hangs
Comprehensive error handling
Guaranteed JSON-RPC responses
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| days | No | Number of days of historical data to analyze (default: 365) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses logging, timeout (25s), error handling, and guaranteed responses. However, it does not state that it is read-only or any other behavioral traits beyond those mentioned. The description adds some value but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence and a bullet list of features. It efficiently conveys the main points without unnecessary verbosity. A bit redundant in listing 'enhanced' aspects but still compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. It only says 'comprehensive technical analysis' without specifics. Compared to siblings like 'get_full_technical_analysis', it's unclear what additional data this version provides. The description is incomplete for effective 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?
Schema coverage is 100% with clear descriptions for both parameters: ticker and days with default. The description does not add any additional meaning or constraints beyond the schema, which is adequate.
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 it gets comprehensive technical analysis for a ticker, but does not differentiate from the sibling tool 'get_full_technical_analysis'. The verb 'get' and resource 'technical analysis' are clear, but the 'enhanced' aspect is vague without distinguishing 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 implies using this tool for detailed analysis with better debugging and timeout handling, but does not explicitly state when to use versus alternatives like 'get_full_technical_analysis' or other analysis tools. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get MACD analysis for a given ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| fast_period | No | Fast EMA period (default: 12) | |
| slow_period | No | Slow EMA period (default: 26) | |
| signal_period | No | Signal line period (default: 9) | |
| days | No | Number of days of historical data to analyze (default: 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral details such as data sources, computation limits, or effect on the system. The agent cannot infer safety or side effects.
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 short sentence, which is concise and front-loaded. However, it omits necessary context, making it less effective despite its 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 tool has 5 parameters and an output schema, the description lacks completeness. There is no explanation of return values, prerequisites, or how this analysis differs from other technical 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?
All parameters are described in the input schema (100% coverage), so the description adds no additional meaning. 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 it retrieves MACD analysis for a given ticker. However, it does not distinguish from the sibling tool 'get_macd_analysis', which likely performs the same 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 like 'technical_get_full_technical_analysis' or 'get_macd_analysis'. The agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get RSI analysis for a given ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| period | No | RSI period (default: 14) | |
| days | No | Number of days of historical data to analyze (default: 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure, yet it only says 'Get RSI analysis' without noting if the tool is read-only, what data it retrieves, or any side effects.
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 sentence of 8 words, highly concise and front-loaded. It loses a point for being slightly too terse to convey full value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description omits any explanation of what RSI analysis entails, how to interpret results, or usage caveats. This leaves significant gaps for a user unfamiliar with the domain.
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?
All parameters have descriptions in the schema (100% coverage). The description adds no additional meaning beyond the schema; 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', the resource 'RSI analysis', and the scope 'for a given ticker'. It effectively differentiates from siblings like 'get_rsi_analysis' and other technical analysis tools.
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_full_technical_analysis' or 'get_macd_analysis'. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a comprehensive technical analysis chart with enhanced error handling.
This enhanced version provides:
15-second timeout for chart generation
Progressive chart sizing for Claude Desktop compatibility
Detailed logging for debugging
Graceful fallback on errors
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | The ticker symbol of the stock to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It focuses on implementation details (timeout, progressive sizing, logging, fallback) rather than the tool's actual behavior (e.g., what the chart looks like, data sources, user actions side effects).
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 relatively concise, listing key enhancements in bullet points. However, it could be restructured to prioritize the core purpose before technical details.
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 output schema and no return value description, the tool's output is undefined. The description lacks information about what the user will receive (e.g., image URL, HTML, data object), which is critical for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the single parameter ('ticker') with a clear description. The tool description adds nothing beyond, but since schema coverage is high, the baseline of 3 is elevated by the schema's adequacy.
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 'Generate a comprehensive technical analysis chart', which gives a verb and resource. However, it is vague about what the chart contains (e.g., indicators, timeframes) and does not differentiate from sibling tools like 'get_full_technical_analysis' or 'get_macd_analysis'.
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 explicit guidance on when to use this tool versus alternatives. The description mentions 'enhanced error handling' and 'Claude Desktop compatibility', but does not specify contexts or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get support and resistance levels for a given ticker.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Stock ticker symbol | |
| days | No | Number of days of historical data to analyze (default: 365) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond the basic operation. For example, it does not mention if the tool returns multiple levels, any limitations, or side effects.
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 very short (one sentence) and front-loaded with the key information. However, it could benefit from a bit more detail without becoming verbose.
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 simplicity (2 parameters, output schema present), the description is minimally complete. It explains the main function but does not address potential sibling confusion or provide any additional context beyond the basic action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions in the schema. The description adds no additional meaning beyond the schema, so 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 'Get support and resistance levels for a given ticker' clearly states the action (Get) and the resource (support and resistance levels), with the input (ticker). It does not differentiate from the sibling 'get_support_resistance' but is otherwise unambiguous.
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 on when to use this tool over alternatives, such as the similarly named sibling 'get_support_resistance'. No exclusions or usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Train an ML predictor model for trading signals.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to train on | |
| start_date | No | Start date for training data | |
| end_date | No | End date for training data | |
| model_type | No | ML model type (random_forest) | random_forest |
| target_periods | No | Forward periods for target variable | |
| return_threshold | No | Return threshold for signal classification | |
| n_estimators | No | ||
| max_depth | No | ||
| min_samples_split | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It merely says 'train' without explaining data dependencies, training duration, model persistence, side effects, or required permissions. This is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It could include more information without becoming verbose, such as a brief statement about output or prerequisites. It is adequate but minimal.
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?
The tool has 9 parameters, a complex training operation, and an output schema, yet the description gives no context about the output, training data requirements, model behavior, or how to use the results. This is severely incomplete for an agent to understand the tool's full 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 67% parameter description coverage (6 out of 9 parameters described). The description adds no additional meaning beyond stating the overall action. It does not explain the purpose of any parameter or how they influence training. For the 3 undocumented parameters (n_estimators, max_depth, min_samples_split), the description offers no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool trains an ML predictor model for trading signals. It uses a specific verb ('train') and resource ('ML predictor model'), and distinguishes itself from sibling tools like 'run_ml_strategy_backtest' which focuses on backtesting the trained model.
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. There is no mention of prerequisites, when not to use it, or comparison to similar tools like 'run_ml_strategy_backtest'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing signal's label, condition, interval, or active status.
| Name | Required | Description | Default |
|---|---|---|---|
| signal_id | Yes | ||
| label | No | ||
| condition | No | ||
| interval_seconds | No | ||
| active | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only lists updatable fields but does not disclose behaviors such as what happens if signal_id is invalid, whether updates are atomic, or any required permissions.
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?
Single sentence, front-loaded with key information, no redundant words. Efficiently communicates the tool's core 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 5 parameters, 0% schema coverage, and no annotations, the description is too brief. It omits return value behavior, edge cases, and preconditions. Output schema exists but description should provide high-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists updatable fields but lacks semantic details like valid ranges for interval_seconds or structure of condition. Adds some value beyond schema but insufficient depth.
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 'Update', the resource 'existing signal', and lists specific fields (label, condition, interval, active status). It effectively distinguishes from sibling tools like create_signal and delete_signal.
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 on when to use this tool versus alternatives like create_signal or list_signals. No prerequisites (e.g., signal must exist) or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform walk-forward analysis to test strategy robustness.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Stock symbol to analyze | |
| strategy | No | Strategy type | sma_cross |
| start_date | No | Start date (YYYY-MM-DD) | |
| end_date | No | End date (YYYY-MM-DD) | |
| window_size | No | Test window size in trading days (default: 1 year) | |
| step_size | No | Step size for rolling window (default: 1 quarter) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the high-level purpose, with no disclosure of behavioral traits such as data requirements, computational cost, side effects, or output format. The output schema exists but is not referenced.
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?
Single sentence, no unnecessary words. However, it could be expanded without losing conciseness to include more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too brief for a complex tool like walk-forward analysis. It lacks explanation of the method, how parameters affect results, and prerequisites. Many sibling tools have more descriptive definitions.
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. The description adds no additional meaning beyond what is in the schema. Baseline 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 tool's purpose: 'Perform walk-forward analysis to test strategy robustness.' It uses a specific verb ('Perform') and resource ('walk-forward analysis'), and distinguishes from siblings like 'backtest_portfolio' or 'optimize_strategy'.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, when to avoid, or compare to other tools like backtest or optimize.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a ticker symbol to an existing watchlist. Optional notes can capture the thesis or context for watching the symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| watchlist_id | Yes | ||
| symbol | Yes | ||
| notes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided to indicate safety or side effects (e.g., readOnlyHint, destructiveHint). The description only mentions 'Add,' implying mutation, but it does not disclose what happens if the symbol already exists, whether the operation is idempotent, or what the response contains. This lack of behavioral detail burdens the agent to explore behaviorally.
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 succinct, consisting of two sentences that immediately convey the primary action and a secondary feature. Every word is relevant, and there is no redundancy or filler. It is appropriately front-loaded with the core 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 moderate complexity (3 parameters, 2 required) and the presence of an output schema (which could document return values but is not shown), the description is incomplete. It fails to explain how to obtain a valid watchlist_id, error handling (e.g., duplicate symbol), or what the tool returns. A more complete description would address these 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 input schema has 0% description coverage, so the description must compensate. It mentions 'existing watchlist' (implying watchlist_id), 'ticker symbol' (symbol), and 'optional notes' (notes), but it does not explain what these parameters mean in context (e.g., where to find watchlist_id, symbol format, or how notes are used). The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a ticker symbol to an existing watchlist.' It uses a specific verb ('Add') and resource ('ticker symbol to an existing watchlist'), and the optional notes detail further clarifies the function. Sibling tools like watchlist_create and watchlist_remove help differentiate this tool from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when adding a symbol to an existing watchlist, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., watchlist_create for creating a new watchlist, or add_portfolio_position for adding to a portfolio). There is no mention of prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a scored intelligence brief for every symbol on a watchlist. Each entry includes: active signal count, upcoming catalyst flag (within 30 days), days on watchlist, and notes. Results are sorted by active signals descending.
| Name | Required | Description | Default |
|---|---|---|---|
| watchlist_id | Yes |
| Name | Required | Description |
|---|---|---|
No output 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 describes output format and sorting, but does not disclose side effects, permissions, or whether the tool is read-only. The read-only nature is inferred but not explicit.
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 two concise sentences, front-loaded with the main purpose, and no unnecessary words. It efficiently communicates the tool's output and sorting.
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 simple tool (one parameter), the description provides adequate context about output content. However, it omits necessary preconditions like the watchlist must exist, and does not mention error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'watchlist_id' with 0% description coverage. The description does not mention the parameter or explain how to obtain the watchlist ID, missing an opportunity to clarify parameter meaning.
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: 'Generate a scored intelligence brief for every symbol on a watchlist.' It specifies the output fields (active signal count, catalyst flag, etc.) and sorting, distinguishing it from siblings like 'get_watchlist' which likely returns raw watchlist data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to get scored intel on a watchlist, but does not explicitly state when to use it over alternatives like 'get_watchlist' or other analytical tools. No 'when not to use' or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new named watchlist for tracking ticker symbols. The name must be unique. An optional description can be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Notes uniqueness constraint but lacks disclosure on permissions, side effects, or response behavior. Minimal 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?
Two sentences, front-loaded with action, no extraneous words. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 parameters and an output schema available, the description covers creation, uniqueness, and optional description. Could mention return value but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. Explains 'name' as required and unique, 'description' as optional. Adds meaning but could detail format or length limits.
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?
Clearly states the verb 'Create', resource 'watchlist', and scope 'named for tracking ticker symbols'. Distinguishes from sibling tools like 'watchlist_add' and 'watchlist_remove' by focusing on creation.
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?
Provides a constraint (name must be unique) but no explicit guidance on when to use this tool versus alternatives like 'watchlist_add' or 'portfolio_add_position'. Usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a ticker symbol from a watchlist.
| Name | Required | Description | Default |
|---|---|---|---|
| watchlist_id | Yes | ||
| symbol | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It only states the removal action but does not explain outcomes for missing watchlist/symbol, permanence, side effects, or authorization needs.
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 short sentence, which is under-specification given the tool's importance. It lacks front-loaded structure and does not earn its place by providing necessary context.
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 mutation tool with no annotations and no parameter descriptions, this description is inadequate. It does not mention output, error conditions, or complete usage context, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no meaning beyond the schema's type and required flag for the two parameters. It does not explain that 'watchlist_id' identifies the list or that 'symbol' is the ticker.
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 'Remove' and the resource 'ticker symbol from a watchlist'. It distinguishes from sibling tools like 'watchlist_add' (adds) and 'watchlist_create' (creates).
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 'watchlist_add' or 'watchlist_clear'. There is no mention of prerequisites like watchlist existence or symbol presence.
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. Dates show when Glama detected each change.
v0.1.0add_portfolio_positionagents_analyze_market_with_agentagents_compare_multi_agent_analysisagents_compare_personas_analysisagents_deep_research_financialagents_get_agent_streaming_analysisagents_list_available_agentsagents_orchestrated_analysisanalyze_market_regimesbacktest_portfoliobacktest_signalcheck_signals_nowcompare_strategiescompare_tickerscreate_signalcreate_strategy_ensembledata_clear_cachedata_fetch_stock_datadata_fetch_stock_data_batchdata_get_adanos_market_sentimentdata_get_cached_price_datadata_get_chart_linksdata_get_news_sentimentdata_get_stock_infodelete_signaldiscover_capabilitiesfetch_stock_datagenerate_backtest_chartsgenerate_optimization_chartsget_adanos_market_sentimentget_all_screening_recommendationsget_circuit_breaker_statusget_component_statusget_decision_logget_economic_calendarget_full_technical_analysisget_health_historyget_macd_analysisget_market_overviewget_market_regimeget_maverick_bear_stocksget_maverick_stocksget_mcp_connection_statusget_my_portfolioget_news_sentimentget_portfolio_risk_dashboardget_position_risk_checkget_regime_adjusted_sizingget_regime_historyget_resource_usageget_risk_alertsget_rsi_analysisget_screening_changesget_screening_historyget_screening_pipeline_statusget_status_dashboardget_stock_infoget_strategy_comparisonget_strategy_helpget_strategy_performanceget_supply_demand_breakoutsget_support_resistanceget_system_healthget_tool_registry_statusget_upcoming_catalystsget_user_portfolio_summaryget_watchlistjournal_add_tradejournal_close_tradejournal_list_tradesjournal_trade_reviewlist_all_strategieslist_signalslist_strategiesmonte_carlo_simulationoptimize_strategyparse_strategyperformance_analyze_database_index_usageperformance_clear_system_cachesperformance_get_cache_performance_statusperformance_get_database_performance_statusperformance_get_redis_health_statusperformance_get_system_performance_healthperformance_optimize_cache_configurationportfolio_add_positionportfolio_clear_portfolioportfolio_compare_tickersportfolio_correlation_analysisportfolio_get_my_portfolioportfolio_portfolio_correlation_analysisportfolio_remove_positionportfolio_risk_adjusted_analysisremove_portfolio_positionresearch_analyze_market_sentimentresearch_company_comprehensiveresearch_comprehensive_researchreset_circuit_breakerrisk_adjusted_analysisrun_backtestrun_health_diagnosticsrun_ml_strategy_backtestschedule_screeningscreening_get_all_screening_recommendationsscreening_get_maverick_bear_stocksscreening_get_maverick_stocksscreening_get_screening_by_criteriascreening_get_supply_demand_breakoutstechnical_get_full_technical_analysistechnical_get_macd_analysistechnical_get_rsi_analysistechnical_get_stock_chart_analysistechnical_get_support_resistancetrain_ml_predictorupdate_signalwalk_forward_analysiswatchlist_addwatchlist_briefwatchlist_createwatchlist_removeMany tools have overlapping purposes, such as multiple portfolio position tools (add_portfolio_position, portfolio_add_position) and duplicate screening tools. The agent would struggle to choose the correct tool.
Naming conventions are inconsistent, mixing category prefixes (data_, technical_, screening_, portfolio_) with unprefixed tools, and using both verb_noun and noun_verb patterns (e.g., add_portfolio_position vs portfolio_add_position).
119 tools is excessively high for any server. This number includes many redundant or trivial tools, indicating poor scoping and a lack of consolidation.
The tool set covers a broad range of financial operations (data, analysis, portfolio, backtesting, signals, watchlists). However, the high redundancy suggests some areas are over-covered while others may still have gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stock analysis MCP: 38 indicators, 7 optimizers, 8 backtests, US + India sectors.
Global stock research, ML forecasts, valuation signals, screeners & portfolio tracking in Claude
7-factor stock scoring MCP server. US/HK/CN, 74 stocks. Free + Premium (USDC/Base). x402 ready.
The Octagon MCP server provides specialized AI-powered financial research and analysis by integrating with the Octagon Market Intelligence API. It enables users to analyze public market data (SEC filings, earnings transcripts, financial metrics, and stock data for 8000+ companies), private market data (3M+ companies, 500k+ funding rounds, 2M+ M&A/IPO transactions), and conduct deep research including web scraping capabilities. The server also features autonomous research agents that search hundreds of sources and return fully cited reports in approximately one minute.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wshobson/maverick-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
