@yosider/cosense-mcp-serverと@takker/cosense-mcp-serverを統合
理由
あと似たようなものが複数あると、どっちを使えばいいのかユーザーが混乱してしまうかも
もちろん、yosider.iconさんのご判断を尊重いたします
機能面
ので、COSENSE_PROJECT_NAMEはいらないかもしれない (default project指定用として残すのはあり)
あと、操作できるprojectsを限定するCOSENSE_PROJECT_ALLOW_LISTを新設したほうがいいかも
insert_linesで予期せぬprojectに勝手に書き込まれるのを防ぐとか
すばら.iconyosider.icon
現時点で効果あるか不明
list_pagesで、最新100件以外を取得できるようにしてみたらbsahd.icon
skip大きいと遅くなるの知りませんでしたtakker.icon
タイトルさえわかればいいので、それもありですね
全ページのタイトルを取得する用途でskipをだいぶ上げながら使ってたんだけど、後半だいぶ遅くなってたbsahd.icon
たしかにyosider.icon
これに合わせて、生のページデータを返すget_raw_pageか行IDなどを返すget_page_metadataを追加する
smart contextだと1hopも入るのでその分入力コストが高くなったりしませんか？bsahd.icon
現行のget_pageも1hop入るので特に変わらないと思いますtakker.icon
うん？入力コスト？すみませんちゃんと理解してないかも
1hop先を全て入力させるとコストが高くなる？bsahd.icon
token数が増えるということですねtakker.icon
確かにそうかも
まあとりあえずやってみて、だめなら軽量化optionを用意すればいいと思います
(検討)write_pageの追加
tool呼び出し時に、LLMに現在のlinesを渡し、書き換え後のテキストを要求する
帰ってきたテキストでページ全体を更新する
特定のブロックのみを書き換えるツールにしてもいいかも
これAPI叩くコストが高いからなあ……いるかなあ
search_pagesをproject数分叩くほうがずっと早そう
内部実装面
Denoで動かしている
ファイル数の削減
これは雑に書き換えてたらなんとなくそうなってしまっただけ
ツールごとにファイルを分けるほうが妥当だと思う
ここ気になっているyosider.icon
自分も分けたい派
PageResourceの削除
これは復活したほうがいい。ただclassは不要かも
個人的にはあまり使わないのでなくても良い気もする…が機能としてあるので対応しないのもどうなのかと思うyosider.icon
じつは一旦resource機能をomitしたほうがいいと思っていますtakker.icon
@takker/cosense-mcp-serverでは特定のprojectのページを全てresource listに追加する設計にした
しかし、vscodeだとresource選択画面に大量のページが列挙されてしまい、他のmcp serverのresourceを見つけづらくなる
例えば/takkerを指定すると、10000件以上のresourcesが登録されてしまい、候補がcosenseで埋め尽くされる @yosider/cosense-mcp-serverのresourceはうまく動いてなかった覚えがある(うろ覚え)
検索はされるのだが、なぜかmcp serverに帰ってくるページタイトルが文字化けしてしまう
復元を試みたが、文字化けの仕組みを特定できず断念した
2025-08-17うまくいったtakker.icon
自分の実装ではclassを所々使っているけどTSでは使わないほうが良しとされがちな印象があるので、使わない方向にしたいyosider.icon
ぱっと見の段階ですが、もちろん歓迎です！yosider.icon
後で詳しく見ます
もちろん移行のハードルが低そうであればそれでも大丈夫です
あ、そうかyosider.icon
自分の観測範囲だと井戸端の人くらいしか使ってないが…
PRやissueに海外の人も書いてた覚えあったtakker.icon
ほへ～takker.icon
https://gyazo.com/f34af02364a420b609b2e2a0948649e6
うーん、多少は使われているのか？
まーでもREADMEに「移行しました」と書いておけばいいのではないか
ありがとうございます！takker.icon
大まかにこんな手順でPRしようと思っていますtakker.icon
いったん整理
これと同時に、toolごとにファイルを分ける
2. 複数のproject対応
3. toolの追加
(どこか) pnpmかyarnにpackage managerを置き換える？
良いyosider.icon
user側で.npmrcを用意する必要がなくなる
denoはうまく行かなかったんだっけyosider.icon
serverの更新がうまくいかなかった覚えtakker.icon
もしかしたらちゃんと設定すれば更新できるかも
あとnode使っているユーザーがほとんどだろうから、denoに統合するのはなんだかなあという気持ちがあった
Denoでもいいかなあ
まあnode/deno固有のコードは少ないので、取り急ぎnodeのままにしますtakker.icon
codingは変えようと思えばすぐ変えられる
おkですyosider.icon
package manegerを変えずに、user側で.npmrc不要にしましたtakker.icon
pnpm/yarnはgithubから直接packageを実行できるみたい
pnpm dlx takker99/cosense-mcp-server#resource-completionで、resource-completion branchにあるnpm packageを動かせる
Denoみたいで便利
レビュー遅くなりすみません、確認いただけると幸いですyosider.icon
（院試とか終わってからで大丈夫です）
ありがとうございます！takker.icon
ちなみにcollaboratorに追加したほうがよければしますが、どうでしょうかyosider.icon
むーんどうしましょうかtakker.icon
追加していただけると確かにありがたいのですが、勝手に大改造スマッシュブラザーズしそうで心配です
追加していただくにしても院試のあとがよさげです
👍yosider.icon
copilot coding agent使えるとうれしいですが、設定で使えるようになるのかなtakker.icon
使ったことないのでわからない PRをレビューしてくれたりするのだろうかyosider.icon
契約している必要があるのはリポジトリオーナーなのか、PR authorなのか
やはりcontributerに追加していただいてもよろしいでしょうか？takker.icon
あとreview返信放置してしまい申し訳ないです
正直注意資源が全然足らなくて手が回ってないところです……
なのでcodingをagentにどんどん外注してかないと自分がやりたいことに作業が追いつかないなと最近感じています。
cosense-mcp-serverについても、issue解決や機能追加を全部coding agentに丸投げして開発を進めたいと思っています
ほしいのはプログラムそのものでありcoding体験ではない
codingそのものが目的になってしまうことが往々にしてあるから反省点
で、たぶんcontributerにしてもらえるとcoding agentを使えるようになりそうです (根拠なし)
了解です！yosider.icon
ありがたやtakker.icon
なお、今reviewしていただいているものはagentに委譲できないので、takker.iconがちゃんと返信しようと思っていますtakker.icon
早めにやりたい……
暇な時で大丈夫ですyosider.icon
これどうしましょうかtakker.icon
pnpm/yarnはこれ使うとinstallが楽だよというだけで、developer側は.npmrcがあるので設定の手間はないんですよね。
新たに来るdeveloperが.npmrcを作らなくてもいいようにしたいyosider.icon
もちろんrecommend installationとdev側のpackage managerとを合わせるのはあり。
ただそのように開発環境に手を加えるなら、nodeにするかdenoにするかまで検討したほうがいいのではと思っています
とはいえ、read onlyなどをdenoの権限レベルで制限できるわけではないから、あまり意味はないかも
ページ読み書きはどちらもネットワークアクセスなので、アクセス可否しか制御できない
まあでもこのPRはユーザー用の変更で、開発者用の変更はやるならまた別のPRでやればいいのか
ということでlockfileの件は対応頂かなくて大丈夫です！
pnpm最近使ってるんですが結構早いと感じていて、開発ツールもこっちに寄せたいかも(手のひら返し)takker.icon
まあべつにいいか
pnpmにしましょうyosider.icon
PRしておきます（多分）（してもらってもOKです）