Skip to main content
Glama
Sign In
Andru

Andru

by geter-andru
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Portfolio readiness scorecard

get_portfolio_readiness_rollup

Achieve portfolio oversight by generating a standardized Revenue Readiness Index for all managed companies. View overall risk, including at-risk counts and customer-concentration exposure, across your entire fund.

Instructions

Portfolio oversight: use this when a PE or VC operator wants a scorecard across all their portfolio companies, or asks which company is most at risk. Returns each company's Revenue Readiness Index, comparable across companies, with the average, the at-risk count and customer-concentration risk. Paid. Check the price with quote before running.

Input Schema

NameRequiredDescriptionDefault
quoteIdNoOptional: the quote_id from quote, to pay the quoted price (held for 30 minutes).
portfolioIdYesThe portfolio to roll up. whoami lists yours with their ids.
idempotencyKeyNoOptional: any unique string for this call. Retrying with the same key returns the first result and never charges twice.
maxAmountCentsNoOptional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.9
    • addedInput schema / properties / idempotencyKey
      Added value: +{
+  "description": "Optional: any unique string for this call. Retrying with the same key returns the first result and never charges twice.",
+  "type": "string"
+}
    • addedInput schema / properties / maxAmountCents
      Added value: +{
+  "description": "Optional: the most this call may cost, in cents. If the price is higher, nothing runs and nothing is charged.",
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / portfolioId / description
      Previous value: -"The portfolio to roll up. Must belong to the caller."New value: +"The portfolio to roll up. whoami lists yours with their ids."
    • addedInput schema / properties / quoteId
      Added value: +{
+  "description": "Optional: the quote_id from quote, to pay the quoted price (held for 30 minutes).",
+  "type": "string"
+}
  2. Addedv1.4.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true but say nothing about billing; the description fills exactly that gap by flagging the tool as Paid with a mandatory quote step. It also discloses the comparison semantics ('comparable across companies'), which is behavioral context an agent needs to interpret results. Minor omissions: no mention of the 30-minute quote hold, idempotency, or the maxAmountCents cap that the schema carries.

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?

Three tight sentences: use case first, return contents second, payment prerequisite last. The 'Portfolio oversight:' prefix is a small category tag but no sentence is redundant or padded.

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 carries the return-value burden and does so by enumerating the per-company index, the average, at-risk count, and concentration risk. The paid/quote flow is also covered. It could still say more about cost variability or what happens when portfolioId is invalid, but nothing critical for correct invocation is missing.

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?

Schema description coverage is 100%, so every parameter is already documented in structured form — baseline 3. The description adds nothing about portfolioId sourcing (whoami), quoteId, idempotencyKey, or maxAmountCents beyond what the schema already says, though its 'comparable across companies' note helps interpret results.

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 — a portfolio-level readiness 'scorecard' — and explicitly scopes it to 'across all their portfolio companies,' which cleanly separates it from the single-company sibling assess_company_readiness. It also names the concrete output (Revenue Readiness Index per company, average, at-risk count, concentration risk).

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 a clear triggering persona and situation ('PE or VC operator wants a scorecard across all their portfolio companies, or asks which company is most at risk') plus a prerequisite workflow ('Check the price with quote before running'). It stops short of stating when NOT to use it (e.g., a single company → assess_company_readiness), so the exclusion is only implicit.

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

Deploy Server

Other Tools