Skip to main content
Glama
Sign In

Finance Database

by io.github.JerBouma
OverviewDiscussionsAdmin

search_instruments

Read-onlyIdempotent
    Find which instruments exist in the Finance Database by ticker, name or ISIN,
    across equities, ETFs, indices, currencies and cryptocurrencies at once, with
    their symbol, exchange and classification (no prices or financial data).

    Matches are case-insensitive substrings of the symbol or name (plus exact
    ISIN/CUSIP/FIGI matches), ordered by relevance: exact symbol first, then
    symbols and names starting with the query, primary listings and larger
    companies first. Each row says which asset class tool has the full record.

    Returns:
        str: Compact JSON with the matches and their total count per asset class.

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_instruments"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoRows to return (default 25, maximum 200).
queryYesTicker, (part of a) name or identifier to look up, e.g. 'AAPL', 'apple', 'S&P 500', 'bitcoin' or an ISIN such as 'US0378331005'. Case-insensitive.
offsetNoRows to skip, for paging.
asset_classesNoAsset classes to search: 'all' (default) or one or more of equities, etfs, indices, currencies, cryptos (comma-separated).all
include_delistedNoInclude delisted equities and ETFs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnly/idempotent/openWorld, but the description adds substantial behavioral detail: case-insensitive substring matching on symbol or name, exact ISIN/CUSIP/FIGI matching, and a precise relevance ordering (exact symbol, then prefix matches, primary listings, larger companies). It also discloses that rows point to the asset-class tool holding the full record, which is behavior no annotation conveys.

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?

Front-loaded with the capability, then matching semantics, then ordering, then return shape — a logical progression with no filler. Minor redundancy: the asset-class list restated in prose duplicates the schema's enum-like description, and the typed 'Returns: str:' line is slightly formal for the amount of information it carries.

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

Completeness5/5

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

With no output schema, the description correctly fills the gap by describing the return as compact JSON with matches and per-asset-class counts, and it explains ordering so the agent can interpret row priority. For a five-parameter read-only search tool, nothing an agent needs in order to call or interpret it is missing.

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 coverage is 100%, so the schema already documents limit, offset, asset_classes and include_delisted. The description adds real meaning for the query parameter (substring vs exact-identifier semantics, case-insensitivity) but says nothing extra about the paging or asset-class parameters beyond what the schema states, so the baseline 3 applies.

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?

States a specific verb and resource ('Find which instruments exist in the Finance Database') and enumerates the covered asset classes (equities, ETFs, indices, currencies, cryptos). It distinguishes itself from the asset-class siblings by searching 'at once' and by noting each row names the asset-class tool holding the full record.

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?

Clear context for use: cross-asset-class discovery by ticker, name or identifier, with an explicit exclusion ('no prices or financial data') and a routing hint to the per-asset-class tools for full records. No explicit named alternative or hard when-not statement, 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.

All Finance Database toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources