mcp-skylos

Overview Schema Source Related Servers Discussions Admin

Verify an AI agent's guardrails

verify_agent

Read-only

Statically verify an AI agent's guardrails before deployment to detect prompt-injection, dangerous sinks, and PII leaks, with scores and remediation.

Instructions

Statically verify an AI agent's guardrails before deployment.

Deterministic, local pre-deployment agent verification: inventories LLM integrations, runs the defense checks (prompt-injection exposure, dangerous sinks, tool scope, output validation, PII filtering, cost controls), and returns scores, failed checks with remediation, OWASP LLM/Agentic coverage, and a reproducible attestation digest. No model is involved in the verdict and the analysis runs locally; source code is not sent to Skylos Cloud. Optional gate: set fail_on (severity) and/or min_score (0-100).

Requires SKYLOS_API_KEY: this tool returns an authentication error unless the MCP server is started with SKYLOS_API_KEY set. Without a key only analyze works (5 calls/day). The local CLI needs no key: skylos verify <file> and skylos agent install-hooks.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No	Directory of the LLM application or agent to check.	.
`fail_on`	No	Fail the gate if any failed check is at this severity or above: critical, high, medium or low.
`min_score`	No	Fail the gate if the defense score (0-100) is lower.
`owasp_version`	No	Version of that OWASP list; omit for the default (2025 for llm, 2026 for agentic).
`exclude_folders`	No	Extra folder names to skip, comma-separated (e.g. "migrations,scripts"). Added to the default excludes.
`owasp_framework`	No	OWASP list to map results to: "llm" (Top 10 for LLM Applications) or "agentic".	llm

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv4.49.0Oct 14, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations (readOnlyHint=true, openWorldHint=false, destructiveHint=false) are consistent and the description meaningfully extends them: deterministic verdict with no model involved, analysis runs locally, source code is not sent to Skylos Cloud, SKYLOS_API_KEY is required or an auth error is returned, and a concrete rate limit (5 calls/day for analyze).

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-loads the purpose and the strongest differentiators (deterministic, local, no model) before the auth details. Slightly long, and the closing CLI/`install-hooks` sentence is tangential to invoking the MCP tool, but most sentences carry real information.

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?

For a six-parameter read-only analysis tool with an output schema and full schema descriptions, this covers everything an agent needs: what is analyzed, what is returned, authentication and rate-limit constraints, gating behavior, and the privacy/data-handling posture.

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 baseline is 3. The description echoes the fail_on severity gate and min_score (0-100) that the schema already documents, adding only the framing that they form an 'optional gate' that fails the run — marginal value beyond structured fields.

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+resource+mode: 'statically verify an AI agent's guardrails before deployment,' then enumerates exactly what is inventoried and checked (LLM integrations, prompt injection, dangerous sinks, tool scope, etc.). It is clearly distinguishable from siblings such as verify_dead_code, verify_change, and security_scan.

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 usage context ('pre-deployment'), explains the optional gate semantics via fail_on/min_score, and names an alternative path when authentication fails ('without a key only `analyze` works'). It does not, however, explicitly state when *not* to use this versus security_scan or quality_check among the many siblings.

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

Deploy Server