Skip to main content
Glama

Amaltash Investment & Retirement Calculators

Search stocks

search_stocks
Read-onlyIdempotent

Finds US stocks and funds by ticker or company name. Used by the calculator card's stock picker.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_stocks"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesA ticker or part of a company name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine scope constraint — results are limited to US stocks and funds — but says nothing about ranking, result limits, or behavior on no-match, which is the remaining behavioral gap.

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?

Two short sentences, front-loaded with the capability before the consumption context. The second sentence is useful orientation rather than filler, though it is framed as internal UI detail rather than agent-facing guidance.

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

Completeness3/5

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

The tool is simple (one required, fully documented parameter) and the annotations carry the safety semantics, so little is strictly missing. Still, an agent gets no signal about result volume, ordering, or what happens when a non-US or unmatched query is supplied.

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 single 'query' parameter is already documented as 'A ticker or part of a company name.' The description restates that meaning without adding format, casing, partial-match, or minimum-length guidance, so the baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource ('Finds US stocks and funds') plus the two lookup keys ('by ticker or company name'), which is clearer than the name alone. It does not explicitly distinguish itself from a sibling like list_assets, so it falls short of the top mark.

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

Usage Guidelines3/5

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

'Used by the calculator card's stock picker' implies the context in which an agent should reach for it, but there is no explicit when-to-use versus when-not guidance and no named alternative (e.g. list_assets) for browsing instead of searching.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources