Custom MCP ควรอยู่ใน repo ของคุณ: ทางแก้ agent drift ที่ใช้เวลา 60 วินาที

ในเดือน October 2025 GitHub commit เดียวปล่อย "skills" ที่ generate ด้วย LLM จำนวน 47 ตัวลงใน agent repository ยอดนิยม หนึ่งในนั้นสอนให้ Claude รัน npx react-codeshift แต่ package นั้นไม่มีอยู่ ไม่เคยมีอยู่เลย Claude hallucinate ขึ้นมาในช่วง training ผู้เขียนไม่ได้ตรวจสอบ และภายในไม่กี่สัปดาห์ไฟล์นั้นแพร่กระจายไปยัง 237 forks นักพัฒนาจริงรัน command นั้นใน terminal จริง npm พยายาม resolve package ที่เป็นภาพลวงตาหลายพันครั้งอย่างเต็มใจ

นี่คือส่วนหนึ่งของเรื่องราว AI agent ที่ไม่ได้ขึ้น keynote Agent drift เมื่อให้ shell และงานคลุมเครือ พวกมันจะหยิบ command ที่ฟังดูสมเหตุสมผลที่สุด แม้มันจะไม่มีอยู่ — และยิ่งให้ tool ทั่วไปมากเท่าไหร่ พวกมันยิ่ง drift มากขึ้น

คำตอบมาตรฐานในปี 2026 คือ: เขียน custom MCP server กำหนด action ที่อยากให้ agent ทำ ให้ schema เข้มงวด ship เป็น binary แยก register ใน config ของ agent จำกัด model โดยให้ tool เฉพาะแทนที่จะให้ bash

คำตอบมาตรฐานนั้นถูกในหลักการแต่ผิดในทางปฏิบัติ การเขียน MCP server จริง — JSON-RPC framing, stdio handshake, schema definition, dependency tree แยก — เพื่อ shell command เดียวคือ engineering theater ทีมส่วนใหญ่ยอมแพ้และอยู่กับ drift

Octomind 0.29.0 ปิดช่องว่างนั้น Custom MCP ไม่ควรเป็นโปรเจกต์ มันควรเป็นไฟล์ใน repo ของคุณ

ปัญหา Drift ที่มีตัวเลขสนับสนุน

ถ้าคุณดู agent รันมาสักพัก คุณจะเห็น drift:

มันรัน npm test ใน pnpm monorepo
มัน curl https://staging.example.com/api แทน https://api-staging.acme.internal/v3 ตัวจริงที่มี auth-gated
มันพยายามติดตั้ง package ที่ชื่อเกือบใช่แต่ไม่ใช่
มันใช้ git tag ดิบแทน release script ของทีม

paper เดือน May 2025 RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection (Gan & Sun) ทำ MCP stress test และพบว่า baseline tool-selection accuracy ลดลงเหลือ 13.62% เมื่อ scale — model ไม่สามารถเลือก tool ที่ถูกได้อย่างน่าเชื่อถืออีกต่อไป เพราะ description ของทุก tool ที่มันต้องพิจารณานั้นเบียดเสียด prompt และเจือจาง attention วิธีแก้แบบ retrieval ของพวกเขาทำให้สูงขึ้นกว่าสามเท่าเป็น 43.13% พร้อมลด prompt token ลงกว่า 50% accuracy ยังแย่อยู่ แต่ทิศทางของกราฟคือประเด็น: ยิ่งยัด tool เข้าไปมากเท่าไหร่ model ยิ่งเลือกได้แย่ลง

Anthropic ผู้เขียน MCP protocol ยอมรับประเด็นเดียวกันเมื่อ November 4, 2025:

"In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request." (ในกรณีที่ agent เชื่อมต่อกับ tool หลายพันตัว พวกมันต้องประมวลผล token หลายแสนตัวก่อนอ่าน request)

benchmark ของพวกเขาเองแสดงว่า flow Drive → Salesforce ใช้ 150,000 token ภายใต้ MCP loading แบบ naive ด้วย code-execution และ on-demand tool discovery flow เดียวกันรันใน 2,000 token — ลดลง 98.7% Tool Search Tool ตามมา (API version 20251119) เลื่อน tool definition ไว้จนกว่าจะต้องการ documentation ระบุว่าโดยทั่วไปลด context bloat ลงกว่า 85% และระบุว่า "Claude's ability to correctly pick the right tool degrades significantly once you exceed 30–50 available tools." (ความสามารถของ Claude ในการเลือก tool ที่ถูกต้องเสื่อมลงอย่างมีนัยสำคัญเมื่อเกิน 30–50 available tools)

บทเรียนที่ทุกคนกำลังหลอมรวม: tool ที่น้อยกว่า แคบกว่า เกี่ยวข้องกับโปรเจกต์ ชนะ catalog ขนาดใหญ่ทุกครั้ง model ทำงานได้ดีกว่า ค่า token ลดลง drift ลดลงตามไปด้วย

ดังนั้นคำถามที่ถูกไม่ใช่ "ฉันจะเขียน MCP เพิ่มอย่างไร" แต่เป็น "ฉันจะทำให้ MCP ที่ฉันต้องการจริงๆ เขียนและ ship โดยไม่มีต้นทุนได้อย่างไร"

ทำไม "แค่เขียน MCP server" ถึง scale ไม่ได้

การวิเคราะห์ MCP server 1,412 ตัวของ Bloomberry เดือน February 2026 พบว่า 38.7% ของพวกมัน ship โดยไม่มี authentication เลย median server expose แค่ five tools และประมาณครึ่งหนึ่งของบริษัทที่ publish ไม่มี public API ตั้งแต่แรก กรอบของ Bloomberry: "MCP might not be a wrapper on an existing API. It might be the first machine-readable interface they've ever shipped." (MCP อาจไม่ใช่ wrapper บน API ที่มีอยู่ มันอาจเป็น machine-readable interface แรกที่พวกเขาเคย ship) การระเบิดส่วนใหญ่คือการ ship โดยคนที่กำลังคิดออกใน production

ปัญหาไม่ใช่ว่า protocol พัง แต่ unit of work ผิด สำหรับ action เฉพาะโปรเจกต์ การเขียน MCP server ภาษา Python หรือ Node ด้วย stdio framing, schema registration และ deployment pipeline แยกนั้นเป็นรูปทรงที่ถูกสำหรับ "GitHub API" หรือ "Postgres database" มันเป็นรูปทรงที่ผิดสำหรับ "รัน staging deploy script ของเรา" — โค้ดที่เป็น bash สี่สิบบรรทัด อยู่ใน bin/deploy แล้ว ที่คุณอยากให้ agent เรียกตามชื่อแทนที่จะเดา

ผู้ปฏิบัติงานก็มาถึงข้อสรุปเดียวกัน จากกระทู้ Hacker News "MCP explained without hype or fluff" (item 44063141), commenter 0x457:

"Many of MCPs shouldn't have existed, IMO. […] I wanted amazon q to interact with github, so I added to its context that it can use gh-cli and it it worked pretty well. […] To make its and mine life easier, common things were saved as scripts in bin/ and Justfile (also generated by it). […] Using github's official MCP bricks chat session every time for me."

และ dvt:

"MCP is bloated AI hype that basically solves nothing […]. It's APIs talking to APIs that talk to other APIs."

ทั้งสองความเห็นถูกต้องเกี่ยวกับเคสที่พวกเขาอธิบาย CLI ทำงานได้ Local script ใน bin/ ทำงานได้ การ wrap shell command บรรทัดเดียวใน MCP server 200 บรรทัดเพราะนั่นคือ pattern ที่ถูก bless อย่างเดียวคือสิ่งที่พัง

