Skip to main content
Glama
Sign In

CULT+MATH Decision Briefs

by com.cultmath
OverviewDiscussionsAdmin

Has anyone started reporting this number?

run_disclosure_check
Read-onlyIdempotent

Use when the user asks whether any company, or which of a named set of competitors, now reports a figure (a franchise share, ARPU, a retention rate, a concentration, a multiple), or whether a public comparable discloses the metric a deal model depends on. Returns, from SEC EDGAR full-text search, which filers use the phrase in their filings over the years given, with the first and latest filing linked; for named peers, who does, who does not, and who could not be measured because they filed nothing. Safe to cite: its controls are checked first, it states its limits, and every result carries a run id, a date and a citation line. If a control fails it refuses and you are not charged. This tool charges nothing: it validates the request and returns a payment_url, the price and instructions. Pay by POSTing to payment_url over MPP (HTTP 402, a Stripe shared payment token from your wallet). Price: $2.00 per run, charged only when the run comes back sound; pay over MPP (a Stripe shared payment token) or x402 (USDC on Base, no account needed). A real sample of this run, free: https://cultmath.com/agent/samples/disclosure-check.json

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": {
      "phrase": "<phrase>"
    },
    "name": "run_disclosure_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoLast year. At most 10 years per run.
formNoFiling type. Default 10-K.
peersNoOptional: 2-10 tickers, comma-separated, from: PEP, KO, K, POST, KDP, CELH, UTZ, HRL, GIS, KHC, CAG, CPB, HSY, MDLZ, SJM, CLX, CL, CHD, PG, SMPL, BRBR, MSFT, EA, TTWO, RBLX, OMC, STGW, CRM, HUBS, TDOC, TALK, GDDY, GEN, NFLX, AMZN. Omit to search all filers.
startNoFirst year. Default: two years ago.
phraseYesThe phrase to measure, without quote marks.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), it discloses meaningful behavior: controls are checked first, it refuses and does not charge on control failure, every result carries a run id/date/citation line, and it states its limits. The payment flow (validate → payment_url → pay via MPP/x402) is disclosed, though the 'charges nothing' vs '$2.00 per run' framing is somewhat convoluted and could confuse an agent.

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?

The opening trigger and the SEC EDGAR explanation are front-loaded and useful, but the description is bloated with pricing mechanics, payment-rail details, and a sample URL that dilute the core definition. Several sentences could be trimmed without losing calling guidance.

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 does the job of explaining returns: linked first/latest filings for the phrase, and for named peers who does, does not, and could not be measured. Combined with pricing and control behavior, an agent has enough to call it correctly; only minor ambiguity in the payment framing remains.

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 the schema already documents every parameter including the enum and per-peer ticker list. The description adds return semantics (first and latest filing linked, who does/doesn't/couldn't be measured) but little extra meaning about the parameters themselves. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource — it checks whether company filers report a given figure/phrase via SEC EDGAR full-text search — and enumerates the kinds of metrics it covers (franchise share, ARPU, retention rate, concentration, multiple). An agent can tell what it does. It does not explicitly name a sibling to distinguish from, so it stays at 4 rather than 5.

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 opens with an explicit trigger: 'Use when the user asks whether any company, or which of a named set of competitors, now reports a figure...'. It also clarifies the peers-vs-all-filers choice in the schema. There is no when-not-to-use guidance or named alternative tool, keeping it below 5.

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

All CULT+MATH Decision Briefs toolsInspect
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