Skip to main content
Glama
Sign In

isMalicious threat intelligence for AI agents

by com.ismalicious
OverviewDiscussionsAdmin

Acknowledge an alert

ack_alert
Idempotent

Set the status of one alert of the isMalicious inbox (an id from list_alerts): ACKNOWLEDGED (seen; still listed by default), RESOLVED (handled; no longer listed by default) or OPEN (new again). Reversible: any status can be set again. A CVE alert (cve.finding) follows its vulnerability finding, for the whole organization: ACKNOWLEDGED acknowledges an open finding, RESOLVED marks a finding not yet closed as patched, OPEN reopens it, and every member's copy of the alert follows; the answer names the finding under finding, and the alert's status is the one the API returns (ack_finding sets NOT_AFFECTED or SNOOZED). Scope: the inbox of the user the key belongs to, which for an organization API key is the organization owner's; an alert of another inbox reads as not found. Costs no request of the monthly quota.

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": {
      "alertId": "<alertId>",
      "status": "<status>"
    },
    "name": "ack_alert"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusYesThe new status.
alertIdYesThe alert's id, from list_alerts.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: inbox scoping for organization keys, that an out-of-scope alert surfaces as not found, that the operation costs no monthly quota, that CVE alerts cascade to every member's copy, and that the response names the finding under `finding`. None of this contradicts readOnlyHint=false, idempotentHint=true or destructiveHint=false — the described writes are repeatable state transitions, not destructive.

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?

Front-loaded with the verb and the three statuses, and every clause about CVE cascading or quota carries information an agent would otherwise have to discover by trial. The long semicolon-chained sentences with nested parentheticals make it denser than it needs to be, but little is truly redundant.

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?

For a two-parameter mutation with no output schema, it covers scope, quota impact, reversibility, cross-entity effects and the shape of the answer's key field. An agent could call this correctly on the first attempt without further exploration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both params are documented, so the baseline is 3; the description earns more by giving each enum value real semantics (RESOLVED drops the alert from the default listing, OPEN restores it) and by pinning alertId's provenance to list_alerts. It stops short of format or length guidance for alertId, which the schema pattern already covers.

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?

Opens with a specific verb and resource ("Set the status of one alert of the isMalicious inbox") and enumerates the three legal states with their listing consequences. It also separates itself from the sibling ack_finding by naming what that tool sets instead (NOT_AFFECTED or SNOOZED).

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

Usage Guidelines5/5

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

Explicitly says the id comes "from list_alerts", explains what each status means operationally (still listed by default vs no longer listed by default), and states reversibility so the agent knows a mistaken call can be undone. It routes CVE cases correctly, noting ack_finding is the tool for NOT_AFFECTED/SNOOZED.

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

All isMalicious threat intelligence for AI agents 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