LLPRO Campus

Chase capital calls and check payment instructions for a change

capital_call_collection_chasing

Read-onlyIdempotent

Capital call collection chasing for syndicators and small funds. Send the call's due date, optional grace days and chase schedule, and per investor a label, the amount called and the amount received. Get back who is paid, partly paid, due, in grace or overdue, who is due a chase today, the chase dates, and draft wording per stage (nothing is sent). Optionally send the payment instructions printed on the call notice (routing number or IBAN, last 4 of the account, names; never a full account number): you get the routing-number and IBAN check-digit results and a fingerprint; send it back as previous_instruction_fingerprint on the next call to learn whether the instructions changed (the usual sign of payment-redirect fraud). Set check_sources true to also read two public FBI and FinCEN pages and, with sec_cik, the SEC EDGAR record for Form D filings. Free. No model, nothing stored, signed record. Up to 100 investors. Use your own investor labels, not names, emails or account numbers. Not legal, tax or investment advice; your fund documents decide default and remedies.

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": {
      "due_date": "<due_date>",
      "investors": "<investors>"
    },
    "name": "capital_call_collection_chasing"
  }
}

Input Schema

Name	Required	Description
`as_of`	No	Date to evaluate on (default today, UTC).
`sec_cik`	No	SEC CIK of the fund or issuer; with check_sources, reports whether a Form D is on file.
`currency`	No	Three capital letters, e.g. USD (shape only, not checked against the ISO list).
`due_date`	Yes	YYYY-MM-DD payment is due.
`call_date`	No	YYYY-MM-DD the call notice was issued (optional).
`investors`	Yes
`fund_label`	No	Your own label for the fund or deal (not a person).
`grace_days`	No	Days after the due date before an unpaid amount counts as overdue. Your own number from your fund documents (default 0).
`check_sources`	No	Also read the FBI IC3 and FinCEN pages (and EDGAR if sec_cik is sent) and report what they say today.
`fingerprint_salt`	No	Your own secret, the same each time, mixed into the fingerprint so nobody else can reproduce it. Not stored.
`chase_offsets_days`	No	Days from the due date on which to chase (negative = before). Default [-5, 0, 3, 7, 14].
`payment_instructions`	No	The payment instructions printed on the call notice. Never a full account number.
`previous_instruction_fingerprint`	No	instruction_fingerprint from your last check of these instructions.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses that nothing is sent, no model is used, nothing is stored, output is a signed record, there is a 100-investor cap, full account numbers are never accepted, and check_sources triggers live reads of two public FBI and FinCEN pages plus EDGAR. It also explains the fingerprinting mechanism (salt-based, non-reproducible by others) and its anti-fraud purpose, which annotations cannot convey.

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?

The purpose and the 'nothing is sent' guarantee are front-loaded, and nearly every clause carries information (caps, privacy constraints, fraud rationale, sibling reads). The telegraphic, comma-spliced sentences ('Send the call's due date, optional grace days and chase schedule, and per investor a label...') are dense enough to slow parsing, which keeps it from a 5.

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?

For a 13-parameter tool with no output schema, the description fully specifies the return payload: paid/partly paid/due/in grace/overdue status, who is due a chase today, chase dates, draft wording per stage, check-digit results and fingerprints. It also covers limits, storage behavior, and the legal-advice disclaimer, leaving nothing essential unstated for correct invocation.

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 92%, so the baseline is 3, but the description adds genuine meaning: it explains why previous_instruction_fingerprint exists (detect payment-redirect fraud), that fingerprint_salt is a private per-user secret, that payment_instructions must exclude full account numbers, and what check_sources with sec_cik returns. It covers the investors array semantics (label, amount called, amount received) without restating the schema verbatim.

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 concrete verbs and resources: it evaluates each investor's capital-call payment status, produces a chase schedule with draft wording, and optionally checks payment instructions for changes. It also distinguishes the two capabilities (fund collection chasing vs. payment-instruction change detection) and clearly states that nothing is sent, so an agent can tell exactly what it gets back.

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?

It gives clear operating context: free, no model, nothing stored, up to 100 investors, use your own labels not names/emails/account numbers, and set check_sources (plus sec_cik) only if you want the FBI/FinCEN/EDGAR reads. It explains the previous_instruction_fingerprint round-trip pattern. It does not name alternative tools or explicitly say when not to use this one, so it falls 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 LLPRO Campus 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?