Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This server exhibits severe structural and documentation deficiencies across nearly all 43 tools. While the naming convention is generally action-oriented (get_*, fetch_*, etc.), the vast majority of tools lack visible input schemas in the provided source code. Of the tools with documented schemas (only ~10 visible: get_market_news, log_activity, get_activities, etc.), most have minimal or missing parameter descriptions. Tool descriptions range from vague (e.g., 'Fetch market-related videos from YouTube' for get_market_videos) to completely absent (tools 32-43 have descriptions that are merely tool names with no context). No output schemas are documented. Error handling is not evident in the tool definitions. The source code excerpt cuts off mid-import, making it impossible to verify actual tool registration, parameter validation, or error recovery patterns. Most tools appear to be inferred from listings rather than from explicit FastAPI @app.post() route definitions with Pydantic schemas.
Tools (43)
archive_activitiesreversiblesource verified67/100
Archive activities older than the specified number of days
Complete all tool definitions with explicit Pydantic request/response models in FastAPI routes. Currently only ~10 tools have visible schemas. Each tool must declare input types, parameter descriptions, and output fields.
Expand all tool descriptions to 50-200 characters and include: WHAT the tool does, WHEN to use it (when to choose it over similar tools), and WHAT it returns. Current descriptions like 'Backtesting engine for strategy analysis' lack actionable guidance.
Add comprehensive output schemas for all 43 tools. Document the structure and types of returned fields. Enable LLMs to plan downstream tool calls without guessing.
Remove API key exposure from get_api_key and get_all_keys. Replace with get_key_status or similar that returns only metadata (provider name, last rotation date, validity status), no actual key material. Inject keys server-side during execution.
Add error handling guidance to all tools. Include recovery hints: 'If market data unavailable, try alternative provider X', 'If user not found, call search_users() first with partial name', 'Available channels: discuss-project-xyz, project-xyz-dev'.
Implement confirmation/dry-run patterns for destructive operations: archive_activities, mark_api_key_invalid, set_cached_data, invalidate_cache_pattern. Example: add a 'dry_run' parameter that returns what would be changed without applying it.
Add permission gates and scope declarations to sensitive tools. Example: log_activity should verify the caller has 'write:audit_log' scope. user_auth_manager should require 'admin:users' scope. Document these in tool descriptions.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
The majority of tools (33 of 43) have no visible input schemas or parameter definitions in the provided code. Only ~10 tools show documented parameters.
Many tool descriptions are trivial or single-noun (e.g., 'Backtesting engine for strategy analysis', 'Risk analysis and metrics'). They do not follow LLM-optimized description patterns: explain WHAT the tool does, WHEN to use it, and what it returns. Baseline: good descriptions are 50-200 characters and answer all three questions.
No output schemas are documented for any tool. LLMs cannot determine what fields to expect, preventing effective planning of downstream tool calls. This violates pattern baseline: '100% of A+ tools have documented return types.'
API key exposure risk: get_api_key and get_all_keys expose API keys (read-only but still high risk). Keys should never be returned to agents. Use server-side secret injection via environment variables or vault. Agents log all parameters and responses, keys in responses leak into audit trails.
No error handling guidance is visible. Tools lack recovery hints ('Try search_users() first', 'Available channels are X, Y, Z'). Error responses should tell LLMs what to do next, categorize errors (retryable vs. fatal), and provide actionable messages. This violates pattern baseline.
Many tools accept external API calls (Alpha Vantage, Tiingo, Yahoo Finance, FRED, etc.) with no visible timeout configuration or fallback strategy. Long-running calls can block the agent. Tools lack rate-limiting guards, risking runaway agent loops that overwhelm downstream services.
Destructive or sensitive operations (archive_activities, mark_api_key_invalid, set_cached_data, invalidate_cache_pattern, notion_integration, watchlist_manager, user_auth_manager) lack confirmation/dry-run patterns. Agents make mistakes, these tools should support a confirmation step before execution to prevent catastrophic errors.
No permission gates documented. Tools like user_auth_manager, notion_integration, and archive_activities should verify calling agent/user has authority before execution. No scope declarations (e.g., 'read:email', 'write:calendar') visible. Least-privilege configuration is impossible.
Parameter descriptions are sparse or missing even when schemas are visible. For example, get_api_key has a 'provider' parameter with description 'Provider name (alpha_vantage, tiingo, finlight, youtube, fred)', this is good, but it should also state whether the value is case-sensitive, if partial names are accepted, and what happens if the provider is invalid. Many other tools have no parameter descriptions at all.
Data pagination and result limits are not consistently enforced or documented. get_activities and get_market_news accept pagination parameters (good), but most other tools lack pagination. For tools returning lists (activities, cached data, archive list, etc.), there's no documentation of result caps, default limits, or how agents should handle large result sets that blow context windows.
Enforce rate limiting and timeouts on external API calls (Alpha Vantage, Yahoo Finance, Tiingo, FRED, Polygon). Cap calls per minute per provider. Add exponential backoff for retries. Document timeout behavior in descriptions.
For list-returning tools (get_activities, get_archive_list, fetch_polygon_data), enforce result limits (e.g., 50 items max) and require pagination. Document the default limit and how to request the next page.
Add input validation with actionable error messages. Example: export_activities with format='xml' should return 'Invalid format: xml. Must be one of: json, csv' instead of a 400 error. Allow LLMs to self-correct.
For tools with mutual parameter dependencies (e.g., export_activities can filter by activity_type OR search_query but not both), document this conflict clearly. Validate and return helpful errors.
Audit the codebase for prompt injection risks. Tools like put_screener and screen_bossio_opportunities that query external services should sanitize LLM-provided parameters (ticker symbols, search terms) to prevent injection attacks.
Add per-tool audit logging: log who called what tool, with which parameters, at what time, and what happened. This is critical for compliance and incident response with financial tools.
Consider batch variants of commonly-called tools. If an agent loops calling put_screener 100 times, offer put_screener_batch() to process multiple at once. Reduces token waste and latency.