CloneKit

by ai.clonekit

Overview Discussions Admin

Server Details

Expert know-how (kits) any AI can read or run, always the latest version.

Ownership verified

Status: Healthy
Uptime: 82.9% over 20 days
Last Tested: 2026-11-05 18:28
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A4/5.0

Scored 2026-10-23 22:20 across 4 tools

Disambiguation5/5

Each tool targets a clearly distinct resource and action: get_kit returns kit metadata, get_kit_files returns file contents, list_creator_kits returns creator profiles and their kits, and search_kits searches the catalog. The boundary between get_kit (metadata) and get_kit_files (contents) is explicit, and search vs. creator listing is unambiguous.

Naming Consistency5/5

All four tools follow a consistent snake_case verb_noun pattern: get_kit, get_kit_files, list_creator_kits, search_kits. The verbs (get, list, search) accurately reflect each tool's operation, and there is no mixing of naming conventions.

Tool Count5/5

Four tools is well-scoped for a public kit catalog and file retrieval server. Each tool covers a distinct discovery or retrieval need, and none appears redundant or missing for the stated read-only purpose.

Completeness4/5

The surface covers search, kit details, file retrieval, and creator browsing, which are the core read-only operations for a public kit catalog. Minor gaps remain, such as no explicit pagination or browsing for creators beyond handle lookup, and paid-kit files are intentionally excluded.

Available Tools

4 tools

get_kitGet kit detailsA

Read-onlyIdempotent

Inspect

Returns the public details of one published kit by its reference: title, summary, link, mode (read: reference files; run: guided steps), file index and entry file, checks, questions, deliverables, tools, inputs, guardrails, license, creator, ratings and the latest changes. Kits that are not public return not_found.

Name	Required	Description	Default
`ref`	Yes	Kit reference, like "@clonekitai/landing-page-design-loop".

Output Schema

Name	Required	Description
`ref`	Yes
`url`	Yes
`mode`	Yes
`files`	Yes
`title`	Yes
`access`	Yes
`version`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful behavioral context: only public kits are returned, non-public kits produce not_found, and it enumerates the detail categories returned.

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?

The description is front-loaded with the core action and then lists the returned detail categories. It is somewhat dense, but the enumeration is relevant for understanding what the tool returns, and the not_found caveat is clearly placed.

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 one-parameter read-only lookup with rich annotations and an output schema, the description is complete enough. It covers public-only access, not_found behavior for non-public kits, and the categories of information returned.

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 description coverage is 100%, and the single ref parameter is already documented with a pattern and example. The description reinforces that retrieval is by reference but adds no additional syntax or format details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it returns public details of one published kit by reference. It identifies the scope as a single published kit and lists the returned fields, though it does not explicitly differentiate itself from sibling tools such as get_kit_files or search_kits.

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?

Usage is implied by “by its reference” and the not_found behavior for non-public kits, so an agent can infer this is for fetching details when the kit reference is already known. However, it does not explicitly say when to use this versus search_kits, get_kit_files, or list_creator_kits.

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

get_kit_filesRead a free kit's filesA

Read-onlyIdempotent

Inspect

Returns the contents of files from a free public kit, by path from the kit's file index. Up to 20 paths and 40,000 characters per reply; offset continues a long file from next_offset. Images within a size budget come as image content; PDFs and larger images come as download links valid for 10 minutes. Files of paid kits and the step instructions of run kits are not returned.

Name	Required	Description
`ref`	Yes	Kit reference, like "@clonekitai/landing-page-design-loop".
`paths`	Yes	File paths from the kit's file index, like ["README.md", "rules/numbers.md"].
`offset`	No	Character position to resume reading paths[0] from (next_offset of the previous reply).

Output Schema

Name	Required	Description
`ref`	Yes
`files`	Yes
`version`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing batch limits (20 paths, 40,000 chars), pagination via offset/next_offset, and how different media are returned (inline images, 10-minute download links for PDFs/larger images). These are operationally critical behaviors an agent cannot infer from the annotations or schema.

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?

