wellulu-insight
Allows automatically saving insights from conversations as GitHub Issues, with tools to create, list, and search insights.
Click on "Install 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., "@wellulu-insightCreate an insight about the new feature request"
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.
wellulu-insight
Claude との会話から自動でインサイトを GitHub Issues に保存する MCP サーバーです。
機能
create_insight— インサイトを Issue として保存list_insights— カテゴリ・ステータスで一覧取得search_insights— キーワード検索
Related MCP server: mcp-github-pm
セットアップ
1. 依存関係のインストール
npm install2. GitHub Personal Access Token の作成
GitHub Settings で repo スコープのトークンを作成してください。
3. Claude Desktop への登録
%APPDATA%\Claude\claude_desktop_config.json(Windows)または~/Library/Application Support/Claude/claude_desktop_config.json(macOS)に追記:
{
"mcpServers": {
"wellulu-insight": {
"command": "node",
"args": ["C:/path/to/wellulu-insight/mcp/index.mjs"],
"env": {
"GITHUB_TOKEN": "your_github_pat",
"GITHUB_OWNER": "DonoueKen",
"GITHUB_REPO": "wellulu-insight"
}
}
}
}4. Claude プロジェクト指示の設定
prompts/claude-project-instructions.md の内容を Claude のプロジェクト指示にコピーしてください。
ディレクトリ構成
mcp/index.mjs # MCP サーバー本体
package.json # 依存関係
prompts/claude-project-instructions.md # Claude への自動保存指示
.github/ISSUE_TEMPLATE/insight.yml # Issue テンプレートAvailable Tools
3 toolscreate_insightA
会話から得られたインサイトを GitHub Issue として保存する
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | インサイトのタイトル | |
| summary | Yes | インサイトの概要(1〜2文) | |
| detail | No | インサイトの詳細内容 | |
| category | Yes | カテゴリ | |
| tags | No | タグの配列 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions saving to GitHub Issues, indicating a side effect, but does not disclose details like authentication needs, rate limits, or what happens on success/failure. No annotations are provided to compensate.
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, front-loaded sentence with no wasted words. It conveys the core purpose efficiently.
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 tool has 5 parameters (all described) and no output schema, the description is adequate for a simple creation tool. It could mention return value or error scenarios, but it is largely 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 description coverage is 100%, so parameters are well-documented there. The description adds no additional meaning beyond the schema.
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 verb 'save' and resource 'insights as GitHub Issues'. It distinguishes itself from sibling tools list_insights and search_insights, which are read-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?
The description implies usage when creating a new insight, but does not explicitly state when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_insightsB
保存済みインサイトの一覧を取得する
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 絞り込むカテゴリ(省略時は全件) | |
| state | No | Issue のステータス(デフォルト: open) | |
| limit | No | 取得件数(デフォルト: 20) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'get a list.' Does not disclose pagination, ordering, default behavior, or any side effects. Fails to compensate for missing annotations.
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?
Single short sentence is concise but lacks sufficient detail. Every sentence should earn its place, but this one is too sparse to be fully 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?
No output schema, no behavioral details, and no annotations. The description does not explain what the list contains or how results are structured. Incomplete for a tool with 3 parameters.
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% coverage with descriptions. Description adds no additional meaning beyond what schema already provides. Baseline score 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?
Description clearly states 'list saved insights,' which is a specific verb+resource combination. It distinguishes from sibling tools create_insight and search_insights by implying retrieval of existing items rather than creation or searching.
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?
No guidance on when to use this tool versus search_insights or create_insight. Lacks context for selection between list and search alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_insightsB
インサイトをキーワードで検索する
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 検索キーワード | |
| limit | No | 取得件数(デフォルト: 10) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose behaviors like case sensitivity, match type, or handling of empty queries, which are critical for a search tool.
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, which is concise, but it lacks detail. It leaves out important information that could be added without significantly lengthening it, making it under-specified.
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 and simple parameters, the description should at least mention search behavior (e.g., exact match, partial match) or output format. It does not, leaving incompleteness.
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 description coverage is 100%, so both parameters have descriptions in Japanese. The tool description adds no extra meaning beyond the schema, baseline holds at 3.
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's purpose: searching insights by keyword. It distinguishes from sibling tools 'create_insight' and 'list_insights' by specifying the search action and resource.
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?
No explicit guidance on when to use this tool vs siblings. The description implies keyword-based search but doesn't mention exclusions or when to use 'list_insights' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Each tool has a clear and distinct purpose: create, list, and search insights. No overlap in functionality.
All tools use a consistent verb_noun pattern in snake_case (create_insight, list_insights, search_insights).
3 tools is slightly low but appropriate for a focused insight management server. Each tool serves a core operation.
The set covers create, list, and search, but lacks update and delete operations, which are notable gaps for full lifecycle management.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables Claude to manage GitHub Gists as an intelligent code library, allowing users to save, retrieve, update, and organize code snippets from anywhere with natural language commands.
- AlicenseBqualityDmaintenanceEnables GitHub project management from Claude, supporting issue creation, milestones, labels, changelog generation, and repository stats.8121MIT
- FlicenseNot gradedqualityCmaintenanceEnables to interact with GitHub repositories directly from Claude, supporting actions like viewing repos, checking status, committing and pushing changes, and managing pull requests.
- FlicenseNot gradedqualityCmaintenanceAutomatically saves valuable insights, learnings, and business knowledge from Claude conversations as GitHub Issues, categorized and searchable.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DonoueKen/wellulu-insight'
If you have feedback or need assistance with the MCP directory API, please join our Discord server