Skip to main content
Glama
Sign In
@thryx/mcp-server

@thryx/mcp-server

by lordbasilaiassistant-sudo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

thryx_portfolio

Scan your entire wallet portfolio for every token holding with live prices and PnL. Use this when you need per-token detail.

Instructions

Full portfolio scan for your wallet — every token holding with live prices and PnL. Requires THRYX_API_KEY. Heavier than thryx_balance; call when you need per-token detail.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "thryx_portfolio"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses a key prerequisite ('Requires THRYX_API_KEY') and a performance characteristic ('Heavier than thryx_balance'). It does not explicitly state read-only behavior, but 'portfolio scan' and the return specification strongly imply it.

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 two sentences, front-loaded with the core purpose, and every sentence adds value: the first defines the tool, the second adds prerequisites and comparative usage. No wasted words.

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?

For a parameterless tool with no output schema, the description covers the essential return content (token holdings, live prices, PnL) and usage context (API key, heavier than balance). It is sufficiently complete, though it could include a note about output format or limits, but these are not critical.

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

Parameters4/5

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

There are zero parameters, so the schema is empty and coverage is effectively 100%. Per the rubric, a baseline of 4 is appropriate since there are no parameter semantics to clarify.

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 identifies the action ('Full portfolio scan') and the resource ('your wallet'), and specifies what it returns ('every token holding with live prices and PnL'). It explicitly distinguishes itself from the sibling tool thryx_balance with 'Heavier than thryx_balance.'

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 clear usage context: 'call when you need per-token detail' and contrasts with thryx_balance by noting it is 'Heavier' (i.e., more resource-intensive). It also notes the prerequisite API key. While it doesn't explicitly list exclusions, it implies when not to use it (if you only need a simple balance).

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

Deploy Server

Other Tools