Stonewake

Portfolio overview

portfolio_overview

Read-onlyIdempotent

Current health of the monitored portfolio: how many exposures sit in each status band (green, amber, red, insufficient, shown on the dashboard as No score yet, and not_assessed, shown as Not yet assessed) and how many are sole traders (sole_trader: a natural person's business, never scored, so it has no band and no transitions), the active exposure count, the number of transitions in the last 30 days and how many of them are status changes (an exposure's first assessment is an addition to the book, a transition but not a change), and how many exposures have an overdue credit review. Optionally pass transitions_since (an ISO 8601 date-time with a UTC offset) to also list the individual status transitions since that moment, newest first, each with its cause: the signals whose change moved the status, their citation ids, and the register record behind the lead one. limit and offset page those transitions with the exact total (default 50, maximum 100), and either alone lists the newest transitions of any date. Start here for questions like how the book is doing or what changed since a date and why.

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_overview"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size, default 50, maximum 100.
`offset`	No	Rows to skip, default 0.
`transitions_since`	No	Also return status transitions at or after this ISO 8601 date-time with a UTC offset (Z or +01:00), newest first.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026

changedInput schema / properties / transitions_since / description

Previous value: -"Also return status transitions at or after this ISO 8601 date-time, newest first."New value: +"Also return status transitions at or after this ISO 8601 date-time with a UTC offset (Z or +01:00), newest first."

Changed2 schema fields changedOct 25, 2026

addedInput schema / properties / limit

Added value: +{
+  "description": "Page size, default 50, maximum 100.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Rows to skip, default 0.",
+  "maximum": 9223372036854776000,
+  "minimum": 0,
+  "type": "integer"
+}

First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, and the description adds substantive behavior on top: transitions are returned newest first with paging applied only to them, limit bounds are 50/100, and either limit or offset used alone lists the newest transitions of any date. It also disambiguates the domain semantics an agent cannot infer — sole_trader is never scored and has no transitions, and a first assessment counts as an addition, not a status change.

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?

Front-loaded with the purpose and no filler — even the parentheticals (band display names, sole_trader definition, transition-vs-change) carry decision-relevant meaning. The trade-off is density: it reads as one very long sentence, so an agent must parse carefully, but nothing is redundant.

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?

There is no output schema, so the description must carry the return shape and does: every aggregate counter, the band label mapping, and the structure of each returned transition. For a multi-metric aggregate with optional nested results, nothing an agent needs to call it correctly or interpret the response is missing.

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%, so the baseline is 3; the description still adds meaning beyond the schema by stating that transitions_since must carry a UTC offset and that paging returns the exact total. It also clarifies the subtle interaction that limit/offset alone change the result set rather than just paginating, which 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 resource (portfolio health) and enumerates exactly what is returned: band counts with their display names, sole-trader count, active exposure count, 30-day transition count with status-change subcount, and overdue review count. The optional transition listing with causes, citation ids and lead register record is spelled out, and the band/sole_trader definitions let an agent distinguish this aggregate from list-style siblings like portfolio_book.

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?

'Start here for questions like how the book is doing or what changed since a date and why' gives clear routing guidance and implies this is the entry point before drilling into list tools. It does not explicitly name an alternative or an exclusion (e.g. when to prefer portfolio_book or portfolio_reviews_due), so it stops short of a 5.

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?