customclaw-mcp
customclaw-mcp
安装，而非重新生成。 CustomClaw 注册表的 MCP 服务器 — 包含 37 个经过验证的单文件工具，适用于 LLM 和代理代码（包括遵循
Retry-After的速率限制器、JSON 修复、响应缓存、带退避的重试、令牌计数器、PII 清理器）。你的代理只需调用四个原生工具，无需编写 120 行看似合理的新代码。
📖 背景：工具健忘症问题 — 为什么你的编码代理已经重写了 47 次相同的速率限制器。
30 秒安装
npx -y customclaw-mcp将该命令放入你的 MCP 客户端配置中（代码片段见下文），即可完成。免费工具无需身份验证即可安装。
功能介绍
将 CustomClaw 目录（37 个工具，32 个免费）接入任何模型上下文协议 (MCP) 主机 — Claude Desktop、Claude Code、Cursor、Windsurf 或任何支持 MCP 的工具 — 作为四个工具使用：
工具 | 参数 | 用途 |
| — | 完整目录（缓存 5 分钟） |
|
| 按别名/名称/描述进行模糊匹配 |
|
| 获取单个工具的详细信息 |
|
| 获取有效载荷并写入文件 |
安装（按客户端）
Claude Desktop
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) 或 %APPDATA%\Claude\claude_desktop_config.json (Windows)：
{
"mcpServers": {
"customclaw": {
"command": "npx",
"args": ["-y", "customclaw-mcp"]
}
}
}重启 Claude Desktop。工具将出现在工具选择器中。
Claude Code
claude mcp add customclaw -- npx -y customclaw-mcpCursor / Windsurf / 任何 stdio MCP 主机
将主机指向 npx -y customclaw-mcp。
可流式传输的 HTTP (smithery, ChatGPT 等)
使用托管端点：https://customclaw.company/mcp。已在 smithery 上注册为 onlythebestswfl/customclaw。
示例提示词
连接后：
“添加一个遵循 Retry-After 的速率限制器。” →
search_utilities→install_utility rate-limit-handler“我需要解析 Claude 输出中损坏的 JSON。” →
json-repair“你们有什么用于缓存 LLM 响应的工具吗？” →
search_utilities→ 查看简短结果表“将
token-optimiser安装到./src/lib中。” → 直接使用install_utility“扫描此项目的提示词是否存在注入风险 — 有相关工具吗？” →
injection-scanner
任务 → 别名快速参考
如果你需要… | 别名 (Slug) |
处理 |
|
LLM 输出的 JSON 修复 |
|
基于提示词哈希的响应缓存 |
|
指数退避重试 |
|
跨模型的令牌计数 |
|
日志记录前的 PII 清理 |
|
提示词注入扫描器 |
|
各提供商的成本预测 |
|
通过 list_utilities 或 customclaw.company/api/catalog 获取完整列表。
付费工具
对于付费工具，请将收据邮件中的 Stripe 结账 session_id 作为 session_id 参数传递给 install_utility。否则，该工具将返回 401 错误。
环境
CUSTOMCLAW_BASE— 注册表基础 URL 覆盖（默认为https://customclaw.company）。适用于暂存环境或自托管镜像。
工作原理
Node.js stdio MCP 服务器。依赖项：
@modelcontextprotocol/sdk。目录从
GET /api/catalog获取；每个进程缓存 5 分钟。有效载荷来自
GET /api/cli?slug=<slug>[&session_id=<cs_...>]— 与官方customclaw-cli使用的端点相同。install_utility拒绝写入target_dir之外的路径（路径遍历防护）。
链接
许可证
MIT。
Available Tools
4 toolsget_utility_infoA
Return the full catalog entry for a single utility or agent by slug (name, tagline, description, price, free flag, category, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The utility or agent slug, e.g. "token-optimiser". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavior. It indicates a read operation without side effects, but does not address error cases (e.g., missing slug), authentication needs, or rate limits. This is adequate for a simple retrieval but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core function and included fields, with no extraneous information. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter schema and no output schema, the description adequately explains what the tool returns and how to use it. It could mention the outcome for invalid slugs, but overall it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% with a description for 'slug'. The description's mention of 'by slug' mirrors the schema, adding no new semantic value beyond what the schema already provides. Therefore, the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a full catalog entry for a single utility/agent by slug, listing specific fields (name, tagline, description, price, etc.). It differentiates from sibling tools like list_utilities and search_utilities, which handle multiple results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the required identifier (slug) but does not explicitly provide when or when not to use this tool versus siblings. However, the context of siblings implies that get_utility_info is for a single detailed entry, while list_utilities gives an overview and search_utilities finds by criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
install_utilityA
Fetch a CustomClaw utility payload and write its files into target_dir. For paid utilities, pass session_id (the Stripe checkout session_id from the buyer's receipt email). Returns the list of files written and any npm dependencies the caller should install — this tool does NOT run npm install itself; the host agent decides when to install deps.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The utility slug to install. | |
| target_dir | Yes | Directory to write files into. Absolute path preferred; relative paths are resolved against the server process cwd. | |
| session_id | No | Optional. Stripe checkout session_id for paid utilities. Found as session_id=... in the CustomClaw receipt email download URL. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it writes files, returns a list of files and npm dependencies, and refrains from running npm install. However, it does not mention potential side effects like overwriting existing files or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficiently structured. The first sentence states the main action, the second provides critical usage details (session_id and npm install behavior). No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema but the description fully explains return value (list of files and npm dependencies) and what the tool does not do (npm install). For a tool with 3 parameters and no nested objects, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context beyond the schema: slug is clarified as 'utility slug', target_dir includes guidance on absolute vs relative paths, and session_id explains where to find it (Stripe checkout session_id from receipt email).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a CustomClaw utility payload and write its files into target_dir', which is a specific verb and resource. It distinguishes from sibling tools (get_utility_info, list_utilities, search_utilities) which are all informational while this is an installation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to pass session_id (for paid utilities) and clarifies that the tool does NOT run npm install itself, leaving that decision to the host agent. This helps the agent understand when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_utilitiesA
List every utility and agent available in the CustomClaw registry (https://customclaw.company). Results are cached for 5 minutes. Returns catalog JSON with utilities and agents arrays.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses caching (5 minutes) and return structure (catalog JSON with utilities and agents arrays), which is transparent for a simple read-only tool. However, it does not mention authentication or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences: first states purpose and source, second adds caching and return format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description sufficiently covers the action, source, caching, and return format. It could mention the JSON structure details but is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds no parameter info since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('every utility and agent') and distinguishes from siblings by indicating it returns all items from the registry, whereas siblings like get_utility_info or search_utilities likely target specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies broad listing use but does not explicitly state when not to use it or mention alternatives like search_utilities or get_utility_info for filtered queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_utilitiesA
Fuzzy-search the CustomClaw registry by keyword. Matches across slug, name, tagline, description, and category. Returns the top 25 matches sorted by relevance.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword(s) to search for, e.g. "token optimiser" or "stripe". |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses fuzzy matching behavior, fields searched, result limit of 25, and relevance-based sorting. While it does not mention pagination or error handling, the provided traits are sufficient for a read-only search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and every sentence adds value. No extraneous information, efficiently conveying scope and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately covers input (keyword) and output (top 25 sorted results). It lacks mention of empty results or pagination but is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single query parameter already described with examples. The description adds meaningful context beyond schema by specifying fuzzy matching and the fields searched, enhancing understanding of how the parameter is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fuzzy-search the CustomClaw registry by keyword' with specific verb and resource. It details matching fields (slug, name, tagline, description, category) and output (top 25 sorted by relevance), clearly distinguishing it from siblings like get_utility_info (specific utility) or list_utilities (all utilities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for keyword search but does not explicitly state when to use this tool versus alternatives (e.g., for exact match use list_utilities, for specific utility use get_utility_info). No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
4 tool updates
v0.1.1- First observed
get_utility_info - First observed
install_utility - First observed
list_utilities - First observed
search_utilities
TDQS
Scored across 4 tools
Each tool has a distinct purpose: getting info for a single utility, installing a utility, listing all utilities, and searching. No overlapping functionality, so an agent can easily distinguish them.
All tool names follow a consistent ��verb_noun�� pattern (get_utility_info, install_utility, list_utilities, search_utilities) with underscores and lowercase, making the set predictable.
Four tools cover the core operations for a registry MCP (list, search, get details, install) without being excessive or insufficient, fitting the domain well.
The toolset provides a complete workflow from discovery (list, search, get info) to installation, with no obvious gaps for its intended use as a consumer-facing registry interface.
Related MCP Connectors
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
MCP-first toolbox for agents: KV storage, auth, queue, and utility tools. Free in early access.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
13 free utility tools for AI agents: web text, markdown, hashing, IDs, dates, units, JSON.
131