# Custom MCPs आपके repo में होने चाहिए: Agent Drift का इलाज जो 60 सेकंड लेता है > AI agents drift करते हैं — वे shell commands गढ़ते हैं, URLs hallucinate करते हैं, internal CLIs पर अनुमान लगाते हैं। मानक समाधान है "custom MCP server लिखो," पर ज़्यादातर projects को server नहीं चाहिए। Octomind 0.29.0 आपको `.agents/tools/` में एक shebang script ड्रॉप करने देता है, git में commit करता है, और 50-लाइन के shell wrapper को project-scoped MCP में बदल देता है जिसे हर developer का agent हर turn पर इस्तेमाल करता है। October 2025 में, एक ही GitHub commit ने एक लोकप्रिय agents repository में 47 LLM-generated "skills" ड्रॉप कर दीं। इनमें से एक ने Claude को `npx react-codeshift` चलाना सिखाया। वह package मौजूद नहीं था। वह कभी मौजूद नहीं था। Claude ने उसे training के दौरान hallucinate किया था, author ने चेक नहीं किया, और कुछ हफ़्तों में [वह file 237 forks तक फैल गई](https://www.aikido.dev/blog/agent-skills-spreading-hallucinated-npx-commands)। असली developers ने असली terminals में वह command चलाई। `npm` ने हज़ारों बार खुशी-खुशी एक phantom package को resolve करने की कोशिश की। यह AI-agent कहानी का वह हिस्सा है जो keynote में नहीं आता। **Agents drift करते हैं।** एक shell और एक धुंधला task दे दीजिए, और वे सबसे प्लॉज़िबल-साउंडिंग command की ओर बढ़ेंगे, भले ही वह मौजूद न हो — और जितना general tool आप उन्हें देंगे, उतना ही ज़्यादा वे drift करेंगे। 2026 में मानक उत्तर है: _एक custom MCP server लिखो।_ वे actions define करो जो आप चाहते हैं कि agent ले, उन्हें सख्त schemas दो, उन्हें एक अलग binary के रूप में ship करो, उन्हें agent की config में register करो। `bash` के बजाय specific tools देकर model को constrain करो। मानक उत्तर सिद्धांत में सही है और व्यवहार में गलत। एक असली MCP server लिखना — JSON-RPC framing, stdio handshake, schema definitions, अलग dependency tree — एक shell command के लिए, यह engineering theater है। ज़्यादातर teams हार मान लेती हैं और drift के साथ जीती हैं। [Octomind 0.29.0](/blog/release-round-may-2026) यह gap बंद करता है। **एक custom MCP एक project नहीं होना चाहिए। यह आपके repo में एक file होनी चाहिए।** --- ## Drift समस्या, संख्याओं द्वारा समर्थित अगर आपने थोड़ी देर एक agent को चलते देखा है, तो आपने drift देखी है: - वह `pnpm` monorepo में `npm test` चलाता है। - वह आपके असली, auth-gated `https://api-staging.acme.internal/v3` के बजाय `https://staging.example.com/api` को curl करता है। - वह एक ऐसा package install करने की कोशिश करता है जिसका नाम लगभग — पर बिलकुल नहीं — सही है। - वह आपकी team के release script के बजाय raw `git tag` का इस्तेमाल करता है। May 2025 का paper _[RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection](https://arxiv.org/abs/2505.03275)_ (Gan & Sun) ने एक MCP stress test चलाया और पाया कि baseline tool-selection accuracy scale पर **13.62%** तक गिर गई — model अब reliably सही tool नहीं चुन सकता था क्योंकि हर tool description जिस पर उसे विचार करना था, prompt को भीड़भाड़ देती थी और attention को diluted करती थी। उनका retrieval-आधारित fix इसे तीन गुना से ज़्यादा बढ़ाकर 43.13% कर देता है जबकि prompt tokens को 50% से अधिक काट देता है। फिर भी accuracy खराब है, पर curve की दिशा ही मुख्य बात है: जितने tools आप ठूँसते हैं, model उतना ही उनमें से चुनने में खराब होता जाता है। Anthropic, जिसने MCP protocol _लिखा_, ने [4 November 2025 को वही बात स्वीकारी](https://www.anthropic.com/engineering/code-execution-with-mcp): > "In cases where agents are connected to thousands of tools, they'll need to process hundreds of thousands of tokens before reading a request." उनके अपने benchmarks ने दिखाया कि एक Drive → Salesforce flow naive MCP loading के तहत **150,000 tokens** लेता है। Code-execution और on-demand tool discovery के साथ, वही flow **2,000 tokens** में चला — 98.7% की कटौती। उनका follow-up [Tool Search Tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool) (API version `20251119`) tool definitions को तब तक defer करता है जब तक उनकी ज़रूरत न पड़े; documentation बताती है कि यह आमतौर पर context bloat को **85% से अधिक** काट देता है और note करती है कि "Claude's ability to correctly pick the right tool degrades significantly once you exceed 30–50 available tools." सबक जिस पर सब converge कर रहे हैं: **कम, संकीर्ण, project-relevant tools हर बार एक विशाल catalog को हराते हैं।** Model बेहतर perform करता है। Token bill गिरता है। Drift उसके साथ गिरती है। तो सही सवाल नहीं है "मैं और MCPs कैसे लिखूँ?" यह है "जिन्हें मुझे वास्तव में चाहिए, उन्हें लिखने और ship करने में कुछ खर्च न हो — यह कैसे करूँ?" --- ## "बस एक MCP Server लिखो" Scale क्यों नहीं करता February 2026 का [Bloomberry analysis of 1,412 MCP servers](https://bloomberry.com/blog/we-analyzed-1400-mcp-servers-heres-what-we-learned/) ने पाया कि **उनमें से 38.7% बिना किसी authentication के ship करते हैं**, median server केवल five tools expose करता है, और जो companies उन्हें publish कर रही हैं उनमें से लगभग आधी के पास पहले स्थान पर एक public API ही नहीं है। Bloomberry की framing: "MCP might not be a wrapper on an existing API. It might be the first machine-readable interface they've ever shipped." (MCP एक मौजूदा API पर wrapper नहीं हो सकता। यह उनके द्वारा कभी ship किया गया पहला machine-readable interface हो सकता है।) इस विस्फोट का अधिकांश हिस्सा वे लोग ship कर रहे हैं जो production में इसे figure out कर रहे हैं। समस्या यह नहीं है कि protocol टूटा है। यह है कि **unit of work गलत है** project-specific actions के लिए। एक Python या Node MCP server लिखना stdio framing, schema registration, और एक अलग deployment pipeline के साथ "GitHub API" या "Postgres database" के लिए सही shape है। यह "run our staging deploy script" के लिए गलत shape है — कोड का एक टुकड़ा जो चालीस लाइन bash है, पहले से `bin/deploy` में है, जिसे आप चाहते हैं कि agent अनुमान लगाने के बजाय नाम से call करे। Practitioners इसी निष्कर्ष पर पहुँच रहे हैं। Hacker News thread "MCP explained without hype or fluff" ([item 44063141](https://news.ycombinator.com/item?id=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." दोनों comments वे जिन cases का वर्णन करते हैं उनके बारे में सही हैं। CLIs काम करते हैं। `bin/` में local scripts काम करते हैं। एक one-line shell command को 200-line MCP server में लपेटना क्योंकि वही एकमात्र blessed pattern है — यही टूटा है। --- ## एक MCP Tool वास्तव में क्या है Protocol को हटा दीजिए और एक MCP tool तीन चीज़ें हैं: 1. **एक नाम और description** ताकि model को पता हो कि इसे कब उठाना है। 2. **एक parameter schema** ताकि model को पता हो कि क्या pass करना है। 3. **एक executable** जो काम करता है। बाकी सब — JSON-RPC framing, stdio handshake, capability negotiation — _runtime_ concern है, author concern नहीं। 2023 का paper _[Tool Documentation Enables Zero-Shot Tool-Usage with Large Language Models](https://arxiv.org/abs/2308.00675)_ (Hsieh et al.) ने empirically दिखाया कि अपरिचित tools के लिए, **clear documentation few-shot demonstrations को हराती है** — और "zero-shot prompts with only tool documentation" out-of-distribution tasks पर few-shot prompts से match कर सकते हैं। निहितार्थ: tool पर एक छोटा, सटीक description एक complex schema या examples के ढेर से ज़्यादा मूल्यवान है। अगर tool _छोटा_ है और docs _छोटे_ हैं, तो पूरा interface उस script पर कुछ header comments की लाइनों के रूप में expressible होना चाहिए जो काम करती है। यही Octomind 0.29.0 करता है। --- ## Pattern: `.agents/tools/` यहाँ पूरा contract है: ```bash 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 ``` तीन बातें अभी हुईं: 1. अगली बार जब session चलेगा तो Octomind ने script को discover किया। 2. इसने `@description` और `@param` लाइनों को एक JSON-Schema tool definition में parse किया। 3. Model अब एक `deploy` tool देखता है — इस repo के लिए scoped — `env` (required) और `dry_run` (optional) के साथ। यह `bash("./bin/deploy --env staging")` के बजाय `deploy(env="staging")` को pick करेगा क्योंकि named tool का signal-to-noise ratio ज़्यादा साफ़ है। वह preference वही guardrail है जो आप चाहते हैं। Model अब "deploy" से "kubectl apply" से "helm install" तक free-associate नहीं कर रहा है। उसके पास एक entry point है, एक typed parameter के साथ, जो team का असली deploy करता है। Wiring verify करने के लिए, validation one-liner चलाएँ: ```bash echo "/mcp" | octomind run ``` आपको output में एक `local` MCP server दिखेगा जिसके नीचे `deploy` listed होगा। अगर script नहीं दिखती, तो runtime आपको बिल्कुल बताता है क्यों — गलत permissions, गायब `@description`, filename में dot। --- ## Header का Anatomy Leading comment block ही पूरा interface है। Octomind इसे हर turn पर फिर से पढ़ता है (cheap — एक `read_dir`) और schema को rebuild करता है। Edit करें और save करें, अगला tool call नया version इस्तेमाल करता है। कोई daemon restart नहीं। ```bash #!/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"] ``` Comment prefix `#` (bash, python, ruby, lua, perl, awk), `//` (node, deno), या `--` (lua, SQL wrappers) हो सकता है। Runtime को परवाह नहीं है कि कौन सी language काम करती है। जब model tool को call करता है, octomind आपको parameters दो तरीकों से देता है: | Channel | Form | | --------- | ------------------------------------------------------------------------------------------------------------ | | **stdin** | One JSON object then EOF: `{"target":"src/x","force":true}` | | **env** | `OCTOMIND_PARAM_TARGET=src/x`, `OCTOMIND_PARAM_FORCE=true`, plus `OCTOMIND_WORKDIR` and `OCTOMIND_TOOL_NAME` | Bash scripts आमतौर पर env vars पढ़ते हैं। Python scripts आमतौर पर stdin JSON parse करते हैं। दोनों हर call पर आते हैं। Stdout वह result बन जाता है जो model देखता है। Stderr को `[stderr]` marker के साथ append किया जाता है। Non-zero exit → tool error। बस यही पूरी सतह है। --- ## चार असली Drifts, चार असली Tools हमने wrapper लिखने से पहले अपने repos में इनमें से हर एक पर agent को fail होते देखा है। Wrapper ने failure रोकी। ### 1. The Drift: "वह `pnpm` monorepo में `npm test` चलाता है" Agent root पर एक `package.json` देखता है, `npm test` type करता है, "no script found" errors की एक दीवार पाता है, और project को टूटा हुआ report करता है। The wrapper — `.agents/tools/test`: ```bash #!/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 अपनी tool list में `test(scope, package)` देखता है। Description उसे defaults बताती है। यह `test()` call करता है और पहली ही try में असली result पाता है। Team में कोई फिर कभी chat window में "use `pnpm -r test:unit`" type नहीं करता। ### 2. The Drift: "इसने staging URL को hallucinate कर दिया" Agent को आपके असली staging API से `https://api-staging.acme.internal/v3/users/42` पर एक record पढ़ना है, जिसके लिए एक `X-Acme-Token` header चाहिए। यह इसके बजाय `https://staging.example.com/api/users/42` को curl करता है — एक URL जो उसने training data से गढ़ा — कुछ नहीं मिलता, और service को down report करता है। The wrapper — `.agents/tools/api`: ```bash #!/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")` call करता है और असली URL script में रहता है। Token developer के environment से आता है (`.envrc`, `direnv`, आपका shell rc) — _tool_ commit होता है, _secret_ नहीं। ### 3. The Drift: "उसने feature flag service चौथी बार फिर से समझाई" Agent एक UI issue debug कर रहा है। आप उसे (फिर से) याद दिलाते हैं कि feature-flag service मौजूद है, कि flags हर environment के लिए अलग हैं, और staging प्रासंगिक है। यह सिर हिलाता है, भूल जाता है, अगले session में फिर पूछता है। The wrapper — `.agents/tools/flags`: ```python #!/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 खोलता है, अपनी tool list में `flags` देखता है, और जब चाहिए तब खुद उसे call करता है। आप "staging में क्या on है" के लिए human cache होना बंद कर देते हैं। ### 4. The Drift: "इसने हमारे release script के बजाय `git tag` का इस्तेमाल किया" आपकी team ने `acme-cli` बनाया ताकि version bumps, changelogs, और tag-then-push सही क्रम में हों। Agent इसे skip कर देता है, raw `git tag v1.2.3` चलाता है, convention तोड़ता है, और अब अगला CI run changelog नहीं ढूँढ सकता। The wrapper — `.agents/tools/release`: ```bash #!/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[@]}" ``` यह वही है जो teammates को राज़ी करता है। Agent अब अपनी ओर से आपकी team की release convention follow करता है — version, changelog, tag, push — क्योंकि tool _repo में मौजूद है_ और model इसे raw `git` के ऊपर pick करता है। --- ## Compounding Effect: यह Repo में रहता है Anthropic की MCP code-execution post का तर्क है कि future dynamic discovery है: ज़रूरत पड़ने पर tools load करो, बाकी समय छोड़ दो। Shebang pattern उस idea का local-first version है। तीन properties एक साथ stack होती हैं: **1. Narrow surface, कम drift.** Model एक generic shell के बजाय एक one-line description के साथ _named, parameterized_ action देखता है। Hsieh et al. ने पाया कि description ही tool selection के लिए अधिकांश काम करती है — examples nice-to-have हैं। Shebang header उसी के लिए सटीक सही shape है: नाम, description, typed params, सब एक comment block में जो tool author कोड के साथ-साथ पहले से maintain करता है। **2. पूरी team को मुफ्त में मिलता है।** एक traditional MCP server एक developer के laptop पर रहता है। जब एक teammate repo clone करता है, server वहाँ नहीं होता, agent tool नहीं देखता, और drift वापस आ जाता है। एक `.agents/tools/` script git में commit होती है। Clone, `octomind run`, सबको वही tools मिलते हैं। **3. Tools कोड के साथ विकसित होते हैं।** एक service rename की? उसी PR में wrapper update कीजिए। एक feature flag जोड़ा? उसी PR में wrapper update कीजिए। आपका AI tooling किसी भी अन्य चीज़ की तरह code review के अधीन है। _Agent को क्या लगता है कि repo कैसा दिखता है_ और _repo वास्तव में कैसा दिखता है_ के बीच का drift — agent reliability का slow-burn killer — अपने आप बंद हो जाता है। इसके एक हफ़्ते बाद, हर developer के terminal में agent एक ही behavior पर converge करता है क्योंकि सब एक ही repo से एक ही tools चलाते हैं। Institutional knowledge "जो मैंने chat में agent को बताया" होना बंद हो जाता है और एक versioned, reviewable artifact बन जाता है। --- ## इसके बजाय MCP Server कब Reach करें Local tools project-specific 90% कवर करते हैं। वे सब कुछ कवर नहीं करते। इस matrix का इस्तेमाल कीजिए: | आप चाहते हैं… | Use | | ------------------------------------------------------------------------------- | ------------------------------------------- | | Project-specific _action_ (deploy, test, query flags, hit an internal endpoint) | **`.agents/tools/` shebang** | | Domain _instructions_ को context में inject करें | [Skills](https://github.com/Muvon/octomind) | | Reusable cross-project tool with rich schema and multi-step logic | Author a tap with an MCP server | | Long-lived process (connection pool, browser session, websocket) | External `stdio`/`http` MCP server | Mental model: _अगर आपके MCP server का body "parse params, spawn this binary, return stdout" है, तो आपको server नहीं चाहिए — आपको एक 15-line shell script चाहिए।_ --- ## Validation Loop कोई भी tool लिखने या बदलने के बाद यह चलाएँ: ```bash echo "/mcp" | octomind run ``` यह current directory में एक session boot करता है, scope में हर MCP server list करता है, और exit करता है। आप देखेंगे: ``` local: ✅ Running Type: LocalTools Configured tools: deploy, test, api, flags, release ``` अगर एक tool गायब है: | Symptom | Cause | Fix | | ----------------------- | ---------------------- | ------------------------------------------------------ | | Not in `/mcp` output | Not executable | `chmod +x .agents/tools/` | | Not in `/mcp` output | Missing `@description` | Add the line | | Not in `/mcp` output | Filename has `.` | Drop the extension (`deploy`, not `deploy.sh`) | | Tool errors when called | Param-reading mismatch | Confirm you read `OCTOMIND_PARAM_*` or stdin, not `$1` | गहरी debugging के लिए: `OCTOMIND_LOG=debug echo "/mcp" | octomind run` दिखाता है कि क्यों हर candidate file को accept या skip किया गया। Runtime `.agents/tools/` को hot-reloaded मानता है — edit, save, अगला tool call नया version इस्तेमाल करता है। कोई `octomind restart` नहीं, कोई daemon नहीं। Write, save, call। --- ## शुरुआत करना अगर आपके पास octomind नहीं है: ```bash # macOS brew install muvon/tap/octomind # Any platform cargo install octomind ``` फिर किसी भी repo में: ```bash 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 ``` आपको `branch` के साथ `local` listed दिखना चाहिए। उसे commit करें: ```bash git add .agents/tools/branch git commit -m "agent: add branch-name tool for AI sessions" ``` बस यही पूरा pattern है। हर dev जो repo pull करता है, उसके पास tool होता है। Directory में हर agent run इसे देखता है। किसी की machine पर कोई और setup नहीं। --- ## FAQ **अगर underlying command वही है तो wrapped tool drift क्यों कम करता है?** क्योंकि model अब हज़ारों समान रूप से प्लॉज़िबल shell invocations के बीच नहीं चुन रहा है। यह उसके लिए लिखे गए descriptions वाले मुट्ठी भर named, typed tools के बीच चुन रहा है। [RAG-MCP](https://arxiv.org/abs/2505.03275) ने प्रभाव को measure किया: catalog बढ़ने के साथ tool-selection accuracy गिरती है। clear descriptions के साथ एक छोटा, named set tool-using LLMs के लिए _empirically correct_ shape है। **क्या यह Octomind-specific है?** `.agents/tools/` discovery एक Octomind runtime feature है। Octomind के अंदर, हर model — Claude, Kimi, GLM, GPT, local models — इन्हें standard MCP tools के रूप में देखता है। अगर आप Claude Desktop या Cursor भी इस्तेमाल करते हैं, तो आप `.agents/tools/` को एक पतले MCP shim के साथ wrap कर सकते हैं, पर सबसे ज़्यादा leverage Octomind के अंदर है जहाँ discovery automatic और project-scoped है। **Secrets के बारे में क्या?** Tool repo में है। Secret नहीं है। Scripts developer के environment से `ACME_TOKEN` (या समान) पढ़ते हैं — `direnv`, `.envrc`, shell rc। Tool commit करें, credential नहीं। अगर env var गायब है, एक स्पष्ट message के साथ non-zero exit करें ताकि model एक गढ़ी हुई error के बजाय असली error surface करे। **क्या agent मेरे हर call को approve किए बिना इनमें से कोई भी tool चला सकता है?** हाँ — किसी भी MCP tool जैसा ही permission flow। Read-only tools (`branch`, `flags`) को auto-approve करें। Destructive वाले (`deploy`, `release`) के लिए हमेशा पूछें। Octomind permission system के लिए local tools को first-class मानता है। **अगर मुझे multiple repos में एक ही tool चाहिए तो?** दो options। Lightweight: `.agents/tools/foo` को shared location पर symlink करें। Proper: एक [tap](https://github.com/Muvon/octomind) author करें — एक Homebrew-style registry। Local tools _इस specific repo के लिए_ हैं। Taps _cross-project reusability_ के लिए हैं। **क्या यह CI / non-interactive runs में काम करता है?** हाँ। `octomind run --format=plain` और `--format=jsonl` दोनों `.agents/tools/` को honor करते हैं। हम अपने ही CI में इसी तरह agent-driven code review चलाते हैं — review agent के `lint`, `test`, और `coverage` tools सब `.agents/tools/` में रहते हैं और team की exact commands को wrap करते हैं। **एक tool नाम built-in से collide करता है। क्या होता है?** Built-in जीतता है। आप `shell` या `view` को script का नाम `shell` रखकर shadow नहीं कर सकते — octomind collision log करता है और original रखता है। Deliberate guardrail। --- ## The Shift अभी एक कहानी सुनाई जा रही है कि agents का future _अधिक MCP servers_ है — बड़े catalogs, समृद्ध ecosystems, अधिक integrations। RAG-MCP का data, Bloomberry audit, Anthropic की अपनी [code-execution post](https://www.anthropic.com/engineering/code-execution-with-mcp), और CLIs पर चुपचाप वापस जाते developers — सब एक अलग दिशा की ओर इशारा करते हैं: **जो agents असली repos में सबसे अच्छा perform करते हैं वे कम tools, संकीर्ण tools, और उस project के लिए लिखे गए tools देखते हैं जिसमें वे हैं।** एक `.agents/tools/` script उस pattern की सबसे छोटी संभव unit है। साठ सेकंड "मैं इस पर agent को drift करते देख रहा हूँ" से "agent के पास इसके लिए tool है, team के पास है, यह git में है, हम आगे बढ़ते हैं" तक। अगली बार जब आप खुद को कुछ दो बार समझाते हुए पाएँ, इसे try करें। — Don --- _[Octomind](https://github.com/Muvon/octomind) Apache-2.0 के तहत open source है। Local-tool feature [0.29.0](/blog/release-round-may-2026) में ship हुआ। अगर यहाँ कुछ workflow unblock करता है, [issue खोलें](https://github.com/Muvon/octomind/issues) — May में request किए गए features June में ship हो जाते हैं।_