Tensorust Ontology

Q3 2026 loan markdowns as BDCs file

credit_q3_cuts

Read-only

Live through earnings season: BDC funds that cut a first-lien loan's mark by 5+ points from Jun 30 to Sep 30 2026, pulled from each Q3 10-Q on EDGAR the day it is filed, biggest cut first, with the holders that have not filed Q3 yet and still carry the same loan 5+ points higher (likely next markdowns). Free: the top 10. full=true: every cut with every pending holder with a Tensorust key.

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": "credit_q3_cuts"
  }
}

Input Schema

Name	Required	Description	Default
`full`	No	true returns every cut and pending holder. Needs a Tensorust key (Authorization: Bearer tdk_...).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / full / description

Previous value: -"true returns every cut and pending holder. $0.25 per call over x402, or free with a Tensorust key."New value: +"true returns every cut and pending holder. Needs a Tensorust key (Authorization: Bearer tdk_...)."

AddedNov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare a safe read-only, closed-world operation, and the description adds real context beyond them: the upstream source (each Q3 10-Q, pulled the day it is filed), the sort order (biggest cut first), the free-tier truncation to 10 results, and the Tensorust bearer-key requirement for full=true. It stops short of describing record fields or how pending holders are matched to cut loans, which is the main remaining ambiguity.

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?

It front-loads the framing and then packs scope, source, sort order, and tiering into two dense sentences with no filler. The run-on construction with parentheticals is harder to parse than it needs to be, but nothing is wasted.

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?

For a single-boolean, read-only tool with no output schema, the description covers what is returned, how it is ordered, how results are truncated, and what auth the paid tier needs. The one gap is the shape of each returned record (which holder/loan/mark fields appear), which the absence of an output schema leaves undocumented.

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 coverage is 100% and the `full` parameter already carries its own description including the auth requirement. The description restates the same free/full distinction with slightly more operational detail ("top 10" vs "every cut with every pending holder"), so it is consistent but largely duplicative of the schema.

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 a precise verb and resource: BDC funds that cut a first-lien loan's mark by 5+ points between Jun 30 and Sep 30 2026, sourced from Q3 10-Q filings on EDGAR. It also distinguishes itself from the related sibling lender_marks by adding the pending-holder / next-markdown angle, so an agent can pick between them without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Live through earnings season" implies the use context, and the free-vs-full split tells the agent which tier to request, but there is no explicit statement of when to use this tool over siblings such as lender_marks or credit_disagreements, and no when-not guidance. Usage is inferable rather than stated.

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

All Tensorust Ontology 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?