MCP tool คืออะไรจริงๆ

ลอก protocol ออก MCP tool คือสามอย่าง:

ชื่อและ description เพื่อให้ model รู้ว่าเมื่อไหร่ควรหยิบมาใช้
Parameter schema เพื่อให้ model รู้ว่าควรส่งอะไร
Executable ที่ทำงาน

ทุกอย่างที่เหลือ — JSON-RPC framing, stdio handshake, capability negotiation — เป็นเรื่องของ runtime ไม่ใช่เรื่องของ author paper ปี 2023 Tool Documentation Enables Zero-Shot Tool-Usage with Large Language Models (Hsieh et al.) แสดงเชิงประจักษ์ว่าสำหรับ tool ที่ไม่คุ้นเคย documentation ที่ชัดเจนชนะ few-shot demonstration — และว่า "zero-shot prompts with only tool documentation" สามารถเทียบเท่า few-shot prompt บนงาน out-of-distribution นัยยะ: description ที่สั้นและแม่นยำบน tool มีค่ามากกว่า schema ซับซ้อนหรือกอง example

ถ้า tool สั้น และ docs สั้น interface ทั้งหมดควรแสดงได้ในไม่กี่บรรทัดของ header comment บนสคริปต์ที่ทำงาน

นั่นคือสิ่งที่ Octomind 0.29.0 ทำ

Pattern: `.agents/tools/<name>`

นี่คือสัญญาทั้งหมด:

mkdir -p .agents/tools
cat > .agents/tools/deploy <<'EOF'
#!/usr/bin/env bash
# @description Deploy the API service to a target environment using our team's pipeline.
# @param *env string Target environment (staging|production)
# @param dry_run boolean If true, validate without applying

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

env="$OCTOMIND_PARAM_ENV"
dry="${OCTOMIND_PARAM_DRY_RUN:-false}"

if [[ "$dry" == "true" ]]; then
  ./bin/deploy --env "$env" --dry-run
else
  ./bin/deploy --env "$env"
fi
EOF
chmod +x .agents/tools/deploy

มีสามอย่างเพิ่งเกิดขึ้น:

Octomind ค้นพบสคริปต์ครั้งถัดไปที่ session รัน
มัน parse บรรทัด @description และ @param เป็น JSON-Schema tool definition
model ตอนนี้เห็น tool deploy — scope กับ repo นี้ — ที่มี env (required) และ dry_run (optional) มันจะเลือก deploy(env="staging") มากกว่า bash("./bin/deploy --env staging") เพราะ named tool มี signal-to-noise ratio ที่ชัดเจนกว่า

ความพึงพอใจนั้นคือ guardrail ที่คุณต้องการ model ไม่ได้ free-associate จาก "deploy" ไปยัง "kubectl apply" ไปยัง "helm install" อีกต่อไป มัน entry point เดียว ด้วย typed parameter ที่ทำ deploy จริงของทีม

เพื่อตรวจสอบ wiring รัน validation บรรทัดเดียว:

echo "/mcp" | octomind run

คุณจะเห็น local MCP server ใน output โดยมี deploy listed ใต้ ถ้าสคริปต์ไม่ปรากฏ runtime จะบอกคุณว่าทำไม — permission ผิด, ขาด @description, มีจุดในชื่อไฟล์

กายวิภาคของ Header

comment block นำหน้าคือ interface ทั้งหมด Octomind อ่านมันใหม่ทุก turn (ราคาถูก — read_dir หนึ่งครั้ง) และ rebuild schema แก้และ save call tool ครั้งถัดไปใช้ version ใหม่ ไม่ต้อง restart daemon

#!/usr/bin/env bash
# @description Short summary the model sees. Continuation lines without an
# @-tag append to the previous one, so multi-line descriptions Just Work.
# @param *target string Path to operate on (* prefix = required)
# @param force boolean Overwrite if the destination exists
# @param count integer Number of iterations
# @param tags array JSON list, e.g. ["foo","bar"]

