Free fundamental analysis of a publicly traded stock. Scores the company against Stoxly's 10-point checklist (P/E, PEG, price/book, revenue growth, ROE, operating margin, return on assets, quick ratio, debt/equity, free cash flow yield) and returns the score, a descriptive verdict, every metric value and a link to the full analysis page.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | Yes | Ticker symbol in Yahoo Finance format, e.g. AAPL, BRK-B, SAP.DE, VOO |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It reveals the scoring methodology (10-point checklist), the output structure (score, verdict, metric values, link), and the 'free' aspect. It does not mention side effects or authentication, but as a read-only analysis tool, the description is sufficiently transparent about 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 a single dense sentence that front-loads the primary purpose ('Free fundamental analysis') before elaborating on the checklist and return value. It contains no unnecessary words, though its length and dense list of metrics could be slightly more readable if split.
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 one parameter and no output schema, the description adequately covers the return value (score, verdict, metric values, link) and the analysis scope. It lacks details on limitations such as data latency or market coverage, but for typical use 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?
The input schema already provides full coverage for the sole 'symbol' parameter with examples. The description does not add any additional parameter semantics or conventions, so it does not exceed the baseline expected when schema coverage is high.
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 stock analysis with a specific verb ('analyzes'), names the resource (publicly traded stock), and details the scoring system (10-point checklist). It inherently differentiates from the sibling analyze_etf by focusing on stocks, making purpose 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?
The description establishes clear context by specifying 'publicly traded stock', implying this tool is for individual equities rather than ETFs. However, it does not explicitly reference the sibling tool or provide when-not-to-use exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The two tools are clearly separated by asset class: ETFs vs. stocks. Descriptions explicitly state the type of security each analyzes, leaving no ambiguity about which tool to use.
Both tools follow a consistent 'analyze_<asset>' naming pattern. This is a predictable and uniform convention.
With only two tools, the server is on the borderline of being too thin. However, the narrow scope of providing security analysis makes the count acceptable, though not substantial.
The tools cover the core analysis functions for stocks and ETFs, returning detailed metrics. A minor gap is the lack of a tool to determine the asset type from a symbol, which could cause friction in workflows.
