Skip to main content
Glama
Sign In
Petra Security MCP Server

Petra Security MCP Server

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

petra_get_incident

Read-onlyIdempotent

Retrieve a Petra incident by ID with full user and phishing-email details; search recent 500 incidents or pass tenantId to reach older ones.

Instructions

Get one Petra incident by its ID, with full user and phishing-email detail. Petra has no single-incident route, so this searches the newest 500 incidents (pass tenantId to reach older ones).

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": {
      "incidentId": "<incidentId>"
    },
    "name": "petra_get_incident"
  }
}

Input Schema

NameRequiredDescriptionDefault
tenantIdNoTenant the incident belongs to, to widen the search window. Petra tenant ID (from petra_list_tenants, or the app.petrasecurity.com/tenant/<id> URL) or the Microsoft tenant ID; Petra resolves either.
startDateNoOnly search incidents created on or after this ISO 8601 date.
incidentIdYesIncident ID (UUID) from petra_list_incidents or the Petra incident URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is set. The description contributes non-obvious behavior beyond that: the lookup is implemented as a search over only the newest 500 incidents, which warns the agent about possible false negatives on old records and explains how tenantId mitigates it.

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?

Two sentences, zero filler, and the result scope is front-loaded ahead of the implementation caveat. Every clause carries information an agent needs to call it correctly.

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?

With annotations present and a fully documented three-parameter schema, the definition covers the important unknowns: retrieval semantics, search-window limits, and remediation via tenantId. It is slightly thin on what a not-found result looks like, but the stated 'full user and phishing-email detail' is adequate for a read tool with no output schema.

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 description coverage is 100%, so baseline is 3; the description still adds value by tying tenantId to the 500-incident search cap rather than describing it abstractly. It does not clarify startDate's interaction with the search window, leaving a small gap.

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 verb and resource ('Get one Petra incident by its ID') plus the payload depth ('full user and phishing-email detail'), which cleanly separates it from the sibling list tool petra_list_incidents. An agent knows this is a single-record retrieval without opening the 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 operational context: there is no single-incident route, so this performs a bounded search, and passing tenantId reaches older records. It does not explicitly name petra_list_incidents as the source of IDs or state exclusions, but the practical when/how is well covered.

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