Tool Design & MCP Integration

The model chooses tools mainly by reading their descriptions. If two tools have thin, similar descriptions, the model can't tell them apart and misroutes. Rich descriptions are the highest-leverage, lowest-effort fix for selection problems.

ماڈل ٹول زیادہ تر ان کی description پڑھ کر چنتا ہے۔ اگر دو ٹولز کی description پتلی اور ملتی جلتی ہو تو ماڈل فرق نہیں کر پاتا اور غلط چن لیتا ہے۔ بہتر description چناؤ کے مسائل کا سب سے فائدہ مند اور آسان حل ہے۔

// weak — model can't disambiguate:
get_customer: 'Retrieves customer information'
lookup_order: 'Retrieves order details'

// strong — inputs, examples, boundaries:
lookup_order: 'Fetch a single order by order ID (e.g. #12345).
  Use for questions about a specific order status/contents.
  Do NOT use to look up a person — use get_customer for that.'

Spell out what inputs the tool accepts, show example calls, note tricky cases, and state when to use a DIFFERENT tool instead. Boundaries ('use X not Y when…') are what actually stop misrouting.

بتائیں ٹول کون سے ان پٹ لیتا ہے، مثال کی کالیں دکھائیں، مشکل صورتیں لکھیں، اور یہ بھی کہ کب کوئی دوسرا ٹول استعمال کرنا ہے۔ حدود ('فلاں حالت میں X استعمال کرو، Y نہیں') ہی اصل میں غلط چناؤ روکتی ہیں۔

Near-identical names and descriptions create genuine ambiguity. The cure is to differentiate purpose and inputs — or rename/split the tools (see skills below).

تقریباً ایک جیسے نام اور description سچی الجھن پیدا کرتے ہیں۔ علاج یہ ہے کہ مقصد اور ان پٹ الگ کریں — یا ٹولز کا نام بدلیں/انہیں بانٹیں (نیچے skills دیکھیں)۔

A phrase in the system prompt like 'analyze the content' can bias the model toward a tool named analyze_content even when another tool is correct. Review system prompts for keywords that accidentally override good tool descriptions.

سسٹم پرامپٹ میں 'analyze the content' جیسا جملہ ماڈل کو analyze_content نامی ٹول کی طرف جھکا سکتا ہے، چاہے کوئی اور ٹول درست ہو۔ سسٹم پرامپٹ کو ایسے لفظوں کے لیے دیکھیں جو غلطی سے اچھی ٹول description کو دبا دیں۔

A good description does four jobs: states the tool's purpose, names its exact inputs, says what it returns, and draws a boundary against its nearest neighbor ('use X not Y when…'). The boundary line is what actually stops misrouting between similar tools.

اچھی description چار کام کرتی ہے: ٹول کا مقصد بتاتی ہے، اس کے عین ان پٹ بتاتی ہے، بتاتی ہے کیا لوٹاتا ہے، اور اپنے قریبی ٹول کے ساتھ حد کھینچتی ہے ('فلاں حالت میں X، Y نہیں')۔ یہی حد ملتے جلتے ٹولز کے درمیان غلط چناؤ روکتی ہے۔

lookup_order: 'Fetch ONE order by numeric order ID (e.g. #12345).
  Returns status, items, totals. Use for questions about a specific order.
  NOT for finding a person or their orders -> use get_customer.'

When two tools overlap, a targeted rename plus a scoped description eliminates the ambiguity at its root.

جب دو ٹول آپس میں اوورلیپ کریں، تو سوچ سمجھ کر نام بدلنا اور محدود description جڑ سے الجھن ختم کر دیتی ہے۔

// before - overlapping:
analyze_content:  'Analyzes content'
analyze_document: 'Analyzes documents'
// after - rename + scope one to its real job:
extract_web_results: 'Parse search-engine result pages into {title,url,snippet}.
  Web SERPs only; NOT for local files -> use read_document.'

A vague analyze_document becomes extract_data_points, summarize_content, and verify_claim_against_source — each with a clear contract the model can select confidently.

مبہم analyze_document بن جاتا ہے extract_data_points، summarize_content، اور verify_claim_against_source — ہر ایک کا صاف کام جسے ماڈل یقین سے چن سکے۔

// vague: what does it even return?
analyze_document(doc) -> ???
// split into selectable contracts:
extract_data_points(doc)            -> [{ field, value }]
summarize_content(doc)              -> string
verify_claim_against_source(claim, doc) -> { supported: bool, excerpt }

A phrase like 'analyze the content' in the system prompt can pull the model toward a tool named analyze_content even when another tool is correct. Scan prompts for words that echo tool names and accidentally bias selection.

سسٹم پرامپٹ میں 'analyze the content' جیسا جملہ ماڈل کو analyze_content نامی ٹول کی طرف کھینچ سکتا ہے، چاہے کوئی اور ٹول درست ہو۔ پرامپٹ کو ایسے لفظوں کے لیے دیکھیں جو ٹول کے ناموں سے ملتے اور غلطی سے چناؤ کو جھکا دیں۔

System prompt: "First, analyze the content the user provides."
Tool present:  analyze_content(...)
// the echoed phrase biases selection toward analyze_content
// fix: reword -> "First, review the user's request"  (no tool-name echo)

MCP tools signal failure by setting isError on the result. This tells the agent 'this was an error, not data' so it can decide how to react instead of treating a failure message as a valid answer.

MCP ٹول نتیجے پر isError لگا کر ناکامی بتاتے ہیں۔ یہ ایجنٹ کو کہتا ہے 'یہ خرابی تھی، ڈیٹا نہیں' تاکہ وہ ناکامی کے پیغام کو درست جواب سمجھنے کے بجائے ردعمل طے کر سکے۔

Different failures need different responses. A transient timeout may be retried; a validation error needs corrected input; a business-rule violation should be explained to the user and NOT retried; a permission error needs different credentials/escalation.

مختلف ناکامیوں کے مختلف ردعمل چاہییں۔ وقتی timeout دوبارہ کوشش سے حل ہو سکتا ہے؛ جانچ کی خرابی درست ان پٹ مانگتی ہے؛ کاروباری اصول کی خلاف ورزی صارف کو سمجھائی جائے، دوبارہ نہ کی جائے؛ اجازت کی خرابی الگ اسناد/آگے بھیجنا مانگتی ہے۔

'Operation failed' tells the agent nothing about WHAT failed or whether to retry. It leads to blind retries or giving up. Structured metadata restores intelligent recovery.

'Operation failed' ایجنٹ کو یہ نہیں بتاتا کہ کیا ناکام ہوا یا دوبارہ کوشش کرنی ہے۔ اس سے یا تو اندھی دوبارہ کوششیں ہوتی ہیں یا ہار مان لی جاتی ہے۔ صاف تفصیل سمجھدار سنبھلاؤ واپس لاتی ہے۔

An explicit isRetryable flag stops the agent from hammering a permanently-failing call and lets it retry only when retrying can actually succeed.

ایک صاف isRetryable نشان ایجنٹ کو ہمیشہ ناکام رہنے والی کال بار بار مارنے سے روکتا ہے اور صرف تب دوبارہ کوشش کرنے دیتا ہے جب کوشش واقعی کامیاب ہو سکے۔

Give the agent the metadata it needs to react: a category to branch on, an explicit retry flag so it doesn't guess, and a message a human can understand. This turns 'Operation failed' into an actionable, recoverable signal.

ایجنٹ کو ردعمل کے لیے درکار تفصیل دیں: فیصلہ کرنے کے لیے قسم، اندازہ روکنے کے لیے صاف retry نشان، اور ایسا پیغام جو انسان سمجھ سکے۔ اس سے 'Operation failed' ایک قابلِ عمل، سنبھلنے والا اشارہ بن جاتا ہے۔

{ "isError": true,
  "errorCategory": "business",
  "isRetryable": false,
  "message": "Refund exceeds the $500 self-service limit; needs manager approval." }

Business-rule failures should never be retried — the answer won't change. Mark them non-retryable and attach an explanation the agent can relay verbatim to the user, so it explains the policy instead of silently looping.

کاروباری اصول کی ناکامیاں کبھی دوبارہ نہ کریں — جواب نہیں بدلے گا۔ انہیں 'دوبارہ نہ کرنے والا' نشان زد کریں اور ساتھ وضاحت دیں جو ایجنٹ صارف کو من و عن سنا دے، تاکہ وہ خاموشی سے چکر کاٹنے کے بجائے اصول سمجھا دے۔

