Skip to main content
Glama

Hundo

by finance.hundo
OverviewDiscussionsAdmin

get_assets

Read-only

List the user's assets (crypto, stocks, real estate, vehicles, trading cards, etc.) with quantity, purchase price, latest market valuation, and P&L - the same numbers the app's net-worth page shows. costBasis, pnl, realizedPnl, and avgCostPerUnit are in the user's base currency; costBasis is the blended total cost (per-trade history included) and avgCostPerUnit is costBasis/quantity - use avgCostPerUnit for any 'average cost per share' question, NOT purchasePrice (which is only the fallback for units without recorded trades). purchasePrice and latestValuation.value are per-unit in the asset's own currency. All monetary fields are in major units. pnl is null only when no market price/valuation or exchange rate is available for the asset. Name an asset by displaySymbol when it has one; for a trading card (type 'collectible') symbol is an internal key, never a name to show.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoFilter by asset type. Omit to return all. 'collectible' is the user's trading cards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / type / description
      Previous value: -"Filter by asset type. Omit to return all."New value: +"Filter by asset type. Omit to return all. 'collectible' is the user's trading cards."
    • changedInput schema / properties / type / enum
      Previous value: -[
-  "crypto",
-  "stock",
-  "real_estate",
-  "vehicle",
-  "commodity",
-  "bond",
-  "other"
-]New value: +[
+  "crypto",
+  "stock",
+  "real_estate",
+  "vehicle",
+  "commodity",
+  "bond",
+  "other",
+  "collectible"
+]
  2. First observed

TDQS

A4.1/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint annotation, disclosing detailed data semantics: currency distinctions (base vs. per-unit), cost basis calculation methods, fallback behavior for purchasePrice, null conditions for pnl, and naming conventions for displaySymbol vs. internal keys. This rich behavioral disclosure prepares the agent for accurate interpretation of results.

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?

The description is lengthy but every sentence adds substantive value, covering purpose, field meanings, currency handling, null behavior, and naming. It is front-loaded with the primary action, then systematically details nuances. While dense, it avoids redundancy and is well structured for its complexity.

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 compensates by specifying key return fields and their semantics, including currency, null cases, and naming. It does not mention pagination, ordering, or limits, but for a tool that lists assets these are minor gaps. The description is comprehensive enough for correct invocation and interpretation.

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 parameter 'type' is fully documented in the schema with an enum and description, so the schema already provides complete parameter semantics. The tool description does not add any new information about this parameter beyond what the schema states, meeting the baseline for 100% schema coverage.

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 states the verb ('List'), the resource ('the user's assets'), and enumerates the asset types (crypto, stocks, real estate, etc.) plus the returned fields (quantity, purchase price, latest market valuation, P&L). It also ties it to the app's net-worth page, making the tool's role unambiguous and distinct from siblings like get_net_worth.

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?

The description implies usage context by referencing the net-worth page and detailing asset-level data, but it does not explicitly state when to use this tool versus alternatives such as get_net_worth or get_accounts. No exclusions or conditions are given, so an agent must infer the appropriate scenario.

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

All Hundo 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