Loading ToolBench

Reading the current corpus…

acidtest MCP server · C · ToolBench

← Browse

acidtest

github.com/chuckyatsuk/acidtest

Security scanner for MCP servers and AI agent skills. Scan before you install.

2026-07-28+STDIO3 tools

65/100

Definition Quality85

Protocol Readiness35

Supportability52

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

acidtest is a security scanner tool for MCP servers and agent skills. It exposes 3 tools with well-defined purposes, clear action-verb naming (scan_*, lint_*), and comprehensive descriptions. All tools have proper input schemas with typed parameters. However, output schemas are not documented in the visible source code, and tool annotations (readOnlyHint) are missing despite all tools being read-only operations. The descriptions are strong (170-250 chars, well above the 10-char minimum and within the 194-char baseline average), and parameter descriptions are present. Error handling and recovery guidance are not visible in the tool definitions themselves.

Tools (3)

lint_mcp_serverread onlysource verified87/100

Lint an MCP server's own tool descriptions before publishing. Checks the manifest and the description strings in TypeScript/JavaScript/Python source for injected instructions, hidden emphasis tags, concealment directives, covert parameters, and cross-server shadowing. Returns located findings (file, line, rule, severity) — the same things a consumer's security scanner would flag. Designed for precision: it stays quiet on legitimate wording.

scan_allread onlysource verified82/100

Recursively scan all skills and MCP servers in a directory. Returns an array of scan results with trust scores and findings for each skill/server found.

scan_skillread onlysource verified87/100

Scan an AI agent skill or MCP server for security vulnerabilities. Returns a trust score (0-100) and findings from two analysis layers: an injection scan of tool descriptions, manifests, and markdown (prompt injection, tool poisoning, cross-server shadowing, credential exfil, invisible-Unicode) and a code scan (dangerous imports/sinks, obfuscation, credentials) of TypeScript/JavaScript/Python source.

Issues (4)

HIGHtool ↗

Output schemas not documented. Tool descriptions explain findings return structure but do not formally specify JSON schema for responses. LLMs cannot plan downstream processing or validate returned fields.

scan_skilllint_mcp_serverscan_all

MEDIUMtool-annotations ↗

Missing tool annotations. All three tools are read-only (Risk: READ_ONLY declared) but MCP tool definitions lack readOnlyHint annotation. This prevents clients from optimizing permissions, caching, or parallelization.

scan_skilllint_mcp_serverscan_all

MEDIUMrecovery-guide ↗

Error handling guidance missing from tool definitions. Descriptions do not explain what errors might occur (e.g., invalid path, permission denied, unsupported file format) or how the agent should recover. No actionable error messages visible in schema.

scan_skilllint_mcp_serverscan_all

HIGH

Recommendations

Add formal output schemas to all three tools. Example for scan_skill: { "type": "object", "properties": { "trustScore": { "type": "integer", "minimum": 0, "maximum": 100 }, "findings": { "type": "array", "items": { "type": "object", "properties": { "type": {"type": "string", "enum": ["injection", "code"]}, "severity": {"type": "string"}, "description": {"type": "string"} } } } }
Add readOnlyHint: true to all three tools in mcp.json or tool registration, since they perform static analysis without mutations.
Enhance parameter descriptions with constraint hints. Example: path parameter should document accepted formats: 'Absolute or relative path to a skill directory (e.g., ./skills/weather-mcp), SKILL.md file, or MCP server manifest (mcp.json, server.json, package.json)'.
Document error scenarios in tool descriptions. Example for scan_skill: 'Returns an error if the path is invalid, unreadable, or contains an unsupported file format. Recoverable: verify the path exists and readable; non-recoverable: unsupported project structure.'
Consider migrating from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote client access and hosted deployment.
Add examples of valid return values in tool descriptions to guide LLM output parsing. Example: 'Returns { trustScore: 85, findings: [{ type: "injection", severity: "high", description: "...", file: "...", line: 42 }] }'.

Score history

Overall score trend

First recorded score · v2 rubric

65/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	65	2026-07-28+	v2