topai-mcp-suite

Overview Schema Source Related Servers Discussions Admin

agentpr_guard_audit

Read-onlyIdempotent

Audits git diffs and pull requests for AI-hallucinated packages, typosquatting, unauthorized boundary imports, and leaked secrets to verify code changes before merging.

Instructions

Audits unified git diffs or Pull Requests for AI-hallucinated NPM/PyPI packages, typosquatting attacks, unauthorized boundary imports, and leaked secrets. Use when: Verifying code changes from AI coding agents (Cursor, Claude Code, Copilot) or reviewing PRs before merging into production repositories. Do not use when: Pruning TypeScript/JavaScript AST syntax or linting container Dockerfiles. Alternative: Use tokenprune_wasm_trim for AST prompt reduction, or dockerlean_wasm_audit for Dockerfile linting. Execution: Runs locally in-memory (<5ms), read-only, idempotent, zero network calls, zero telemetry, air-gapped deterministic.

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": {
      "diff": "<diff>"
    },
    "name": "agentpr_guard_audit"
  }
}

Input Schema

Name	Required	Description	Default
`diff`	Yes	Unified git diff or PR patch text to audit. Must include hunk headers (e.g., 'diff --git a/... b/...').
`licenseKey`	No	Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).

Output Schema

Name	Required	Description
`report`	Yes	Detailed security audit findings, blocked hallucinated packages, and boundary policy results.
`markdown`	Yes	Formatted Markdown audit summary suitable for PR comments.
`securityNotice`	Yes	One-line pass/fail status verification string.
`hasVulnerability`	Yes	Flag indicating whether hallucinated packages or security hazards were intercepted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.0.6Oct 22, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / diff / description

Previous value: -"Unified git diff string to audit"New value: +"Unified git diff or PR patch text to audit. Must include hunk headers (e.g., 'diff --git a/... b/...')."

addedInput schema / properties / licenseKey

Added value: +{
+  "description": "Optional TopAI Sovereign Pro offline license key (or set TOPAI_LICENSE_KEY env variable).",
+  "type": "string"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "hasVulnerability": {
+      "description": "Flag indicating whether hallucinated packages or security hazards were intercepted.",
+      "type": "boolean"
+    },
+    "markdown": {
+      "description": "Formatted Markdown audit summary suitable for PR comments.",
+      "type": "string"
+    },
+    "report": {
+      "description": "Detailed security audit findings, blocked hallucinated packages, and boundary policy results.",
+      "type": "object"
+    },
+    "securityNotice": {
+      "description": "One-line pass/fail status verification string.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "report",
+    "markdown",
+    "hasVulnerability",
+    "securityNotice"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is partly redundant here. The description still adds genuine context beyond them: in-memory local execution, <5ms latency, zero telemetry, and air-gapped determinism, which tells an agent this is safe to call repeatedly in a loop. Minor overlap with openWorldHint prevents a 5.

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 with labeled sections (Use when / Do not use when / Alternative / Execution) so an agent can scan quickly. Slightly padded — 'zero network calls, zero telemetry, air-gapped deterministic' restates the same property three ways, and idempotency duplicates the annotation.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, exclusions, alternatives, and execution profile. For a two-parameter, single-required-input tool, nothing an agent needs to invoke it 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 both parameters (diff, licenseKey) are already documented including the hunk-header requirement. The description adds no syntax, format, or sizing guidance for the diff payload beyond what the schema states, 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?

Starts with a specific verb+resource ('Audits unified git diffs or Pull Requests') and enumerates the exact defect classes it catches: hallucinated NPM/PyPI packages, typosquatting, unauthorized boundary imports, leaked secrets. It also explicitly names the sibling tools it is not, so an agent can discriminate without opening schemas.

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?

Has explicit 'Use when' (verifying AI-agent-authored code changes, PR review before merge) and 'Do not use when' (AST pruning, Dockerfile linting) clauses, plus a concrete 'Alternative' line routing to tokenprune_wasm_trim and dockerlean_wasm_audit. Both positive and negative selection criteria are stated outright.

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

Deploy Server