prefix ของ comment สามารถเป็น # (bash, python, ruby, lua, perl, awk), // (node, deno), หรือ -- (lua, SQL wrappers) runtime ไม่สนใจว่าภาษาไหนรันงาน

เมื่อ model เรียก tool octomind ส่ง parameter ให้คุณสองทาง:

Channel	Form
stdin	JSON object หนึ่งตัวตามด้วย EOF: `{"target":"src/x","force":true}`
env	`OCTOMIND_PARAM_TARGET=src/x`, `OCTOMIND_PARAM_FORCE=true`, รวมถึง `OCTOMIND_WORKDIR` และ `OCTOMIND_TOOL_NAME`

Bash script มักอ่าน env var Python script มักอ่าน stdin JSON ทั้งสองมาถึงทุก call Stdout กลายเป็นผลลัพธ์ที่ model เห็น Stderr ถูก append ด้วย marker [stderr] Exit ไม่ใช่ศูนย์ → tool error

นั่นคือพื้นผิวทั้งหมด

Drift จริงสี่อย่าง tool จริงสี่ตัว

เราเฝ้าดู agent ล้มเหลวในแต่ละสถานการณ์นี้ใน repo ของเราเองก่อนเขียน wrapper. Wrapper คือสิ่งที่หยุดมัน

1. Drift: "มันรัน `npm test` ใน `pnpm` monorepo"

agent เห็น package.json ที่ root พิมพ์ npm test ได้ error "no script found" เต็มหน้าจอ และรายงานว่าโปรเจกต์พัง

Wrapper — .agents/tools/test:

#!/usr/bin/env bash
# @description Run the project test suite. Defaults to fast unit tests.
# @param scope string One of: unit, integration, all (default: unit)
# @param package string Optional package filter, e.g. @acme/api

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

scope="${OCTOMIND_PARAM_SCOPE:-unit}"
pkg="${OCTOMIND_PARAM_PACKAGE:-}"

case "$scope" in
  unit)        cmd=("pnpm" "-r" "test:unit") ;;
  integration) cmd=("pnpm" "-r" "test:integration" "--" "--runInBand") ;;
  all)         cmd=("pnpm" "-r" "test") ;;
  *) echo "Unknown scope: $scope" >&2; exit 2 ;;
esac

[[ -n "$pkg" ]] && cmd+=("--filter" "$pkg")
exec "${cmd[@]}"

ตอนนี้ agent เห็น test(scope, package) ใน tool list ของมัน description บอกค่า default มันเรียก test() และได้ผลจริงในครั้งแรก ไม่มีใครในทีมพิมพ์ "ใช้ pnpm -r test:unit" ลงในหน้าต่าง chat อีก

2. Drift: "มัน hallucinate URL ของ staging"

agent ต้องอ่าน record จาก staging API จริงของคุณที่ https://api-staging.acme.internal/v3/users/42 ซึ่งต้องการ header X-Acme-Token มันกลับ curl https://staging.example.com/api/users/42 — URL ที่มันแต่งขึ้นจากข้อมูล training — ไม่ได้อะไรกลับมาและรายงานว่า service down

Wrapper — .agents/tools/api:

#!/usr/bin/env bash
# @description Call our internal staging API. Returns raw JSON.
# @param *path string Path under /v3, e.g. /users/42
# @param method string HTTP method (default: GET)
# @param body string Optional JSON body for POST/PUT/PATCH

set -euo pipefail
: "${ACME_STAGING_TOKEN:?ACME_STAGING_TOKEN not set in environment}"

path="$OCTOMIND_PARAM_PATH"
method="${OCTOMIND_PARAM_METHOD:-GET}"
body="${OCTOMIND_PARAM_BODY:-}"
url="https://api-staging.acme.internal/v3${path}"

