Skip to main content
Glama
Sign In

RiskDiff

by com.riskdiff
OverviewDiscussionsAdmin

Get Signal Matches

get_signal

Find added or modified risk sections matching a theme across available 10-K filing comparisons. Returns one entry per company per change type, with a snippet and comparison years. A theme match does not establish that the theme wording itself changed.

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": {
      "signal_id": "<signal_id>"
    },
    "name": "get_signal"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusNo"added" = extracted section unmatched to the prior filing, not necessarily a newly arising risk; "modified" = matched section with changes, not necessarily expanded languageboth
signal_idYesSignal ID — call list_signals first (e.g. "ai", "tariffs", "china")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does reasonably well: it explains the return granularity (one entry per company per change type), the presence of a snippet and comparison years, and adds a genuine caveat that a theme match does not mean the theme wording itself changed. It does not mention result caps, ordering, or what 'available comparisons' means in practice.

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 short sentences, front-loaded with what is found and what is returned, followed by an interpretive caveat that genuinely earns its place. No restatement of the title and no filler.

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?

No output schema and no annotations, yet the description covers the core return shape and the main semantic trap for a two-parameter read tool. Gaps remain around pagination, result limits, and whether coverage varies by company, which an agent might need before trusting a sparse result.

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 enum values for status are already documented in the schema with their own interpretive caveats. The description reinforces the theme/signal framing but adds no parameter-level meaning beyond what the schema provides, so 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?

States a specific verb and resource: find added or modified risk sections matching a theme across 10-K filing comparisons. That is more precise than the title, and it is distinguishable from get_company_diff in principle, but the description never names the company-scoped sibling or otherwise routes the agent between them.

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?

Usage is only implied: 'matching a theme' suggests the tool is for theme-based screening rather than per-company inspection, and the schema notes that list_signals must be called first. There is no explicit when-to-use/when-not guidance or named alternative, so the agent has to infer the boundary from the schema.

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

All RiskDiff 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