Skip to main content
Glama

Entity risk profile

entity_risk_profile
Read-onlyIdempotent

The caller team's credit risk view of one company, by its graph node_id (the id search_companies hits carry). Answers one of three honest shapes: not in the portfolio (in_portfolio false), held but not yet assessed (assessment null), or the full current assessment with its status band, score, seen_share, explained_share and reachable_share (the figure the insufficient floor reads), a coverage_line of one to three sentences counting covered signals and gaps with their reasons, and every signal with its state (evidenced, register_quiet, gap, awaiting_bank_input, not_applicable), gap_reason, evidence grade (A to D), evidence value, note, and citation ids. A signal no connected source reaches for the company's jurisdiction is a gap, never not_applicable. A held company also carries entity_class: the class its checks route on (a bank is never scored on corporate distress models) and its source, either your team's analyst override or the register rule that derived it. A sole trader (sole_trader true, a natural person's business by its register's evidence) is never scored: assessment and entity_class are null. Company nodes only; person lookups answer not_found.

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": {
      "node_id": "<node_id>"
    },
    "name": "entity_risk_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
node_idYesThe graph node id, as returned by search_companies. Not the entity_id of company_profile.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / node_id / maximum
      Added value: +2147483647
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent safety profile, and the description adds substantial behavior beyond that: the three possible response shapes with their null semantics, the signal state taxonomy, the rule that unreachable jurisdiction sources are gaps not not_applicable, entity_class derivation and override source, and the sole-trader exclusion. This is exactly the kind of null/edge-case disclosure an agent needs to interpret results.

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 clause is well front-loaded, but the body becomes a very long run-on enumeration of fields, states, and exceptions that is hard to scan. Every element is relevant, yet the structure could be broken into shorter sentences or a shape-by-shape list without losing content.

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?

There is no output schema, so the description carries the full return-value burden, and it does so thoroughly: three answer shapes, field-level semantics for score/seen_share/explained_share/reachable_share, coverage_line, per-signal state and gap_reason, and the not_found case. Nothing material is missing for a single-parameter read tool.

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 schema already explains that node_id comes from search_companies and is not company_profile's entity_id. The description restates that relationship but adds no format, range, or validation detail beyond it, so baseline 3 is appropriate.

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 resource and scope: 'The caller team's credit risk view of one company, by its graph node_id'. It also explicitly distinguishes the identifier from company_profile's entity_id, so an agent can tell which sibling to call without inspecting 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 Guidelines4/5

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

Gives clear context: how to obtain the node_id (search_companies), that only company nodes are valid, and that person lookups answer not_found. It stops short of naming an alternative tool for person risk or for non-portfolio entities, so the routing guidance is implicit rather than explicit.

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.

Resources