Skip to main content
Glama
aahl

MCP Server for stock and crypto

by aahl

给出投资建议

trading_suggest

Generates investment recommendations for stocks and crypto, specifying action (buy/sell/hold), confidence score, and reasoning based on AI analysis.

Instructions

基于AI对其他工具提供的数据分析结果给出具体投资建议

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYes股票代码或加密币种
actionYes推荐操作: buy/sell/hold
scoreYes置信度,范围: 0-100
reasonYes推荐理由

Implementation Reference

  • The tool 'trading_suggest' is registered via the @mcp.tool decorator with a Chinese title '给出投资建议' (Give investment advice) and a description about providing investment suggestions based on AI analysis of data from other tools.
    @mcp.tool(
        title="给出投资建议",
        description="基于AI对其他工具提供的数据分析结果给出具体投资建议",
  • The handler function for 'trading_suggest'. It takes four parameters: symbol (stock/crypto code), action (buy/sell/hold), score (confidence 0-100), and reason (recommendation rationale). Simply returns them as a dictionary.
    def trading_suggest(
        symbol: str = Field(description="股票代码或加密币种"),
        action: str = Field(description="推荐操作: buy/sell/hold"),
        score: int = Field(description="置信度,范围: 0-100"),
        reason: str = Field(description="推荐理由"),
    ):
        return {
            "symbol": symbol,
            "action": action,
            "score": score,
            "reason": reason,
        }
  • The schema for input parameters includes symbol (string), action (string - buy/sell/hold), score (int 0-100), and reason (string). The output schema is a dictionary with the same four fields.
    def trading_suggest(
        symbol: str = Field(description="股票代码或加密币种"),
        action: str = Field(description="推荐操作: buy/sell/hold"),
        score: int = Field(description="置信度,范围: 0-100"),
        reason: str = Field(description="推荐理由"),
    ):
        return {
            "symbol": symbol,
            "action": action,
            "score": score,
            "reason": reason,
        }

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0

TDQS

C2.2/5.0
Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It does not state whether the tool is a read-only suggestion, a write/record operation, or how it communicates results. No side effects, permissions, or return behavior are mentioned, leaving the tool's actual execution opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that communicates its core purpose efficiently. It is front-loaded and avoids verbosity, though it omits important contextual details that would make it more useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description should explain what the tool returns and any behavioral nuances. It does not describe return values, side effects, or how the advice is delivered. For a 4-parameter tool, this is notably incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains each parameter (symbol, action, score, reason) adequately. The description adds no additional meaning to the parameters, but the baseline of 3 applies because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'gives specific investment advice based on AI analysis results of data from other tools,' which is a clear verb+resource. However, it does not distinguish itself from sibling tools like composite_stock_diagnostic or binance_ai_report that also generate advice, and the input schema (containing action, score, reason) suggests the tool may present pre-computed advice rather than generate it, creating ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives. It merely describes what it does without mentioning prerequisites, exclusions, or when not to use it. The phrase 'based on AI analysis of other tools' hints at a sequence, but no explicit usage context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.