Front-loads the core action and scope, then layers limits, pagination, media handling, and exclusions in a tight sequence. Every sentence carries distinct operational information with no filler.

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?

Given an output schema exists, return values needn't be detailed, yet the description still explains the image/PDF return shapes and download-link lifetime. Combined with the limit and exclusion rules, an agent has everything needed to invoke correctly.

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 already 100%, so the baseline is 3, but the description adds meaning beyond it: the 40,000-char reply cap and the fact that offset resumes paths[0] from next_offset clarify how batching and pagination interact. It stops short of 5 since most per-parameter semantics are already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (returns contents) and resource (files from a free public kit), scoped by 'path from the kit's file index' and limited to free/public kits. It differentiates from siblings by implicit scope (get_kit = metadata, this = file contents) but never names a sibling or explicitly contrasts with them.

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?

Clear context with exclusions: files of paid kits and step instructions of run kits are not returned, and paths must come from the kit's file index. It lacks explicit 'use X instead when...' routing against get_kit or search_kits, so it stops short of full alternative guidance.

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

list_creator_kitsList a creator's kitsA

Read-onlyIdempotent

Inspect

Returns a creator's public profile (handle, name, bio, link) and their public kits, most used at the top, with the same fields as search results. Unknown or inactive creators return not_found.

Name	Required	Description
`limit`	No	Number of kits per page (default 20, maximum 50).
`cursor`	No	next_cursor from the previous page of results.
`handle`	Yes	Creator handle, like "@francisco".

Output Schema

Name	Required	Description
`kits`	Yes
`count`	Yes
`creator`	Yes
`next_cursor`	No

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description adds genuinely useful behavior beyond them: results are ordered by usage, unknown or inactive creators yield not_found, and the payload shape mirrors search results.

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?

Two tight sentences with no filler, and the return content is front-loaded before the error case. The ordering guarantee and error behavior are each delivered once.

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?

An output schema exists, so return values need not be enumerated; the description still briefly characterizes the payload. With annotations covering the safety profile and full schema coverage, an agent has enough to call this correctly, though it would benefit from routing guidance versus siblings.

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 description coverage is 100%, with limit, cursor and handle all documented in the schema itself (defaults, maximum, pattern). The description adds no parameter-level detail such as handle formatting or pagination semantics, so the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns a creator's public profile plus their public kits, and even specifies ordering (most used at the top). The phrase 'same fields as search results' implicitly separates it from search_kits and get_kit, though it never names those siblings directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to choose this over search_kits or get_kit, and no stated prerequisites or exclusions. Usage is only inferable from the tool name and the mention of a handle-based lookup.

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

search_kitsSearch kitsA

Read-onlyIdempotent

Inspect

Searches CloneKit's public catalog of kits by keywords, tool ids or area of work. Returns matching public kits ranked by relevance: reference, title, summary, link, creator, the tools each kit uses, whether it is free or paid, and ratings. When no kit matches the keywords, closest lists up to 3 nearby kits. example: true marks sample kits made by CloneKit to show the format.

Name	Required	Description
`q`	No	Keywords describing the task or result, like "landing page design".
`limit`	No	Number of kits per page (default 20, maximum 50).
`query`	No	Same as q.
`tools`	No	Tool ids every returned kit uses, like ["vercel", "supabase"].
`cursor`	No	next_cursor from the previous page of results.
`domain`	No	Area of work.

Output Schema

Name	Required	Description
`kits`	Yes
`count`	Yes
`closest`	No
`next_cursor`	No

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuinely new behavior: results are ranked by relevance, a no-match query falls back to a 'closest' list of up to 3 kits, and 'example: true' flags CloneKit-authored sample kits — details an agent could not derive from the annotations.

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?

Three front-loaded sentences: capability first, then return shape, then edge-case semantics. Dense but every clause carries information; the return-field enumeration is slightly redundant given an output schema exists.

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?

