Skip to main content
Glama

Manawa Terminal

Search financial data

finance_search
Read-only

Search financial data and return an answer with an inline widget.

Covers stocks, macro, forex, crypto, commodities, earnings, technicals,
and related market questions. Pass the user's question in `query` without
rephrasing.

To screen a named watchlist or portfolio, call list_watchlists or
list_portfolios first, then pass the symbols here with filter criteria in
`query`.

Exclusive modes when a Deep Dive exists:
  focus=ai + section=… → narrative section
  focus=raw + source=… → thin data slice
  focus=catalog → list available Deep Dives

Args:
    query: The user's financial question
    symbols: Optional ticker universe to screen (e.g. from list_watchlists)
    section: Optional Deep Dive section (competition, valuation, thesis,
        forecast, analyst_consensus, people, financials, earnings,
        technicals, overview, moves)
    focus: Optional exclusive mode: ai | raw | auto | catalog
    source: Optional thin raw slice when focus=raw (comparison_peers,
        price_targets, consensus, quote, key_financials, …)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
focusNo
queryYes
sourceNo
sectionNo
symbolsNo

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it returns an inline widget, covers multiple asset classes, and details exclusive modes when Deep Dives exist. It also advises passing the user's question 'without rephrasing.' No contradiction with annotations exists.

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

Conciseness5/5

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

The description is well-structured and dense with information. It uses bullet points and code formatting for modes and arguments, making it easy to scan. Each sentence contributes value, from the opening summary to the parameter definitions. There is no repetition or filler.

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

Completeness4/5

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

Given the tool's complexity (5 parameters, exclusive modes) and the absence of an output schema, the description is largely sufficient. It explains the return is 'an answer with an inline widget' but does not specify the widget's structure or behavior on empty results. Minor gaps remain, but overall it provides enough context for an agent to invoke the tool correctly.

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

Parameters5/5

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

The schema has 0% description coverage, but the description fully compensates with an Args section explaining every parameter. It describes query, symbols, section (with enumerated values), focus (ai|raw|auto|catalog), and source (with examples). This adds far more meaning than the bare schema titles and types.

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

Purpose5/5

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

The description clearly states the tool's function: 'Search financial data and return an answer with an inline widget.' It specifies the resource (financial data) and scope (stocks, macro, forex, crypto, commodities, earnings, technicals). This distinguishes it from the sibling tool 'search_library', which presumably searches library items, by the type of data queried.

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

Usage Guidelines4/5

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

The description provides explicit workflows: 'To screen a named watchlist or portfolio, call list_watchlists or list_portfolios first, then pass the symbols here...' It also explains when to use focus/section/source modes. However, it does not explicitly mention alternatives like search_library for library searches, so it lacks a full 'when-not-to-use' statement.

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.

TDQS

A3.8/5.0
Disambiguation5/5

Each tool targets a distinct resource and action. Portfolio, alert, watchlist, library, journal, and search tools have clearly separated purposes with no overlapping functionality. Even similar tools like get_portfolio_statistics and get_positions provide different outputs.

Naming Consistency4/5

The majority follow a clear verb_noun pattern in snake_case (e.g., create_portfolio, delete_library_item). However, 'finance_search' inverts the verb-noun order and 'run_deepdive' uses a less common verb, creating minor but noticeable exceptions.

Tool Count4/5

31 tools is on the high side but each serves a distinct purpose across portfolio management, alerts, watchlists, library, journal, search, and bug reporting. The library subsystem alone accounts for 11 tools (CRUD + versions + move + rename + search), which is justifiable for a full document manager.

Completeness3/5

Core operations are present but several lifecycle gaps exist: no delete_watchlist, delete_portfolio, update_portfolio, update_alert, or delete_transaction. The journal and deepdive areas also lack update/delete capabilities. Agents may hit dead ends when trying to remove or modify certain resources.

Resources