Skip to main content
Glama
Sign In
ai-security-wiki

ai-security-wiki

by MathBorgess
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_risk

Read-onlyIdempotent

Retrieve a complete DASF risk record by ID, including impacts, deployment applicability, mappings, and official source row.

Instructions

Read one complete DASF risk, impacts, deployment applicability, mappings and official source row.

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": {
      "risk_id": "<risk_id>"
    },
    "name": "get_risk"
  }
}

Input Schema

NameRequiredDescriptionDefault
risk_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already establish that this is a safe, read-only, idempotent, non-destructive operation. The description adds meaningful behavioral context by specifying that the result includes impacts, deployment applicability, mappings, and the official source row, beyond what the annotations provide.

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?

The description is a single front-loaded sentence with no filler. Every phrase contributes to stating the action and the returned content.

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 one-parameter read tool with rich annotations and no output schema, the description usefully enumerates what is returned. The remaining gaps are the undocumented risk_id format and the lack of guidance on choosing this tool over investigate_risk.

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?

The schema has zero description coverage for the sole risk_id parameter, so the description must compensate. It implies that risk_id selects one complete DASF risk, but it does not describe the expected ID format, source, or examples, leaving some semantic gaps.

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 (Read) and resource (one complete DASF risk) and enumerates the payload components, so the operation is clear. It does not distinguish this from sibling tools such as investigate_risk or scope_risks, which creates ambiguity about when this direct fetch is preferred.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use get_risk versus investigate_risk, search_knowledge, or other sibling tools. The single-record fetch is implied by the wording and required risk_id, but the agent is left to infer the selection criteria.

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

Deploy Server

Other Tools