TWSE MCP Server

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns historical or real-time data, or handles errors. For a tool with zero annotation coverage, this lack of behavioral context is a significant gap.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Get stock P/E ratio, dividend yield and P/B ratio') and adds the key constraint ('by date query'), making it easy to parse quickly. Every part of the sentence 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 0 parameters (schema coverage 100%) and no output schema, the description is minimally adequate. It explains the purpose and hints at date-based querying, but lacks details on behavioral traits (e.g., data freshness, error handling) and doesn't clarify output format or structure. For a simple retrieval tool, it meets basic needs but leaves gaps in 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?

The input schema has 0 parameters with 100% coverage, so the schema already fully documents that no inputs are required. The description adds value by implying a 'date query' is involved, suggesting the tool might use contextual or default dates, but it doesn't specify how dates are handled (e.g., format, default to today). This extra semantic hint compensates slightly, earning a score above the baseline of 3.

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

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

The description clearly states the tool's purpose: 'Get stock P/E ratio, dividend yield and P/B ratio by date query.' It specifies the verb ('Get'), resource ('stock P/E ratio, dividend yield and P/B ratio'), and scope ('by date query'). However, it doesn't explicitly differentiate from sibling tools like 'get_stock_valuation_ratios' (which appears to be similar but without the date query specification), so it falls short of a perfect score.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions 'by date query' but doesn't clarify if this is for a specific date, date range, or how it compares to other valuation tools in the sibling list (e.g., 'get_stock_valuation_ratios'). There's no mention of prerequisites, exclusions, or recommended contexts, leaving usage ambiguous.

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