haiec-ai-agent-security-free-mcp

Overview Schema Source Related Servers Discussions Admin

Scan AI/LLM Source Code Security

scan_ai_security

Read-only

Audit AI applications and agents for security risks before commit, merge, or deployment. Static analysis produces deterministic findings with coverage and evidence.

Instructions

Audit AI applications and agents for security risks before commit, PR, merge, or deployment. Produces deterministic findings with explicit coverage, Security Concern Families, Scan Receipts, and Evidence Envelopes.

USE when a developer asks to:

"check this for security issues"
"audit this task before I push"
"review this change for security problems"
"scan this AI agent" or "scan this AI app"
"check my LLM application"
"security review this PR"
"is this safe to merge"
"check this before deployment"
"audit this code for vulnerabilities"
"run a security scan"
"check for security risks before commit"
"review this implementation before pushing"

Also use for:

reviewing AI/LLM/agent source code for security
validating AI code before merge
checking an agent before deployment
reviewing RAG or model integration security
looking for unsafe AI source-code patterns
checking AI-output-to-dangerous-action flows
checking AI source-code secrets/security controls

DO NOT use for:

actual LLM response/content verification (use verify_llm_content)
tenant/RLS/cross-customer isolation (use scan_tenant_isolation)
generic compliance questionnaires or compliance certification
generic non-AI source scanning where no AI check applies

This tool performs static analysis only. It does NOT execute target code, make network requests, or emit telemetry. BLOCK findings are advisory — deployment enforcement is handled by check_deploy_security (not yet implemented).

Input Schema

TableJSON Schema

Name	Required	Description
`timeout`	No	Scan timeout in seconds. Default: 300.
`targetPath`	Yes	Absolute or relative path to the AI application source code to scan.
`extendedScope`	No	Include tests/docs/examples in the scan. Default: false (production scope only).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`errors`	Yes
`scanId`	Yes
`receipt`	No
`summary`	Yes
`verdict`	Yes
`versions`	Yes
`truncation`	Yes
`limitations`	Yes
`completeness`	Yes
`observations`	Yes
`schemaVersion`	Yes
`evidenceEnvelope`	No
`actionableFindings`	Yes
`completenessReasons`	Yes
`evaluatedDetectorIds`	Yes
`securityConcernFamilies`	Yes
`evaluatedSecurityCheckIds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnlyHint annotation: states it performs static analysis only, does not execute target code, does not make network requests, does not emit telemetry, and explicitly notes that BLOCK findings are advisory with deployment enforcement not yet implemented. This is strong behavioral disclosure.

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?

The description is front-loaded with a clear purpose and then organized into use, non-use, and behavioral sections. The trigger phrase list is somewhat repetitive, but the structure is effective and the information density is high for an agent-facing tool description.

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?

Given the output schema exists, the description need not explain return values. It covers the tool's scope, safety characteristics, exclusions, alternatives, and advisory nature, making it complete for an agent to select and invoke correctly.

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 all three parameters (targetPath, timeout, extendedScope) are already documented in the schema. The description does not add parameter-level detail, but with full schema coverage the baseline of 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Audit AI applications and agents for security risks before commit, PR, merge, or deployment.' It also distinguishes itself from related tools by naming alternatives in the DO NOT use section, such as verify_llm_content and scan_tenant_isolation, even though no siblings are listed.

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?

Provides an extensive USE when list of concrete developer intents, a separate 'Also use for' list of scenarios, and an explicit DO NOT use section that points to alternative tools. This gives an agent clear routing guidance and exclusions.

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

scan_ai_securityA