{ "isError": true,
  "errorCategory": "business",
  "isRetryable": false,       // the answer won't change on retry
  "message": "Coupon SAVE20 expired on 2026-06-30 and can't be applied." }
// agent relays the message to the customer; it does NOT loop

Let a subagent retry its own timeouts and transient blips rather than escalating every hiccup. Bubble up to the coordinator only when it truly can't proceed — and include the partial results and what it already tried so the coordinator isn't starting blind.

چھوٹے ایجنٹ کو اپنے timeout اور وقتی جھٹکے خود دوبارہ کوشش کر کے سنبھالنے دیں، ہر معمولی رکاوٹ آگے نہ بھیجیں۔ صرف تب بڑے ایجنٹ تک بات لے جائیں جب وہ واقعی آگے نہ بڑھ سکے — اور ادھورے نتائج اور کی گئی کوشش ساتھ دیں تاکہ بڑا ایجنٹ اندھیرے میں شروع نہ کرے۔

# inside the subagent:
for attempt in 1..3:
    r = fetch(url)
    if r.ok: return r                 # recover transient failures locally
# only if still failing, propagate WITH context:
return { "isError": true, "errorCategory": "transient",
         "attempted": url, "partial_results": cached }

'No orders found' is a successful query with an empty result — not an error. Conflating the two makes the agent retry pointlessly or report a false failure.

'کوئی آرڈر نہیں ملا' ایک کامیاب کھوج ہے جس کا نتیجہ خالی ہے — خرابی نہیں۔ دونوں کو ایک سمجھنا ایجنٹ سے بے فائدہ دوبارہ کوشش یا جھوٹی ناکامی کی رپورٹ کرا دیتا ہے۔

search("orders for C-8842") -> []      # SUCCESS, zero matches (data)
  -> { "isError": false, "results": [] }
gateway timeout                          # ACCESS FAILURE (retry/escalate)
  -> { "isError": true, "errorCategory": "transient", "isRetryable": true }
// never report "no orders" when the lookup actually failed

Every extra tool is another option the model must weigh. Past a handful, selection accuracy drops. Give each agent only the tools its role needs.

ہر اضافی ٹول ایک اور اختیار ہے جسے ماڈل کو تولنا پڑتا ہے۔ چند سے زیادہ ہوں تو صحیح چناؤ کم ہو جاتا ہے۔ ہر ایجنٹ کو صرف اس کے کام کے ٹول دیں۔

If a synthesis agent has web-search tools, it will sometimes wander off to search instead of synthesizing. Removing out-of-role tools keeps agents in their lane.

اگر ملانے والے ایجنٹ کے پاس web-search ٹول ہوں تو وہ کبھی ملانے کے بجائے کھوج میں بھٹک جائے گا۔ کام سے باہر کے ٹول ہٹانا ایجنٹوں کو اپنے دائرے میں رکھتا ہے۔

Scope tightly, but allow a small, well-chosen cross-role tool when a need is common enough to justify it (e.g. a verify_fact tool for synthesis).

دائرہ تنگ رکھیں، مگر جب کوئی ضرورت اتنی عام ہو کہ جائز ہو تو ایک چھوٹا، سوچا سمجھا دوسرے دائرے کا ٹول دے دیں (مثلاً ملانے کے لیے verify_fact ٹول)۔

auto lets the model choose whether to call a tool at all (it may answer in text). any forces it to call SOME tool. Forced selection makes it call a SPECIFIC named tool. Use these to guarantee structure or ordering.

auto ماڈل کو یہ چننے دیتا ہے کہ ٹول چلائے بھی یا نہیں (وہ متن میں جواب دے سکتا ہے)۔ any اسے کوئی نہ کوئی ٹول چلانے پر مجبور کرتا ہے۔ مجبور کرنا اسے ایک خاص نامی ٹول چلواتا ہے۔ انہیں ساخت یا ترتیب کی ضمانت کے لیے استعمال کریں۔

Give a synthesis agent no web-search tools and it can't wander off to search mid-task. Scoping tools to the role keeps each agent in its lane and shrinks the selection space, which also improves accuracy.

