@clawket/mcp
Integrates with GitHub repositories, specifically the Clawket project repository, for accessing and managing project artifacts, tasks, and documentation through semantic search capabilities.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@@clawket/mcpsearch for recent decisions about authentication"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@clawket/mcp
MCP (Model Context Protocol) server for Clawket.
A stdio server that allows LLMs to explore Clawket's RAG repository via pull-based tool_use. It handles exploratory and conditional queries that fixed injection (Push) in the SessionStart hook cannot cover.
Status
Status: Pre-alpha / Scaffolding (CK-299)
Spec: Clawket artifact ART-01KPCQ4ZPF0HHJ029WERJAHWD3
Unit: P7 (UNIT-01KPCPQKDW2NQ91BJC6HFN8XQB)
Tools have not been implemented yet. It only responds to stdio handshakes after build.
Installation
It is automatically installed alongside the Clawket CLI (since CK-302).
pnpm install @clawket/mcp # 단독 사용 시Execution
Automatic startup as a Claude Code plugin (Recommended, since CK-303)
Installing the Seungwoo321-clawket plugin will automatically register .mcp.json.
Manual execution
clawket mcp # CK-302 이후: CLI 서브커맨드
node dist/index.js # 빌드 후 직접 실행Exposed Tools (Planned)
Tool | Purpose |
| Semantic search for design documents and decisions |
| Task search |
| Extract similar past tasks + decisions/issues |
| Aggregate artifacts, relationships, and comments around a specific task |
| Recent decisions (artifact type=decision) |
For detailed specifications, refer to artifact ART-01KPCQ4ZPF0HHJ029WERJAHWD3 in the Clawket DB.
Development
pnpm install
pnpm build # TypeScript → dist/
pnpm dev # watch 모드Daemon Connection
Default: Read port from
~/.cache/clawket/clawketd.portOverride:
CLAWKET_DAEMON_URL=http://localhost:PORTenvironment variable
Architectural Principles
Read-only — State changes are the responsibility of the
clawketCLIIndependent Package — Importing
lattice-codex/code is prohibited; rely only on HTTP APIPull-only — Complements SessionStart injection (Push); duplicate results are marked as
_already_injected
License
MIT
Available Tools
5 toolsclawket_find_similar_tasksFind similar Clawket tasksA
특정 Task와 의미적으로 유사한 과거 Task들을 찾습니다. 주로 "이 작업 전에 비슷한 이슈를 해결한 적 있는지?" 확인용. task_id 제공 시: 해당 태스크의 title+body 임베딩으로 KNN 검색. query 제공 시: 자유 쿼리 기반 검색. 결정·이슈 패턴(결정:, Decision:, 이슈:, Issue: 등)을 코멘트에서 추출해 decisions/issues 필드에 포함합니다. 반환: ticket_number, title, status, distance, extracted(decisions, issues). 비슷한 작업 유무만 확인하려면 clawket_search_tasks가 더 가볍습니다.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | No | 시드 Task ID(TASK-ULID 또는 CK-xxx). 지정 시 query 무시. | |
| query | No | 자유 쿼리 (task_id 미지정 시 필수) | |
| limit | No | 반환 개수 (1~30, 기본 5) | |
| status | No | 상태 필터 (기본 없음) | |
| include_extracted | No | 코멘트에서 decisions/issues 추출 여부 (기본 true) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: uses title+body embedding for KNN search, extracts decisions/issues from comments. Describes return fields. Could be more explicit about task_id taking precedence over query, but overall well-covered.
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?
Five sentences covering all essential aspects: purpose, modes, extraction, return fields, and alternative tool. No redundant information.
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 no output schema, the description explains return fields. Covers all parameters with behavioral context. Lacks details on error handling or rate limits, but acceptable for a similarity search tool.
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 has 100% description coverage, but the description adds value by explaining the two modes (task_id vs query), embedding usage, and extraction flag. It goes beyond schema definitions.
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 it finds semantically similar past tasks using embedding-based search or query. It distinguishes from the sibling tool clawket_search_tasks by noting that the latter is lighter for checking existence only.
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?
Explicitly states the primary use case: checking if similar issues were resolved before. Also provides an alternative: 'if only checking existence, use clawket_search_tasks'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clawket_get_recent_decisionsGet recent Clawket decisionsA
최근 결정(Artifact type=decision, scope=rag)을 목록 조회합니다. 세션 시작 시 "지난 회차에서 어떤 결정이 있었지?" 확인용. 자연어 검색이 아닌 타입 기반 필터 — 키워드 탐색은 clawket_search_artifacts를 사용하세요. plan_id 미지정 시 전체 프로젝트의 결정을 최신순으로 반환.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | No | 특정 Plan에 속한 결정만 (선택) | |
| limit | No | 반환 개수 (1~30, 기본 10) | |
| since_ts | No | Unix ms 이후 생성된 결정만 (선택) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it is a read-only list operation, orders by latest, scoped to rag, and uses type-based filtering. Could mention idempotency or pagination, but sufficient for the use case.
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?
Three compact sentences front-load the purpose, include usage context, and provide alternative tool reference without waste.
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?
The description covers purpose, usage, parameter behavior, and sibling differentiation. Missing details about output format, but reasonable given no output schema.
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 that omitting plan_id returns results from all projects, enhancing understanding beyond the schema descriptions.
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 lists recent decisions of artifact type decision with scope rag, and distinguishes itself from sibling clawket_search_artifacts by specifying it is type-based filtering, not natural language search.
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?
Explicitly says to use at session start to check past decisions, and for keyword exploration to use clawket_search_artifacts instead, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clawket_get_task_contextGet Clawket task contextA
특정 Task의 주변 맥락(관련 아티팩트, 관계, 코멘트, 이력)을 일괄 조회합니다. "이 티켓이 무슨 배경으로 만들어졌는지" 파악할 때 사용. 기본 include: artifacts, relations. comments/history는 명시적으로 추가. 아티팩트는 scope=rag만 스니펫 반환. 전체 내용은 별도 조회 필요.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Task ID (TASK-ULID 또는 CK-xxx) | |
| include | No | 포함할 섹션 (기본 [artifacts, relations]) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that artifacts return only snippets for scope=rag and full content requires separate call. Does not mention side effects or 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 in Korean, front-loaded with purpose, no redundancy. Efficient but could be slightly more structured.
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?
Adequately covers key behaviors and defaults for a 2-parameter tool. No output schema, but description provides sufficient context for usage.
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 has 100% description coverage, but description adds value by explaining default values for include parameter ('기본 [artifacts, relations]') and behavior for artifact snippets.
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?
Description clearly states the tool retrieves context around a task (artifacts, relations, etc.) and provides a use case ('figure out background of a ticket'), effectively distinguishing it from sibling tools like search or decisions.
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?
States when to use (background of a ticket), specifies default includes, and notes that comments/history require explicit addition. However, lacks direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clawket_search_artifactsSearch Clawket artifactsA
프로젝트의 설계 문서·결정사항·스펙(아티팩트 scope=rag)을 시맨틱/키워드 하이브리드로 검색합니다. 이전 세션의 결정사항을 찾거나, 특정 주제(예: "RAG 청킹 전략", "데몬 포트 설정")의 문서를 탐색할 때 사용하세요. 반환: 제목, 타입, 스니펫(300자), 유사도. 전체 내용이 필요하면 get_task_context 또는 별도 조회를 이용하세요. archive·reference 스코프는 접근 불가 — rag 스코프만 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색 쿼리 (자연어 또는 키워드) | |
| mode | No | 검색 모드. keyword=FTS5, semantic=벡터, hybrid=병합(기본) | |
| limit | No | 반환 개수 (1~30, 기본 10) | |
| type_filter | No | 아티팩트 타입 필터 (선택) | |
| plan_id | No | 특정 Plan에 속한 아티팩트만 (선택) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: hybrid search method, return fields (title, type, snippet of 300 chars, similarity), and scope limitation. No contradictions.
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?
Description is a single paragraph with clear structure: purpose, usage, return info, limitations. Efficient but could be slightly more concise.
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 description explains return values (title, type, snippet, similarity) and scope. Lacks pagination info but sufficient for a search tool.
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 detailed parameter descriptions. The tool description adds minimal new info about parameters (only reiterates mode semantics). Baseline 3 is appropriate.
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 searches project artifacts (design docs, decisions, specs) using semantic/keyword hybrid search, specifically for the 'rag' scope. It distinguishes from sibling tools like clawket_search_tasks by explicitly targeting artifacts.
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 use cases (finding previous decisions, exploring topics) and alternatives (get_task_context for full content). Also states inaccessible scopes (archive, reference), guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
clawket_search_tasksSearch Clawket tasksA
Clawket의 Task(작업 티켓)를 시맨틱/키워드 하이브리드로 검색합니다. 과거에 비슷한 작업을 했는지, 관련 티켓이 있는지 확인할 때 사용하세요. 더 풍부한 패턴/결정 추출이 필요하면 find_similar_tasks를 사용하세요. 반환: ticket_number(CK-xxx), title, status, priority, unit_id, 유사도.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 검색 쿼리 | |
| mode | No | 검색 모드 (기본 hybrid) | |
| limit | No | 반환 개수 (1~30, 기본 10) | |
| status | No | 특정 상태로 필터 (선택) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses search method (hybrid) and return fields (ticket_number, title, status, etc.), providing complete behavioral context.
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?
Concise single sentence with clear purpose, usage, and return info. Slightly dense but effective.
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?
Describes search method, filtering, and return format. No output schema needed since fields are listed. Complete for its purpose.
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 already covers parameters well (100%). Description adds little beyond stating hybrid search for mode, but does not deepen meaning for query, limit, or status.
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 searches Clawket tasks using semantic/keyword hybrid, and distinguishes from siblings like find_similar_tasks.
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?
Explicitly states when to use (checking past similar work or related tickets) and when not (use find_similar_tasks for richer pattern extraction).
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.
5 tool updates
v0.1.0- First observed
clawket_find_similar_tasks - First observed
clawket_get_recent_decisions - First observed
clawket_get_task_context - First observed
clawket_search_artifacts - First observed
clawket_search_tasks
TDQS
Scored across 5 tools
Tools are mostly distinct, with clear descriptions differentiating the two task search tools (find_similar_tasks vs search_tasks) and the two artifact tools (search_artifacts vs get_recent_decisions). However, some overlap exists between search_tasks and find_similar_tasks that could cause confusion if descriptions are not read carefully.
All tools follow a consistent prefix 'clawket_' with snake_case and verb_noun pattern (find_similar_tasks, get_recent_decisions, get_task_context, search_artifacts, search_tasks). No mixing of conventions.
5 tools is a well-scoped set for a retrieval-focused server covering task search, artifact search, context, and decisions. Neither too few nor too many for the domain.
The tools cover key retrieval needs (search tasks, find similar tasks, search artifacts, get context, list decisions). Minor gaps include the absence of a direct 'get artifact' or 'get task detail' tool, but the descriptions indicate context and snippets are provided, and full content can be obtained separately.
Maintenance
Related MCP Connectors
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
MCP server for searching Airweave collections with natural language queries.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