Covers capability, result ranking, fallback behavior, and the sample-kit flag, which is what an agent needs to call and interpret it. Return fields are re-listed despite an output schema, and pagination via limit/cursor is left to the schema, but nothing critical is missing.

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 description coverage is 100%, so the baseline is 3. The description maps its three matching facets to parameters but adds no syntax, format, or interaction detail beyond what the schema already documents (e.g., that 'query' duplicates 'q', how 'limit' and 'cursor' paginate together).

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 ('Searches') and resource ('CloneKit's public catalog of kits') plus the three matching facets (keywords, tool ids, area of work). The 'public catalog' scope distinguishes it from get_kit (single kit by id) and list_creator_kits (creator-scoped listing) without needing to open a schema.

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?

Usage is implied by the search framing: call it when you have keywords, tool ids, or a domain and don't already know the kit id. It never explicitly says when to prefer get_kit or list_creator_kits instead, nor does it state any prerequisites, so guidance remains inferential.

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.

2 tool updatesOct 22, 2026

Changedget_kit1 field changed

changedInput schema / properties / ref / description

Previous value: -"Kit reference, like \"@francisco/whatsapp-agents\"."New value: +"Kit reference, like \"@clonekitai/landing-page-design-loop\"."

Changedget_kit_files1 field changed

changedInput schema / properties / ref / description

Previous value: -"Kit reference, like \"@francisco/whatsapp-agents\"."New value: +"Kit reference, like \"@clonekitai/landing-page-design-loop\"."

7 tool updatesOct 19, 2026

Removedcheck_tools
Removedget_file

Changedget_kit10 fields changed

changedInput schema / properties / ref / description

Previous value: -"Kit reference, like \"@francisco/whatsapp-agents\". Get it from search_kits."New value: +"Kit reference, like \"@francisco/whatsapp-agents\"."

removedInput schema / properties / version

Removed value: -{
-  "description": "Leave it out for the published version. \"draft\" (the newest version, drafts and versions in review included) or a version number: only for the kit's creator and CloneKit reviewers.",
-  "maxLength": 20,
-  "pattern": "^(?:draft|\\d+\\.\\d+\\.\\d+)$",
-  "type": "string"
-}

addedOutput schema / properties / access

Added value: +{
+  "enum": [
+    "free",
+    "paid"
+  ],
+  "type": "string"
+}

changedOutput schema / properties / files / items / additionalProperties
```
Previous value: -falseNew value: +{}
```
removedOutput schema / properties / files / items / properties / title
```
Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}
```

changedOutput schema / properties / files / items / required

Previous value: -[
-  "path",
-  "chars",
-  "title"
-]New value: +[
+  "path",
+  "chars"
+]

removedOutput schema / properties / next

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / price_label
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "ref",
-  "title",
-  "version",
-  "mode",
-  "price_label",
-  "files",
-  "next"
-]New value: +[
+  "ref",
+  "title",
+  "version",
+  "url",
+  "mode",
+  "access",
+  "files"
+]

Addedget_kit_files
Addedlist_creator_kits

Changedsearch_kits22 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / cursor / description

Previous value: -"next_cursor from the previous page, to get more results. There is no next_cursor on the last page."New value: +"next_cursor from the previous page of results."

changedInput schema / properties / limit / description

Previous value: -"How many kits (default 20, at most 50)."New value: +"Number of kits per page (default 20, maximum 50)."

changedInput schema / properties / q / description

Previous value: -"What the user wants to get done, in their words."New value: +"Keywords describing the task or result, like \"landing page design\"."

addedInput schema / properties / query

Added value: +{
+  "description": "Same as q.",
+  "maxLength": 200,
+  "type": "string"
+}

changedInput schema / properties / tools / description

Previous value: -"Tool ids the kit must use, like [\"vercel\", \"supabase\"]."New value: +"Tool ids every returned kit uses, like [\"vercel\", \"supabase\"]."

removedInput schema / properties / tools / examples

Removed value: -[
-  [
-    "whatsapp"
-  ],
-  [
-    "vercel",
-    "supabase"
-  ]
-]

addedOutput schema / properties / closest / items / properties / access