ملانے والے ایجنٹ کو web-search ٹول نہ دیں تو وہ بیچ کام میں کھوج کی طرف بھٹک نہیں سکتا۔ ٹولز کو کردار تک محدود رکھنا ہر ایجنٹ کو اپنے دائرے میں رکھتا ہے اور چناؤ آسان کرتا ہے، جس سے درستگی بھی بہتر ہوتی ہے۔

synthesis_agent = AgentDefinition(
  allowedTools=['write_report', 'verify_fact'])   # NO web_search
// with search tools present it wanders off mid-synthesis;
// fewer, role-scoped tools also raise selection accuracy

A constrained tool that only accepts valid document URLs prevents misuse better than a general fetch_url that will fetch anything.

ایک محدود ٹول جو صرف درست دستاویز URL قبول کرے، عام fetch_url سے بہتر غلط استعمال روکتا ہے جو کچھ بھی لے آتا ہے۔

// generic: fetches anything, easy to misuse
fetch_url(url)
// constrained: validates the input first
load_document(url):
    if not is_document_url(url): return error('not a document URL')
    ...

When a role needs a bit of another role's capability often (synthesis doing quick fact-checks), give it a narrow, purpose-built tool for the common case instead of the full toolset — and send the rare complex cases back through the coordinator. That's least privilege in practice.

جب کسی کردار کو اکثر دوسرے کردار کی تھوڑی صلاحیت چاہیے ہو (ملانے والا جلدی fact-check کرے)، تو اسے عام کام کے لیے ایک محدود، خاص مقصد کا ٹول دیں، پورا ٹول سیٹ نہیں — اور کبھی کبھار کے پیچیدہ معاملے بڑے ایجنٹ کے ذریعے بھیجیں۔ عملاً یہی کم سے کم اختیار ہے۔

// synthesis needs quick fact-checks ~85% of the time:
synthesis.allowedTools = ['write_report', 'verify_fact']  # narrow, purpose-built
// the rare ~15% deep research -> route back through the coordinator
// (NOT the full web-search toolset)

Forcing a named tool guarantees a required first step happens before anything else — useful when later work depends on it. Handle the subsequent steps in follow-up turns once that output exists.

کسی نامی ٹول کو مجبور کرنا یقینی بناتا ہے کہ ایک ضروری پہلا قدم سب سے پہلے ہو — تب مفید جب آگے کا کام اسی پر منحصر ہو۔ باقی مرحلے اگلی باریوں میں کریں جب وہ نتیجہ موجود ہو۔

tool_choice = { 'type': 'tool', 'name': 'extract_metadata' }  # must run first

any forces the model to call SOME tool instead of replying in prose — the right setting when you need structured action every time but don't care which of several tools it picks.

any ماڈل کو عبارت میں جواب دینے کے بجائے کوئی نہ کوئی ٹول چلانے پر مجبور کرتا ہے — تب درست جب آپ کو ہر بار منظم عمل چاہیے مگر یہ فرق نہ پڑے کہ کئی میں سے کون سا ٹول چنے۔

tool_choice = { 'type': 'any' }   # MUST call some tool; model picks which
// use when every turn must produce a structured action;
// 'auto' would let it reply in conversational prose instead

Put team-shared servers in the project's .mcp.json so everyone gets them on clone/pull. Put personal or experimental servers in your user-level ~/.claude.json, which is not shared with teammates.

ٹیم کے ساتھ شیئر ہونے والے سرور پروجیکٹ کے .mcp.json میں رکھیں تاکہ سب کو clone/pull پر مل جائیں۔ ذاتی یا آزمائشی سرور اپنے یوزر لیول ~/.claude.json میں رکھیں، جو ساتھیوں سے شیئر نہیں ہوتا۔

Reference secrets via ${ENV_VAR} so the config can be committed while the actual token stays in the environment, never in VCS.

رازوں کا حوالہ ${ENV_VAR} سے دیں تاکہ کنفیگ commit ہو سکے جبکہ اصل ٹوکن environment میں رہے، کبھی ورژن کنٹرول میں نہ جائے۔