args=(-sS -X "$method" -H "X-Acme-Token: $ACME_STAGING_TOKEN")
[[ -n "$body" ]] && args+=(-H "Content-Type: application/json" --data "$body")

curl "${args[@]}" "$url"

URL ไม่ drift อีกต่อไปเพราะ URL ไม่ใช่หน้าที่ของ model อีก agent เรียก api(path="/users/42") และ URL จริงอยู่ในสคริปต์ Token มาจาก environment ของนักพัฒนา (.envrc, direnv, shell rc ของคุณ) — tool ถูก commit, secret ไม่

3. Drift: "มันอธิบาย feature flag service ซ้ำเป็นครั้งที่สี่"

agent debug ปัญหา UI คุณเตือนมัน (อีกครั้ง) ว่า feature-flag service มีอยู่ ว่า flag แตกต่างกันต่อ environment และ staging คือตัวที่เกี่ยวข้อง มันพยักหน้า ลืม ถามอีกครั้งใน session ถัดไป

Wrapper — .agents/tools/flags:

#!/usr/bin/env python3
# @description Return the currently enabled feature flags for an environment.
# @param env string Environment to inspect (default: staging)

import json, os, sys, urllib.request

params = json.load(sys.stdin) if not sys.stdin.isatty() else {}
env = params.get("env") or os.environ.get("OCTOMIND_PARAM_ENV") or "staging"

url = f"https://flags.acme.internal/api/snapshot?env={env}"
req = urllib.request.Request(url, headers={"X-Acme-Token": os.environ["ACME_TOKEN"]})

with urllib.request.urlopen(req, timeout=10) as r:
    flags = json.load(r)

enabled = sorted(k for k, v in flags.items() if v.get("enabled"))
print("\n".join(enabled) if enabled else "(no flags enabled)")

ตอนนี้ model เปิด session เห็น flags ใน tool list และเรียกเองเมื่อต้องการ คุณหยุดเป็น cache มนุษย์สำหรับ "อะไรเปิดอยู่บน staging"

4. Drift: "มันใช้ `git tag` แทน release script ของเรา"

ทีมของคุณสร้าง acme-cli เพื่อให้ version bump, changelog, และ tag-then-push เกิดขึ้นในลำดับที่ถูก agent ข้ามมัน รัน git tag v1.2.3 ดิบ ทำลาย convention และตอนนี้ CI run ครั้งถัดไปหา changelog ไม่เจอ

Wrapper — .agents/tools/release:

#!/usr/bin/env bash
# @description Cut a release using the team's acme-cli. Bumps version, updates
# CHANGELOG, tags the commit, and pushes. Use bump=patch unless minor or major
# is explicitly requested.
# @param *bump string One of: patch, minor, major
# @param dry_run boolean If true, show what would happen without pushing

set -euo pipefail
cd "$OCTOMIND_WORKDIR"

bump="$OCTOMIND_PARAM_BUMP"
dry="${OCTOMIND_PARAM_DRY_RUN:-false}"

args=(release --bump "$bump")
[[ "$dry" == "true" ]] && args+=(--dry-run)

acme-cli "${args[@]}"

นี่คือตัวที่ชนะใจเพื่อนร่วมทีม agent ตอนนี้ปฏิบัติตาม release convention ของทีมด้วยตัวเอง — version, changelog, tag, push — เพราะ tool มีอยู่ ใน repo และ model เลือกมันมากกว่า git ดิบ

Compounding Effect: มันอยู่ใน Repo

โพสต์ MCP code-execution ของ Anthropic เถียงว่าอนาคตคือ dynamic discovery: load tool เมื่อต้องการ drop เมื่อไม่ต้อง shebang pattern คือเวอร์ชัน local-first ของไอเดียนั้น สามคุณสมบัติซ้อนกัน:

1. พื้นผิวแคบ drift ต่ำ model เห็น action ที่ตั้งชื่อแล้ว มี parameter พร้อม description บรรทัดเดียวแทน shell ทั่วไป Hsieh et al. พบว่า description เองทำงานส่วนใหญ่สำหรับ tool selection — example เป็นแค่ nice-to-have shebang header คือรูปทรงที่ถูกต้องสำหรับสิ่งนั้น: ชื่อ, description, typed param, ทุกอย่างใน comment block ที่ tool author maintain ควบคู่กับโค้ดอยู่แล้ว

2. ทั้งทีมได้มาฟรี MCP server แบบดั้งเดิมอยู่บน laptop ของนักพัฒนาคนเดียว เมื่อเพื่อนร่วมทีม clone repo server ไม่อยู่ที่นั่น agent ไม่เห็น tool และ drift กลับมา สคริปต์ .agents/tools/ ถูก commit เข้า git Clone, octomind run, tool เดียวกันกับทุกคน

3. tool วิวัฒน์ไปกับโค้ด เปลี่ยนชื่อ service? อัปเดต wrapper ใน PR เดียวกัน เพิ่ม feature flag? อัปเดต wrapper ใน PR เดียวกัน AI tooling ของคุณอยู่ภายใต้ code review เหมือนสิ่งอื่นๆ drift ระหว่าง สิ่งที่ agent คิดว่า repo เป็นยังไง และ สิ่งที่ repo เป็นจริงๆ — ฆาตกร reliability ของ agent ที่เผาช้าๆ — ปิดเองอัตโนมัติ

หลังจากหนึ่งสัปดาห์ของสิ่งนี้ agent ใน terminal ของนักพัฒนาทุกคนหลอมรวมเป็นพฤติกรรมเดียวกันเพราะทุกคนรัน tool เดียวกันจาก repo เดียวกัน ความรู้เชิงสถาบันหยุดเป็น "สิ่งที่ฉันบอก agent ใน chat" และเริ่มเป็น artifact ที่มี version และตรวจสอบได้

เมื่อไหร่ควรหันไปใช้ MCP Server แทน

Local tool ครอบคลุม 90% ที่เฉพาะโปรเจกต์ มันไม่ครอบคลุมทุกอย่าง ใช้ matrix นี้:

คุณต้องการ…	ใช้
Action เฉพาะโปรเจกต์ (deploy, test, query flag, hit endpoint ภายใน)	`.agents/tools/` shebang
ฉีด instruction ของ domain เข้า context	Skills
Tool ที่ใช้ซ้ำข้ามโปรเจกต์ที่มี schema รวยและ logic หลายขั้นตอน	เขียน tap ด้วย MCP server
Process อายุยาว (connection pool, browser session, websocket)	External `stdio`/`http` MCP server

Mental model: ถ้าเนื้อหาของ MCP server ของคุณคือ "parse param, spawn binary นี้, return stdout" คุณไม่ต้องการ server — คุณต้องการ shell script 15 บรรทัด

Validation Loop

รันสิ่งนี้หลังเขียนหรือเปลี่ยน tool ใดๆ:

echo "/mcp" | octomind run

มัน boot session ใน directory ปัจจุบัน list ทุก MCP server ใน scope และออก คุณจะเห็น:

local: ✅ Running
  Type: LocalTools
  Configured tools: deploy, test, api, flags, release

ถ้า tool หาย:

อาการ	สาเหตุ	แก้
ไม่อยู่ใน `/mcp` output	ไม่ executable	`chmod +x .agents/tools/<name>`
ไม่อยู่ใน `/mcp` output	ขาด `@description`	เพิ่มบรรทัด
ไม่อยู่ใน `/mcp` output	ชื่อไฟล์มี `.`	ตัด extension (`deploy`, ไม่ใช่ `deploy.sh`)
Tool error เมื่อถูกเรียก	param-reading ไม่ตรง	ยืนยันว่าคุณอ่าน `OCTOMIND_PARAM_*` หรือ stdin ไม่ใช่ `$1`

