Skip to main content
Glama

Get Portfolio Analysis

get_portfolio_analysis
Read-only

Paid. Fundamentals profile of a portfolio: allocation-weighted scores for the 8 metrics, each holding's TVR Score and valuation category, and the portfolio TVR Score from TVR's scoring engine (scores only, no prices). $0.08 per call, paid in-band with x402 (USDC on Base) or MPP (USDC.e on Tempo); an unpaid call returns the offer (isError with the x402 PaymentRequired in structuredContent) and charges nothing. Invalid input is refused before any payment. Free alternative: compare_coins. Data from True Value Rankings (truevaluerankings.com).

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": {
      "portfolio": "<portfolio>"
    },
    "name": "get_portfolio_analysis"
  }
}

Input Schema

NameRequiredDescriptionDefault
portfolioYesThe holdings to analyse

Output Schema

NameRequiredDescriptionDefault
errorNo
legalNo
accessNo
reasonNo
statusNo
contextNo
paymentNo
productNo
profileNo
successNo
holdingsNo
disclaimerNo
how_to_payNo
learn_moreNo
redeliveryNo
weights_usedNo
blended_metricsNo
portfolio_tvr_scoreNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / access
      Added value: +{}
  2. Added
  3. Removed
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint/destructiveHint only cover safety), disclosing cost ($0.08/call), payment rails (x402 USDC on Base, MPP USDC.e on Tempo), the unpaid-call behavior (isError with PaymentRequired in structuredContent, nothing charged), and that invalid input is refused before payment. This is exactly the behavioral context an agent needs for a paid call.

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?

Front-loads the key constraint ('Paid.') so cost is known before anything else, then packs output contents, pricing, error behavior, and the free alternative into a handful of dense sentences with no filler.

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 an output schema present, return values need not be explained, and the description instead covers the things the schema can't: payment flow, failure modes, and the cheaper alternative. Nothing an agent needs to invoke this correctly 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?

The single 'portfolio' parameter is fully documented in the schema (100% coverage, including the maxItems 50 cap and allocation normalisation), so the schema carries the load. The description adds only indirect context ('allocation-weighted'), which is baseline-appropriate but not extra parameter meaning.

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+resource ('Fundamentals profile of a portfolio') and enumerates exactly what comes back: allocation-weighted scores for the 8 metrics, per-holding TVR Score and valuation category, and the portfolio TVR Score. It also carves out scope ('scores only, no prices'), which separates it from siblings like get_full_breakdown or compare_coins.

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?

Explicitly names the free alternative (compare_coins) and describes the paid-path mechanics, giving the agent a clear routing signal. It stops short of spelling out the exact condition under which compare_coins is preferable over this paid tool, so the 'when not to use' is implied rather than stated.

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.