MCP server providing stock price data, historical stock information, stock comparison, and tech news retrieval via Tavily API
Server has 5 tools with basic verb-noun naming (get_*, compare_*). All tools have descriptions, but most are generic and under 100 chars, lacking context on WHEN to use them or WHAT they return. Input schemas are present with parameter descriptions, but output schemas are entirely undocumented, LLMs cannot plan downstream calls. Error handling returns raw strings ('Error fetching...') without recovery guidance. No tool annotations (readOnlyHint, etc.). Composition is reasonable (each tool does one thing), but missing pagination, result limits, and structured output. No secrets exposed, but no audit logging either.
Compare the current stock prices of two ticker symbols. Returns a formatted message comparing the two stock prices.
Use tools when user ask for news about a specific topic. Get the latest news article for the given query. Returns the summarize article.
Get articles and summarize them.
Retrieve the current stock price for the given ticker symbol. Returns the latest closing price as a float.
Retrieve historical data for a stock given a ticker symbol and a period. Returns the historical data as a CSV formatted string.
No output schemas documented. LLMs cannot infer return types (float vs string vs CSV). Breaks downstream tool chaining and forces agents to guess field names.
Error handling returns raw exception strings ('Error fetching stock price for AAPL: ...') without recovery guidance. LLMs cannot determine if error is retryable or user-fixable.
Tool descriptions are generic and under 100 chars. Missing WHEN to use each tool and how it differs from similar tools (e.g., get_articles vs get_article). Descriptions should be 50-200 chars with context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | <=2025-11-25 | v2 |
No pagination or result limits. get_articles and get_article return raw API responses (potentially large). Should cap results at 20-50 items and document limit in description.
No tool annotations (readOnlyHint, idempotentHint). All tools are read-only but this is not declared in schema, forcing LLMs to infer safety from descriptions.