สำหรับ debug ที่ลึกกว่า: OCTOMIND_LOG=debug echo "/mcp" | octomind run แสดงว่าทำไมไฟล์ candidate แต่ละตัวถูกรับหรือข้าม

runtime ถือว่า .agents/tools/ เป็น hot-reload — แก้, save, call tool ครั้งถัดไปใช้ version ใหม่ ไม่มี octomind restart ไม่มี daemon เขียน save เรียก

เริ่มต้น

ถ้าคุณไม่มี octomind:

# macOS
brew install muvon/tap/octomind

# Any platform
cargo install octomind

จากนั้นใน repo ใดก็ได้:

mkdir -p .agents/tools
cat > .agents/tools/branch <<'EOF'
#!/usr/bin/env bash
# @description Print the current branch name.
git -C "$OCTOMIND_WORKDIR" rev-parse --abbrev-ref HEAD
EOF
chmod +x .agents/tools/branch

echo "/mcp" | octomind run

คุณควรเห็น local listed พร้อม branch Commit มัน:

git add .agents/tools/branch
git commit -m "agent: add branch-name tool for AI sessions"

นั่นคือ pattern ทั้งหมด ทุก dev ที่ pull repo มี tool ทุก agent run ใน directory เห็นมัน ไม่ต้อง setup เพิ่มที่ไหนบนเครื่องของใคร

FAQ

ทำไม wrapped tool ถึงลด drift ถ้า command ข้างใต้เหมือนกัน?

เพราะ model ไม่ได้เลือกระหว่าง shell invocation หลายพันแบบที่ดูสมเหตุสมผลเท่ากันอีกต่อไป มันเลือกระหว่าง named, typed tool ไม่กี่ตัวพร้อม description ที่เขียนเพื่อมัน RAG-MCP วัดผล: tool-selection accuracy ลดลงเมื่อ catalog โต ชุดเล็กที่มีชื่อพร้อม description ชัดเจนคือรูปทรงที่ถูกต้องเชิงประจักษ์สำหรับ tool-using LLM

นี่เป็นเรื่องของ Octomind เท่านั้นหรือ?

การค้นพบ .agents/tools/ เป็น feature ของ Octomind runtime ภายใน Octomind ทุก model — Claude, Kimi, GLM, GPT, local model — เห็นพวกมันเป็น MCP tool มาตรฐาน ถ้าคุณใช้ Claude Desktop หรือ Cursor ด้วย คุณสามารถ wrap .agents/tools/ ด้วย MCP shim บาง แต่ leverage สูงสุดอยู่ใน Octomind ที่ discovery เป็นอัตโนมัติและ scope ระดับโปรเจกต์

Secret ล่ะ?

Tool อยู่ใน repo Secret ไม่อยู่ Script อ่าน ACME_TOKEN (หรือคล้ายกัน) จาก environment ของนักพัฒนา — direnv, .envrc, shell rc Commit tool ไม่ใช่ credential ถ้า env var หาย exit ไม่ใช่ศูนย์พร้อมข้อความชัดเจนเพื่อให้ model surface error จริงแทนการแต่งเอง

agent รัน tool พวกนี้ได้โดยไม่ต้องอนุมัติทุก call หรือเปล่า?

ได้ — permission flow เดียวกันกับ MCP tool ใดๆ Auto-approve tool ที่ read-only (branch, flags) ถามเสมอสำหรับตัวทำลาย (deploy, release) Octomind ถือว่า local tool เป็น first-class สำหรับระบบ permission

ถ้าฉันต้องการ tool เดียวกันข้าม repo หลายๆ ตัว?

สองตัวเลือก เบา: symlink .agents/tools/foo ไปยังที่ตั้งที่แชร์กัน ทางการ: เขียน tap — registry แบบ Homebrew Local tool สำหรับ repo นี้โดยเฉพาะ Tap สำหรับ การใช้ซ้ำข้ามโปรเจกต์

