FinBridge

My Portfolio

get_portfolio

Read-only

Return the holdings this user has already registered in FinBridge with import_portfolio — listed stocks plus cash, crypto, ETF and physical assets — valued at the latest prices, with return and asset allocation. A user who has registered nothing gets an empty list.

Not this tool for: analysing or valuing a company (get_valuation), prices (get_stock_prices), or finding companies (screen_companies). It reads only what this user stored, so it knows nothing about a company they do not hold.

Crypto and ETFs use live ccxt quotes, stocks the latest close in the database, cash and physical assets the registered amount. allocation is aggregated per currency; combined converts everything to KRW using an ECB-derived USD/KRW rate.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`count`	No
`error`	No
`notes`	No
`combined`	No
`holdings`	No
`allocation`	No
`total_value`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 7, 2026

addedOutput schema / properties / combined

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "properties": {},
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark the tool read-only, and the description adds valuable behavioral context beyond that: pricing sources differ per asset class (live ccxt quotes for crypto/ETFs, latest database closes for stocks, registered amount for cash and physical assets), allocation is aggregated per currency, and combined totals convert to KRW via an ECB-derived USD/KRW rate. This gives the agent a clear model of side effects, dependencies, and edge cases.

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 structured: main purpose is front-loaded, followed by empty-case behavior, explicit alternatives, and then helpful technical details. Every sentence carries meaningful information, and there is no fluff or repetition.

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 and no parameters, the description covers all necessary invocation context: what is returned, how values are sourced, under what conditions it returns an empty list, and which sibling tools should be used instead. No critical gap remains.

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?

The tool has zero parameters and an empty input schema, so there are no parameter semantics to add. The no-parameters baseline is 4, and the description does not need to explain anything more for invocation.

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 states exactly what the tool does with a specific verb and resource: 'Return the holdings this user has already registered in FinBridge with import_portfolio', listing all asset types and valuation aspects. It also explicitly distinguishes itself from sibling tools by naming get_valuation, get_stock_prices, and screen_companies as what it is not for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives unambiguous when-to-use and when-not-to-use guidance by naming the alternatives ('Not this tool for: analysing or valuing a company (get_valuation), prices (get_stock_prices), or finding companies (screen_companies)') and states the limiting condition that it only reads what the user stored. The empty-list case is also explicitly handled.

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

All FinBridge tools Inspect

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.