Added value: +{
+  "enum": [
+    "free",
+    "paid"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / closest / items / properties / mode

Added value: +{
+  "enum": [
+    "read",
+    "run"
+  ],
+  "type": "string"
+}

removedOutput schema / properties / closest / items / properties / price_label
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / closest / items / properties / summary
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / closest / items / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / closest / items / required

Previous value: -[
-  "ref",
-  "title",
-  "price_label"
-]New value: +[
+  "ref",
+  "title",
+  "url",
+  "summary",
+  "mode",
+  "access"
+]

addedOutput schema / properties / kits / items / properties / access

Added value: +{
+  "enum": [
+    "free",
+    "paid"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / kits / items / properties / mode

Added value: +{
+  "enum": [
+    "read",
+    "run"
+  ],
+  "type": "string"
+}

removedOutput schema / properties / kits / items / properties / price_label
```
Removed value: -{
-  "type": "string"
-}
```
addedOutput schema / properties / kits / items / properties / summary
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / kits / items / properties / url
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / properties / kits / items / required

Previous value: -[
-  "ref",
-  "title",
-  "price_label"
-]New value: +[
+  "ref",
+  "title",
+  "url",
+  "summary",
+  "mode",
+  "access"
+]

removedOutput schema / properties / next

Removed value: -{
-  "type": "string"
-}

removedOutput schema / properties / next_cursor / description

Removed value: -"Pass as cursor with the same search filters; absent on the final page."

changedOutput schema / required

Previous value: -[
-  "count",
-  "kits",
-  "next"
-]New value: +[
+  "count",
+  "kits"
+]

Removedwhoami

5 tool updatesOct 15, 2026
- First observedcheck_tools
- First observedget_file
- First observedget_kit
- First observedsearch_kits
- First observedwhoami

Related MCP Connectors

MidOS - MCP Community Library A
io.github.MidOSresearch
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
Knowledge & Memory RAG Systems Search
27
https://midos.dev/mcp
bots A
net.urbot
150+ vertical AI expert bots as agent tools. $1 bots run on YOUR machine - your data stays yours.
Agent Orchestration AI & Machine Learning Autonomous Agents
52
https://urbot.net/mcp
skills A
co.tasklinkr
Executable skill packages for agents: vetted competence, ready to run, not just documents.
Agent Orchestration Autonomous Agents Developer Tools
11
https://tasklinkr-mcp-stub.vercel.app/mcp/skills
Project Noosphere A
org.projectnoosphere
An open knowledge commons for AI agents: search versioned how-tos, report whether they worked.
Search Documentation Access Knowledge & Memory
61
https://projectnoosphere.org/mcp

Related MCP Servers

domain-expertise-mcp
Knowledge & Memory
mdfifty50-boop
A
license
Not graded
quality
D
maintenance
Injects structured professional domain expertise into AI agents, providing access to decision frameworks, workflows, terminology, and regulatory context across 24 professional domains.
Updated 6 months ago (2026-04-24 13:40 UTC)
56 npm
MIT
Skillroute MCP
Developer Tools Documentation Access
vaibhavgupta5
A
license
A
quality
D
maintenance
Provides AI agents with a structured library of engineering skills, best practices, and playbooks for software development.
Updated 5 months ago (2026-06-12 09:50 UTC)
2
ISC
Cortex MCP
BasharAmso
A
license
A
quality
D
maintenance
Delivers on-demand knowledge from a built-in library of 728 agents, skills, patterns, and examples across 26 domains to any MCP-compatible AI tool.
Updated 3 months ago (2026-08-20 11:39 UTC)
6
12 npm
1
MIT
Skill7
Developer Tools AI & Machine Learning Knowledge & Memory
Abderraouf-yt
A
license
A
quality
D
maintenance
Provides 634+ curated production-ready AI skills for any MCP-compatible client, covering areas like security, frontend, backend, infrastructure, AI/ML, and architecture. Enables AI agents to access best practices, patterns, and solutions across multiple domains.
Updated 9 months ago (2026-02-07 10:40 UTC)
6
8 npm
1
MIT

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?