Skip to main content
Glama

groundcheck

by io.github.beepboop2025

Resolve a security to FIGI

resolve_instrument
Read-onlyIdempotent

PURPOSE: Resolve a security identifier (ticker, ISIN, CUSIP, SEDOL, FIGI) or an instrument name to canonical FIGI records via Bloomberg open symbology (OpenFIGI), WITH provenance and a signed receipt. Returns {matched, instruments: [...], provenance}. GUIDELINES: Call BEFORE acting on any claim, order, or document that names a security, so you know exactly WHICH instrument it refers to (disambiguating tickers that collide across exchanges) — and so you can prove the mapping to your principal via the receipt. Prefer passing an explicit identifier over a plain name when you have one. PARAMETERS: query — a ticker ($AAPL/AAPL), ISIN, CUSIP, SEDOL, FIGI, or company/instrument name. id_type — optional; auto-detected from the value's shape when omitted. max_results — 1..10, default 5. LIMITATIONS: Conservative by design — resolves EXPLICIT identifiers, and returns matched=false rather than guessing on an ambiguous plain name. Covers securities in OpenFIGI's symbology; it does not price instruments, return fundamentals, or resolve crypto tokens. Paid per call (x402). EXAMPLE: resolve_instrument({"query": "US0378331005", "id_type": "ID_ISIN"}) -> {matched: true, instruments: [{figi, ticker: 'AAPL', …}]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesTicker, ISIN, CUSIP, SEDOL, FIGI, or instrument name.
id_typeNoOptional identifier type; auto-detected from the value's shape (e.g. 12-char alphanumeric -> ISIN).
max_resultsNoMax canonical records to return (1-10).

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds substantial behavior: conservative by design, returns matched=false rather than guessing, covers only OpenFIGI symbology, does not price or resolve crypto, and is paid per call. This goes well beyond the annotations.

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-organized with labeled sections (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE), front-loading the core purpose. Every sentence contributes value, with no redundant filler, and the example aids quick comprehension.

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?

Despite no output schema, the description explicitly states the return structure (matched, instruments, provenance). It covers purpose, usage, limitations, and parameters, providing enough context for an agent to select and invoke the tool effectively. The example further anchors real usage.

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?

Input schema descriptions cover 100% of parameters, so baseline is 3. The description reiterates parameter meanings and adds an example call, but does not introduce significant new semantic detail beyond the schema. The auto-detection note appears in both places.

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 uses a specific verb 'resolve' with the resource 'security identifier or instrument name' and target 'canonical FIGI records' via OpenFIGI. It also highlights unique outputs like provenance and a signed receipt, clearly distinguishing it from sibling tools such as verify_claim or extract_claims.

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 explicitly instructs 'Call BEFORE acting on any claim, order, or document that names a security' and advises preferring explicit identifiers. It also notes what the tool does not do (e.g., pricing, crypto). However, it does not explicitly name alternative sibling tools, so it stops short of the top criterion.

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

All groundcheck toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: claim verification (single vs batch), claim extraction, identifier resolution, and delivery attestation. The batch vs single claim tools are distinguished by input granularity, resolving any potential confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (attest_delivery, check_citations, extract_claims, resolve_instrument, verify_claim). This predictable convention makes the tool set easy to navigate.

Tool Count5/5

Five tools is well-scoped for a verification/attestation service. Each tool covers a distinct stage (extract, verify, attest, resolve) without redundancy or bloat.

Completeness5/5

The tool set provides complete coverage of the verification workflow: extraction (extract_claims), single and batch verification (verify_claim, check_citations), identifier resolution (resolve_instrument), and delivery attestation (attest_delivery). Signed receipts enable offline verification, leaving no obvious gaps.

Resources