projectpulse-mcp

analyze_code_scanning

Read-onlyIdempotent

Fetches or triggers open Code Scanning alerts from all tools (CodeQL, Scorecard, third-party) for a GitHub repository. Note: trigger_scan is CodeQL-only. - Side effects: Read-only by default.

Instructions

Fetches or triggers open Code Scanning alerts from all tools (CodeQL, Scorecard, third-party) for a GitHub repository. Note: trigger_scan is CodeQL-only.

Side effects: Read-only by default. If trigger_scan=true (CodeQL-only), writes to GitHub Actions by creating a workflow_dispatch event.
Data sources: GitHub REST API (code-scanning/alerts and actions).
Auth requirements: Requires GITHUB_TOKEN with appropriate permissions (security-events).
Rate limits: Subject to standard GitHub API limits.
Return shape: Returns a JSON array of alert objects including tool_name, rule_id, severity (error/warning/note), security_severity_level (critical/high/medium/low as in GitHub UI, or null), rule_description, state, location paths, and html_url.
Usage guidelines: Use this tool ONLY for deep static analysis code vulnerability scanning. DO NOT use this tool for other checks:
- For package/dependency vulnerabilities, use 'analyze_dependencies' instead.
- For a computed A-F health score grading, use 'get_health_score' instead.
- For checking standard CI/CD workflow statuses, use 'check_ci_status' instead.

Input Schema

Name	Required	Description
`repo`	Yes	GitHub repository name (e.g., 'sdk')
`owner`	Yes	GitHub repository owner (e.g., 'modelcontextprotocol')
`trigger_scan`	No	If true, triggers CodeQL workflow then polls for results before returning alerts
`poll_timeout_seconds`	No	Max seconds to wait for CodeQL scan completion (default 300)
`poll_interval_seconds`	No	Seconds between poll attempts (default 15)

Output Schema

Name	Required	Description	Default
`alerts`	Yes
`warning`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.9.0Oct 14, 2026

addedOutput schema / properties / alerts / items / properties / security_severity_level
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
addedOutput schema / properties / alerts / items / properties / tool_name
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

changedOutput schema / properties / alerts / items / required

Previous value: -[
-  "rule_id",
-  "severity",
-  "rule_description",
-  "state",
-  "html_url",
-  "alert_number",
-  "created_at"
-]New value: +[
+  "rule_id",
+  "severity",
+  "tool_name",
+  "security_severity_level",
+  "rule_description",
+  "state",
+  "html_url",
+  "alert_number",
+  "created_at"
+]

Changed1 schema field changedv1.1.7Sep 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "alerts": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "alert_number": {
+            "type": "number"
+          },
+          "created_at": {
+            "type": "string"
+          },
+          "end_line": {
+            "type": "number"
+          },
+          "html_url": {
+            "type": "string"
+          },
+          "message_text": {
+            "type": "string"
+          },
+          "most_recent_instance_path": {
+            "type": "string"
+          },
+          "most_recent_instance_start_line": {
+            "type": "number"
+          },
+          "rule_description": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "rule_id": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "severity": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "state": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "rule_id",
+          "severity",
+          "rule_description",
+          "state",
+          "html_url",
+          "alert_number",
+          "created_at"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "warning": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "alerts"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedv1.1.4Sep 5, 2026

changedInput schema / properties / owner / description

Previous value: -"GitHub repository owner"New value: +"GitHub repository owner (e.g., 'modelcontextprotocol')"

changedInput schema / properties / repo / description

Previous value: -"GitHub repository name"New value: +"GitHub repository name (e.g., 'sdk')"

First observedv1.1.3Aug 30, 2026

TDQS

A4/5.0

Behavior2/5

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

The description is genuinely rich — side effects, data sources, auth scope (GITHUB_TOKEN/security-events), rate limits and return shape — which is far beyond what annotations provide. However, it documents a write path ('trigger_scan=true ... writes to GitHub Actions by creating a workflow_dispatch event') while annotations declare readOnlyHint=true and idempotentHint=true, so the definition is internally inconsistent and an agent trusting the hints could trigger an unadvertised mutation.

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?

Well front-loaded and bulleted by concern (side effects, data sources, auth, limits, return shape, usage), so an agent can scan it quickly. It is somewhat longer than needed — the return-shape bullet duplicates the output schema — but no bullet is pure filler.

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?

Covers purpose, conditional side effects, auth, rate limits, data sources and alternatives, and an output schema exists so return-shape detail need not be exhaustive. Nothing an agent needs in order to call this correctly is missing.

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 description coverage is 100%, so the schema already documents owner, repo, trigger_scan and both polling parameters; baseline is 3. The description adds only one genuinely new parameter fact ('trigger_scan is CodeQL-only'), which is marginal since the schema already says it triggers the CodeQL workflow.

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 ('Fetches or triggers open Code Scanning alerts from all tools ... for a GitHub repository') and immediately scopes it against three named siblings. An agent can distinguish it from analyze_dependencies, get_health_score and check_ci_status without opening any schema.

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?

Explicit 'Use ONLY for deep static analysis code vulnerability scanning' plus a DO-NOT list with the exact alternative tool named for each excluded case (dependencies, health score, CI status). This is the strongest possible routing guidance.

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

Deploy Server