{ "mcpServers": {
  "github": {
    "command": "github-mcp",
    "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } } } }

When Claude Code connects, it discovers tools from every configured MCP server at once — project and user servers are all available together in the same session.

جب Claude Code جُڑتا ہے تو یہ ہر طے شدہ MCP سرور کے ٹول ایک ساتھ دریافت کر لیتا ہے — پروجیکٹ اور یوزر دونوں کے سرور اسی سیشن میں مل کر دستیاب ہوتے ہیں۔

Resources let a server publish browsable content (a schema, an issue list) so the agent can see what's available without making repeated exploratory tool calls to discover it.

Resources سرور کو دیکھنے لائق مواد پیش کرنے دیتے ہیں (schema، issue کی فہرست) تاکہ ایجنٹ بار بار کھوجی ٹول کالیں کیے بغیر دیکھ لے کیا دستیاب ہے۔

Commit the server config so every teammate gets it on pull, but keep the actual secret out of VCS by referencing it as ${ENV_VAR}. The config is shared; the credential stays in each person's environment.

سرور کنفیگ commit کریں تاکہ ہر ساتھی کو pull پر ملے، مگر اصل راز کو ${ENV_VAR} کے حوالے سے ورژن کنٹرول سے باہر رکھیں۔ کنفیگ شیئر ہوتا ہے؛ اسناد ہر شخص کے environment میں رہتی ہیں۔

// .mcp.json (committed)
{ "mcpServers": { "github": {
  "command": "github-mcp",
  "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" } } } }

Put servers only you use (a scratch experiment, a personal account) in the user-scoped file so they don't get pushed onto the whole team. This is also why a teammate 'doesn't have' a server you added — it lives in your user scope, not the project's.

صرف اپنے استعمال کے سرور (کوئی آزمائش، ذاتی اکاؤنٹ) یوزر سکوپ فائل میں رکھیں تاکہ وہ پوری ٹیم پر نہ چڑھ جائیں۔ یہی وجہ بھی ہے کہ کسی ساتھی کے پاس آپ کا شامل کیا سرور 'نہیں ہوتا' — وہ آپ کے یوزر سکوپ میں ہے، پروجیکٹ کے نہیں۔

// ~/.claude.json  (personal, NOT shared via VCS)
{ "mcpServers": { "my-scratch-db": { "command": "sqlite-mcp", ... } } }
// this is exactly why a teammate "doesn't have" a server you added:
// it lives in your user scope, not the project's .mcp.json

If a custom MCP tool is better than the built-in Grep for a job, its description must sell that clearly — otherwise the model defaults to the familiar built-in.

اگر کوئی اپنا MCP ٹول کسی کام کے لیے بلٹ اِن Grep سے بہتر ہے، تو اس کی description یہ بات صاف بتائے — ورنہ ماڈل جانے پہچانے بلٹ اِن کی طرف چلا جاتا ہے۔

// weak -> model just uses built-in Grep:
code_search: 'Search code'
// strong -> sells the advantage:
code_search: 'Symbol-aware search across the indexed repo. Finds callers
  through re-exports/aliases that plain Grep misses. Prefer for "who calls X".'

Don't build what already exists. Standard integrations (Jira, GitHub, Slack) have maintained community servers — adopt those and spend your custom-server effort only on workflows unique to your team.

جو پہلے سے موجود ہے وہ نہ بنائیں۔ عام جوڑ توڑ (Jira، GitHub، Slack) کے سنبھالے ہوئے community سرور ہیں — انہیں اپنائیں اور اپنی محنت صرف اُن کاموں پر لگائیں جو آپ کی ٹیم کے لیے خاص ہیں۔

Jira / GitHub / Slack?          -> adopt the maintained community MCP server
Team's bespoke deploy-approval? -> build a custom server
// don't reinvent standard integrations; spend effort on the unique ~20%

Publishing a schema, issue list, or doc hierarchy as an MCP resource lets the agent SEE what's available and read it directly, instead of burning tool calls probing to discover what exists.

کسی schema، issue کی فہرست، یا دستاویزوں کے ڈھانچے کو MCP resource کے طور پر پیش کرنا ایجنٹ کو دیکھنے اور سیدھا پڑھنے دیتا ہے کیا دستیاب ہے، بجائے اس کے کہ ٹول کالیں لگا کر معلوم کرے کیا موجود ہے۔

// server publishes a resource the agent can READ directly:
resource "db://schema" -> { tables: [...], columns: [...] }
// agent reads the schema once, instead of firing 10 exploratory
// "list tables" / "describe table" tool calls to discover it

Use Grep to search INSIDE files (function names, error strings, imports). Use Glob to find files BY name/extension pattern. They answer different questions: 'where is this text?' vs 'which files match this pattern?'.

فائلوں کے اندر ڈھونڈنے کے لیے Grep استعمال کریں (فنکشن نام، خرابی کے الفاظ، imports)۔ نام/قسم کے نمونے سے فائلیں ڈھونڈنے کے لیے Glob۔ یہ الگ سوالوں کے جواب دیتے ہیں: 'یہ متن کہاں ہے؟' بمقابلہ 'کون سی فائلیں اس نمونے سے ملتی ہیں؟'۔

Edit changes a file by matching a unique snippet of text and replacing it. Read/Write handle whole files. Edit is precise but requires the anchor text to be unique.

Edit ایک منفرد متن کے ٹکڑے کو ملا کر بدل دیتا ہے۔ Read/Write پوری فائلیں سنبھالتے ہیں۔ Edit درست ہے مگر اسے منفرد anchor متن چاہیے۔

If the anchor text appears more than once, Edit can't safely target it. Read the whole file, construct the new content, and Write it back.

اگر anchor متن ایک سے زیادہ بار ہو تو Edit اسے محفوظ طریقے سے نشانہ نہیں بنا سکتا۔ پوری فائل Read کریں، نیا مواد بنائیں، اور واپس Write کریں۔

Grep answers 'where does this TEXT appear?' — reach for it to find every caller of a function, an error string, or an import. It searches inside files, not filenames.

Grep کا جواب 'یہ متن کہاں آتا ہے؟' — کسی فنکشن کے سب استعمال، خرابی کا لفظ، یا import ڈھونڈنے کے لیے اسے استعمال کریں۔ یہ فائلوں کے اندر ڈھونڈتا ہے، فائل ناموں میں نہیں۔

Grep 'processRefund'   # every file/line that references the function

Glob answers 'which FILES match this name pattern?' — use it to enumerate files by extension or path shape before you decide what to read.

Glob کا جواب 'کون سی فائلیں اس نام کے نمونے سے ملتی ہیں؟' — کیا پڑھنا ہے یہ طے کرنے سے پہلے قسم یا راستے کی شکل سے فائلیں گننے کے لیے اسے استعمال کریں۔

Glob '**/*.test.tsx'   # all test files, by path pattern

Edit needs a unique anchor snippet; when the text appears more than once it can't safely target the change. Don't just retry — Read the whole file, build the new content, and Write it back.

Edit کو منفرد anchor ٹکڑا چاہیے؛ جب متن ایک سے زیادہ بار ہو تو یہ تبدیلی کو محفوظ نشانہ نہیں بنا سکتا۔ بار بار نہ آزمائیں — پوری فائل Read کریں، نیا مواد بنائیں، اور واپس Write کریں۔

Edit(file, old="return None")  -> ERROR: 'return None' appears 6x (ambiguous)
// fallback (don't just retry the same Edit):
content = Read(file)
new = content.replace(<a larger, unique surrounding region>)
Write(file, new)

Reading everything blows the context budget. Grep to locate entry points, then follow imports with targeted Reads. This keeps context lean and focused.

سب کچھ پڑھنا سیاق کا بجٹ ختم کر دیتا ہے۔ Grep سے داخلے کے مقام ڈھونڈیں، پھر مخصوص Reads سے imports کا پیچھا کریں۔ اس سے سیاق ہلکا اور مرکوز رہتا ہے۔

1. Grep 'def main('       # find the entry point
2. Read main.py           # follow its imports outward
3. Grep/Read only what the trace actually touches
// reading ALL files upfront blows the context budget

When a module re-exports under different names, a single search misses callers. First list everything the module exports, then Grep each exported name so you catch usages that go through wrappers/aliases.

جب کوئی ماڈیول مختلف ناموں سے دوبارہ export کرے تو ایک ہی کھوج کچھ استعمال چھوڑ دیتی ہے۔ پہلے ماڈیول کے سب exports کی فہرست بنائیں، پھر ہر export نام کو Grep کریں تاکہ wrapper/alias سے ہونے والا استعمال بھی پکڑا جائے۔

# utils.py re-exports under a new name:
#   from .core import refund as process_refund
1. list the module's exports -> [process_refund, ...]
2. Grep EACH exported name across the repo
// searching only 'refund' misses callers that import 'process_refund'