Stonewake

Portfolio funds look through

portfolio_funds

Read-onlyIdempotent

The funds of the caller team's Depot A, looked through to their constituents. Without fund_id it lists the live funds, the weakest fund first, each with its ISIN or LEI, the as of date the fund's manager states, how many lines resolved to a company, the weight per standing and the weakest standing. With fund_id it returns that fund's constituents weakest first: line, isin, lei, the name in the file (never used to match), weight in percent, resolution (resolved, conflict, ambiguous or unresolved, from the GLEIF and ANNA ISIN to LEI map, ESMA and FCA FIRDS or the stated LEI) with its reason, basis and cited evidence, the matched company, and its standing: the credit status in the team's book (red, amber, insufficient, green, not_assessed, sole_trader), unmatched for a line not resolved (never guessed) or not_in_book. An in book constituent carries its score, top signals and newest daily press tone reading. Weakest first is red, amber, unmatched, insufficient, the honesty states and green last, the more negative press tone first within a standing, then the larger weight. Lines page with limit and offset. A fund outside the team answers 404. Read only.

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": "portfolio_funds"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size, default 100, maximum 100.
`offset`	No	Rows to skip, default 0.
`fund_id`	No	The fund's id; omit to list the funds.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, closed-world and non-destructive, so the safety profile is carried elsewhere. The description does add genuine behavioral context beyond that: the weakest-first ordering rule and its tiebreakers, the 404 for out-of-team funds, and the resolution methodology and evidence sources. However, the many domain labels ('standing', 'honesty states', 'the team's book') are used without definition, which limits how much an agent can actually predict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, which is good, but the body is one dense run-on paragraph packing ordering rules, resolution taxonomy and field inventories. Much of it is useful, yet the jargon-dense phrasing ('the honesty states', 'the weight per standing') forces re-reading rather than being skimmable.

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?

No output schema exists, so the description must carry the return shape, and it does: both modes enumerate their fields, ordering, tiebreakers, paging and the 404 case. It falls short only on the undefined domain vocabulary, which an agent would need in order to interpret the returned standings correctly.

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?

Schema coverage is 100% and already documents limit/offset defaults and maxima, so the baseline is 3. The description goes further by explaining that fund_id is a mode switch (omit to list funds, supply to get constituents) and that pagination applies to constituent lines specifically, which is meaning the schema does not convey.

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 and resource ('the funds of the caller team's Depot A, looked through to their constituents') and cleanly splits the two operating modes by fund_id presence. An agent can distinguish it from sibling tools like portfolio_book or portfolio_overview without opening any schema.

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?

Clear usage context: omit fund_id to enumerate live funds, supply fund_id to get that fund's constituents, plus the 404 rule for out-of-team funds. It does not explicitly name sibling alternatives (portfolio_book, portfolio_overview) or when to prefer them, so the routing guidance is contextual rather than explicit.

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

All Stonewake 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.

Resources

Need Help?