agentic-sdlc-mcp

Security Triage

security_triage

Read-onlyIdempotent

Read GitHub code scanning, Dependabot, and secret scanning alerts to produce a triage report with severity breakdown, fix order, and suggested issues.

Instructions

Read GitHub security alerts (code scanning, Dependabot, secret scanning) and produce a triage report.

Required token scopes:

security_events, or public_repo for public-only repos (Code Scanning)
security_events, or public_repo for public-only repos (Dependabot)
repo or security_events (Secret Scanning)

Args:

owner, repo: Repository coordinates.
includeCodeScanning / includeDependabot / includeSecretScanning: Default true.

Returns: Alert summary, severity breakdown, recommended fix order, suggested issues.

Input Schema

Name	Required	Description
`repo`	No	GitHub repo. Falls back to GITHUB_REPO.
`owner`	No	GitHub owner. Falls back to GITHUB_OWNER.
`includeDependabot`	No	Include Dependabot alerts. Requires vulnerability_alerts scope.
`includeCodeScanning`	No	Include Code Scanning alerts. Requires security_events scope.
`includeSecretScanning`	No	Include Secret Scanning alerts. Requires secret_scanning_alerts scope.

Output Schema

Name	Required	Description	Default
`repo`	Yes
`alerts`	Yes
`errors`	Yes
`trustBoundary`	No
`severityCounts`	Yes
`truncatedSources`	Yes
`markdownOmittedAlertCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.11.0Oct 18, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed4 schema fields changedv1.9.0Jul 29, 2026

addedOutput schema / properties / markdownOmittedAlertCount

Added value: +{
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}

addedOutput schema / properties / truncatedSources

Added value: +{
+  "items": {
+    "enum": [
+      "code_scanning",
+      "dependabot",
+      "secret_scanning"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / trustBoundary

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "callerAndRepositoryContent": {
+      "const": "untrusted",
+      "type": "string"
+    },
+    "instructionHandling": {
+      "const": "never_execute",
+      "type": "string"
+    },
+    "permissionHandling": {
+      "const": "never_expand",
+      "type": "string"
+    },
+    "secretHandling": {
+      "const": "never_reveal",
+      "type": "string"
+    }
+  },
+  "required": [
+    "callerAndRepositoryContent",
+    "instructionHandling",
+    "secretHandling",
+    "permissionHandling"
+  ],
+  "type": "object"
+}

changedOutput schema / required

Previous value: -[
-  "repo",
-  "alerts",
-  "errors",
-  "severityCounts"
-]New value: +[
+  "repo",
+  "alerts",
+  "errors",
+  "truncatedSources",
+  "markdownOmittedAlertCount",
+  "severityCounts"
+]

First observedv1.5.0Jul 9, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds real behavioral context beyond that: the required token scopes per alert source and the fact that all three sources default to true. It stops short of disclosing rate limits, pagination, or failure modes when a scope is missing.

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 purpose, then cleanly sectioned into scopes, args, and returns. The scope list repeats the identical 'security_events, or public_repo' line for Code Scanning and Dependabot, which is minor redundancy.

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 read-only tool with an output schema, the definition covers the essentials: auth requirements, defaulted filters, and the shape of the report. It is essentially complete, with only minor redundancy in re-describing return values already covered by the output schema.

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%, so the schema already documents all five parameters including fallback behavior (GITHUB_OWNER/GITHUB_REPO) and scope requirements. The description's Args section largely restates the schema (coordinates, default true) without adding syntax or semantics beyond it, so the baseline 3 applies.

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 (read), specific resource (GitHub security alerts, naming the three categories) and the output artifact (triage report). It is clearly distinguishable from siblings like workflow_permissions_audit and branch_protection_status, which cover different security domains.

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 implied by the tool's scope (aggregate the three alert types into a triage report), and the include* defaults signal the default behavior. However, there is no explicit when-to-use vs an alternative, and no when-not-to-use guidance, so it stays at implied usage.

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

Deploy Server