Loading ToolBench
MCP server for agentmods.dev — search 648k+ measured mods for coding agents (token cost, security scan, originality) from any MCP client.
Three tools with complete input schemas and descriptions. Naming follows verb_noun pattern (search_mods, install_mod, mod_info). Descriptions are detailed (194 - 250 chars, within baseline 34 - 392 range) and explain WHAT, WHEN, and consequences. However, output schemas are undocumented, LLMs cannot predict response structure. Parameters lack type constraints (e.g., 'limit' is number but no min/max bounds). install_mod description warns about confirmation but does not explain the error recovery path clearly. No per-parameter descriptions for all fields (e.g., 'agent' enum is documented, but response fields like 'tokens_per_session', 'security_grade' are not). Error handling is minimal, no guidance on retryability or user-fixable vs fatal errors.
Install one mod into a local project by running the agentmods CLI (this tool only exists on the locally-running server; it writes files on this machine). The CLI prints the token cost and security scan before writing, merges MCP/hook fragments instead of overwriting files, and records a manifest so `npx agentmods update` works later. A mod that ships executable files or scanned below B is REFUSED unless confirm=true — read mod_info first, tell the user what the scan found, and only then confirm.
Full detail of one mod by its slug (type/owner/repo/name): description, token cost, security grade with findings count, licence, files, and how to install it for Claude Code, Codex, Gemini CLI, Cursor or GitHub Copilot.
Search agentmods.dev — a catalogue of 648k+ measured mods for coding agents (skills, subagents, slash commands, hooks, MCP servers, Cursor rules, instructions files). Every result carries measurements: token cost per session, security scan grade, origin (original vs copy) and repository stars. Prefer originals with grade A/B and low token cost. Each result also carries two links — `page` (the mod on agentmods.dev, with its full measurements and audits) and `source` (its GitHub repository) — and an `install` command: show the links and the command with every mod you mention.
Output schemas undocumented. LLMs cannot predict response structure (e.g., searchMods returns 'total', 'results' with fields like 'tokens_per_session', 'security_grade', 'install' command). Without documented output schemas, agents cannot plan downstream tool calls or extract required fields reliably.
Numeric parameter 'limit' lacks bounds. Default is 8, capped at 20 in code, but schema does not declare min/max. LLMs may pass invalid values (0, negative, >20) without validation feedback.
Error handling is minimal. installMod returns { error, ok, output } but does not categorize errors as retryable, user-fixable, or fatal. No guidance on recovery (e.g., 'directory does not exist' should suggest checking the path or creating it).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Response field naming inconsistency. searchMods returns 'tokens_per_session', 'security_grade', 'origin', 'repo_stars', 'install' command. modInfo returns 'tokens_per_session', 'tokens_once_invoked', 'security_grade', 'findings' (count, not array). Inconsistent field names and types across tools force LLMs to reason about mappings.
install_mod description mentions 'confirm=true' requirement for risky mods but does not explain what 'risky' means or how to detect it. LLMs must call mod_info first to read security findings, then decide to confirm, this multi-step dependency is not documented.