Skip to main content
Glama
deenesjakoruzh
onlythebestswfl-ops

customclaw-mcp

by onlythebestswfl-ops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

customclaw-mcp

npm version npm downloads License: MIT MCP

재생성하지 말고 설치하세요. CustomClaw 레지스트리를 위한 MCP 서버 — LLM 및 에이전트 코드를 위한 37개의 검증된 단일 파일 유틸리티(Retry-After를 준수하는 속도 제한기, JSON 복구, 응답 캐시, 지수 백오프 재시도, 토큰 카운터, PII 스크러버). 에이전트가 그럴듯해 보이는 120줄의 새 코드를 작성하는 대신 4개의 기본 도구 호출을 사용하게 하세요.

📖 배경: 유틸리티 기억상실 문제 — 코딩 에이전트가 왜 동일한 속도 제한기를 47번이나 다시 작성했는지에 대한 설명.

30초 설치

npx -y customclaw-mcp

해당 명령어를 MCP 클라이언트 설정(아래 스니펫 참조)에 넣으면 완료됩니다. 무료 도구는 인증 없이 설치됩니다.

기능

CustomClaw 카탈로그(37개 유틸리티, 32개 무료)를 모든 Model Context Protocol 호스트(Claude Desktop, Claude Code, Cursor, Windsurf 등 MCP를 지원하는 모든 환경)에 4개의 도구로 연결합니다:

도구

인수

목적

list_utilities

—

전체 카탈로그 (5분 캐시)

search_utilities

query: string

슬러그/이름/설명에 대한 퍼지 매칭

get_utility_info

slug: string

하나의 유틸리티에 대한 상세 정보

install_utility

slug, target_dir, session_id?

페이로드 가져오기 + 파일 쓰기

설치 (클라이언트별)

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-mcp

Cursor / 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

작업 → 슬러그 빠른 참조

필요한 기능

슬러그

Retry-After 처리가 포함된 속도 제한

rate-limit-handler

LLM 출력을 위한 JSON 복구

json-repair

프롬프트 해시별 응답 캐시

response-cache

지수 백오프 재시도

retry-with-backoff

모델 간 토큰 카운팅

token-optimiser

로깅 전 PII 스크러빙

pii-scrubber

프롬프트 인젝션 스캐너

injection-scanner

공급자별 비용 예측

cost-forecaster

전체 목록은 list_utilities 또는 customclaw.company/api/catalog에서 확인하세요.

유료 유틸리티

유료 유틸리티의 경우, 영수증 이메일에 있는 Stripe 결제 session_id를 install_utility의 session_id 인수로 전달하세요. 그렇지 않으면 도구가 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 tools
get_utility_infoA

Return the full catalog entry for a single utility or agent by slug (name, tagline, description, price, free flag, category, etc.).

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesThe utility or agent slug, e.g. "token-optimiser".

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesThe utility slug to install.
target_dirYesDirectory to write files into. Absolute path preferred; relative paths are resolved against the server process cwd.
session_idNoOptional. Stripe checkout session_id for paid utilities. Found as session_id=... in the CustomClaw receipt email download URL.

TDQS

A4.8/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesKeyword(s) to search for, e.g. "token optimiser" or "stripe".

TDQS

A4.2/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 4 tool updatesv0.1.1
    • First observedget_utility_info
    • First observedinstall_utility
    • First observedlist_utilities
    • First observedsearch_utilities
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

Four tools cover the core operations for a registry MCP (list, search, get details, install) without being excessive or insufficient, fitting the domain well.

Completeness5/5

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.

Resources

Related MCP Connectors