Skip to main content
Glama

portfolio_cashflow

Read-onlyIdempotent

A portfolio's cashflow against its baselines, per month, in the organization's default currency. baseline: each project's chosen baseline (its latest, or baselineId for that one project), its tasks' planned cost spread over their baseline dates. forecast: expected and committed cost lines on their dates plus the cost still to spend on unfinished tasks over their remaining dates. actual: spent cost lines, approved expense claims and timesheet labour on their days. variance is actual plus forecast minus baseline (positive is above the baseline); the cumulative figures include what fell before the range (beforeRange). unscheduled is task cost with no dates to place it. A project whose cost the caller may not read is listed with costHidden and left out of every figure (costHiddenCount). unconvertedCurrencies names currencies with no rate, counted at face value. from and to are months, YYYY-MM, at most 120 apart; omitted, they span the projects' dates. Each project carries its totals; pass includeProjectMonths for its months too. Requires the portfolios feature and org.portfolio.manage.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "portfolioId": "<portfolioId>"
    },
    "name": "portfolio_cashflow"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLast month, YYYY-MM.
fromNoFirst month, YYYY-MM.
baselineIdNoA baseline of one of the portfolio's projects, used for that project instead of its latest.
portfolioIdYes
includeProjectMonthsNoEach project's figures per month as well as its totals.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent safety profile, and the description adds substantial behavior: permission-gated projects are listed but excluded from all figures (costHidden/costHiddenCount), currencies with no rate are counted at face value (unconvertedCurrencies), unscheduled costs are separated out, and beforeRange is included in cumulative figures. This is exactly the edge-case disclosure an agent needs to interpret results correctly.

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, then definitions in a logical order (baseline, forecast, actual, variance, then edge cases, then params, then requirements). However, it is a dense wall of semicolon-joined clauses; the run-on sentences around variance/cumulative could be tightened without losing meaning.

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 no output schema, the description carries the return-value burden and does so: it defines variance (actual + forecast − baseline, positive above baseline), cumulative inclusion of beforeRange, unplaceable costs, hidden-cost handling, unconverted currencies, and the fact that projects carry totals unless includeProjectMonths is set. Nothing essential for correct invocation or interpretation appears 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?

Adds real meaning beyond the 80%-covered schema: from/to default to the projects' dates and are capped at 120 months apart, baselineId overrides the latest baseline for exactly one project, and includeProjectMonths toggles per-project monthly breakdowns in addition to totals. portfolioId itself is left undefined (presumably 'the portfolio'), a minor gap.

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?

Opens with a specific verb+resource+scope: 'A portfolio's cashflow against its baselines, per month, in the organization's default currency.' That distinguishes it from the sibling portfolio_summary (general rollup) and revenue_at_risk by naming the exact computed artifact (cashflow vs. baselines) and the granularity (per month).

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?

Gives clear operating context: from/to are optional and default to spanning the projects' dates, max 120 months, and it states the prerequisites ('Requires the portfolios feature and org.portfolio.manage') plus the includeProjectMonths opt-in. It does not explicitly compare itself to alternatives like portfolio_summary, calculate_evm, or revenue_at_risk, so an agent must infer when this is the right tool vs. those.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.