มันทำงานใน CI / non-interactive run ไหม?

ใช่ octomind run --format=plain และ --format=jsonl ทั้งคู่ honor .agents/tools/ เรารัน agent-driven code review ใน CI ของเราเองแบบนี้ — tool lint, test, และ coverage ของ review agent ทั้งหมดอยู่ใน .agents/tools/ และ wrap command ที่แน่นอนของทีม

ชื่อ tool ชนกับ built-in จะเกิดอะไรขึ้น?

Built-in ชนะ คุณ shadow shell หรือ view ด้วยการตั้งชื่อสคริปต์ว่า shell ไม่ได้ — octomind log การชนและเก็บตัวเดิม guardrail ที่ตั้งใจ

การเปลี่ยนแปลง

มีเรื่องเล่าที่กำลังเล่าตอนนี้ว่าอนาคตของ agent คือ MCP server เพิ่มขึ้น — catalog ใหญ่ขึ้น ecosystem รวยขึ้น integration มากขึ้น ข้อมูลจาก RAG-MCP, Bloomberry audit, โพสต์ code-execution ของ Anthropic เอง และนักพัฒนาที่กลับไปใช้ CLI เงียบๆ ทั้งหมดชี้ทิศทางที่ต่าง: agent ที่ทำงานได้ดีที่สุดใน repo จริงเห็น tool น้อยลง tool แคบลง และ tool ที่เขียนสำหรับโปรเจกต์ที่พวกมันอยู่

สคริปต์ .agents/tools/ คือ unit ที่เล็กที่สุดเท่าที่เป็นไปได้ของ pattern นั้น หกสิบวินาทีจาก "ฉันเฝ้าดู agent drift ในเรื่องนี้ตลอด" เป็น "agent มี tool สำหรับมัน ทีมมี อยู่ใน git เราเดินต่อ"

ลองใช้กับสิ่งถัดไปที่คุณพบว่าตัวเองอธิบายซ้ำสองครั้ง

— Don

Octomind เป็น open source ภายใต้ Apache-2.0 feature local-tool ship ใน 0.29.0 ถ้าสิ่งใดในนี้ปลดบล็อค workflow เปิด issue — feature ที่ถูกขอในเดือน May มักจะ ship ในเดือน June

ปัญหา Drift ที่มีตัวเลขสนับสนุน

ทำไม "แค่เขียน MCP server" ถึง scale ไม่ได้

MCP tool คืออะไรจริงๆ

Pattern: .agents/tools/<name>

กายวิภาคของ Header

Drift จริงสี่อย่าง tool จริงสี่ตัว

1. Drift: "มันรัน npm test ใน pnpm monorepo"

2. Drift: "มัน hallucinate URL ของ staging"

3. Drift: "มันอธิบาย feature flag service ซ้ำเป็นครั้งที่สี่"

4. Drift: "มันใช้ git tag แทน release script ของเรา"

Compounding Effect: มันอยู่ใน Repo

เมื่อไหร่ควรหันไปใช้ MCP Server แทน

Validation Loop

เริ่มต้น

FAQ

การเปลี่ยนแปลง

บทความที่เกี่ยวข้อง

Timex 1.1.0: ส่งออก Database เป็น ZIP และแปลภาษาห้าภาษา

รอบการปล่อย พฤษภาคม 2026: Octofs 0.4.3, Octobrain 0.6.1, Octolib 0.21.5, Octomind 0.29.0

Timex 1.0.0: ติดตามเวลาอัตโนมัติสำหรับ Mac — สร้างเพื่อคนที่เกลียด time tracker

Pattern: `.agents/tools/<name>`

1. Drift: "มันรัน `npm test` ใน `pnpm` monorepo"

4. Drift: "มันใช้ `git tag` แทน release script ของเรา"