Skip to main content
Glama
Sign In

Ava Advisor

by fund.ava
OverviewDiscussionsAdmin

Company Relationships

relationships
Read-only

Competitors + peers of a company (news-derived relationship graph). limit caps EACH list (default 15, max 50). Each side carries total/count/note — a big total (peers often run to hundreds) means you're seeing a TOP slice; say so rather than implying it's the complete set.

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": {
      "ticker": "<ticker>"
    },
    "name": "relationships"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMax competitors + peers each (default/cap per _lim).
tickerYesA Ava Advisor ticker OR a company/asset NAME — the SERVER resolves it (no lookup step). A COMPANY/proper NAME passes AS-IS in any language (茅台/トヨタ/삼성 resolve natively — never translate a name); a generic COMMODITY/SECTOR concept must be ENGLISH (黄金→'gold', 原油→'crude oil'). Pass the user's full request in `context` to disambiguate ('apple' company vs fruit); if still ambiguous you get a `needs_confirmation` with candidates — resolve from conversation or ask, then re-call. Exact tickers pass through (Ava Advisor suffixes: Korea .KO, Taiwan .TW, commodity .COMM, crypto .CC, FX .FOREX, bond .GB, rate .MM).
contextNoOPTIONAL but RECOMMENDED — paste the user's FULL request VERBATIM (any language: 'ขอราคาผลไม้ apple', 'compare Apple and Microsoft stock'). The server uses it to disambiguate which candidate each `ticker` entity means (the apple COMPANY vs the fruit COMMODITY; which Samsung). One context per call, shared by all tickers here.
countryNoOPTIONAL market disambiguator — pass ONLY when `ticker` is a plain NAME that collides across markets (the Thai vs Korean 'KBANK'); omit for a distinctive name or an exact ticker (an unneeded country silently 0-matches). A country NAME or ISO-2 code ('South Korea'/'KR'); the server normalizes, so pass the NAME when unsure — never GUESS a 2-letter code ('CH' = Switzerland, not China).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description's job is to add context beyond safety, and it does: the graph is news-derived, `limit` applies per list not globally, and each side returns total/count/note. It also warns that a large total means a top slice only — meaningful behavioral guidance about the completeness of results that annotations cannot convey.

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?

Three short sentences, front-loaded with what the tool returns, then limit semantics, then the reporting caveat. Tight and free of filler; only minor cost is that the caveat sentence is dense with inline field names.

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?

With no output schema, the description does the work of explaining return shape (total/count/note per side), which is exactly what an agent needs. It is complete for a read-only two-list lookup; it could only be stronger with an explicit pointer to sibling tools for broader theme or sector membership.

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 baseline is 3. The description does add real meaning for `limit` that the schema leaves vague ('default/cap per _lim'): default 15, max 50, and that it caps EACH list independently — a genuine clarification, but it says nothing about `ticker`, `context`, or `country` beyond what the schema already states.

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?

States a specific resource and relationship: competitors and peers of a company, with the qualifier that the graph is news-derived. An agent can distinguish it from quote or news tools, though it does not explicitly name a sibling (e.g. theme_players) as the alternative.

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?

Usage is implied by the resource description — call it when the user wants competitors/peers of one company. There is no explicit when-to-use vs when-not-to-use guidance and no named alternative tool for adjacent needs like sector peers via theme_players.

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

All Ava Advisor 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