Lumaktaw papunta sa content

Mga Resipe

Mga praktikal na recipe para sa pang-araw-araw na gawaing Maguyva MCP. Inililista ng bawat recipe ang mga tool at ang pagkakasunud-sunod ng paggamit — hindi ito kumpletong parameter reference. Para sa mga parameter ng tool, gamitin ang Sanggunian sa MCP API. Para sa unang setup, gamitin ang Quickstart.

Mga input para sa MCP tools/call ang mga JSON block. Palitan ang owner/repo, branch, at mga pangalan ng symbol ng mga value mula sa iyong repository.

Piliin ang tamang tool

#

Karamihan sa mga tanong ay nagsisimula sa isang call. Gumamit lang ng mas masusing paraan kapag masyadong malawak o kulang sa detalye ang unang sagot.

  • intelligent_search — magsimula rito para sa tanong tungkol sa codebase na nakasulat sa natural na wika. Sa default na auto/balanced, ang mga query na may mataas na kumpiyansang natukoy bilang paghahanap ng definition ay dinadala sa structural search, ang mga tanong tungkol sa reference o epekto sa graph, at ang mga tanong tungkol sa eksaktong tugma sa text search. Gumagamit ang ibang tanong ng semantic na kahulugan at naka-index na text. Gamitin ang mode=hybrid o auto na may quality=thorough para hilingin ang lahat ng apat na paraan ng paghahanap. Mas nasusunod ang tahasang piniling mode kaysa sa quality.
  • find_symbol — alam mo na ang function, klase, o variable na pangalan.
  • dependency_search — saklaw ng epekto: mga tumatawag, dependent, o epekto bago (at pagkatapos) ng isang pag-edit.
  • get_task_context — hindi pamilyar na lugar; isang bounded na bundle ng mga file, symbols, at dependencies para sa isang paglalarawan ng gawain.
  • repository_context — maglista ng mga naa-access na repositoryo o siyasatin kung paano niresolba ang pangalan ng repositoryo.
  • ask_maguyva na may operation="guidance" — lokal na tulong sa pagpili ng tool at paggamit ng Maguyva (walang repo mutation).

I-install at i-verify ang isang kliyente

#

Ikonekta ang Maguyva sa MCP client mo at kumpirmahin ang koneksyon gamit ang tunay na listahan ng mga repository.

  1. Gumawa ng API key sa app.maguyva.ai (nagsisimula ang mga key sa mgv_).
  2. Kumonekta at mag-index ng kahit isang GitHub repository na naiintindihan mo na.
  3. I-wire ang iyong kliyente gamit ang Gabay sa Pag-install (Claude Code plugin, o native remote config para sa Cursor, VS Code, Devin Desktop, Zed, at iba pa).
  4. Itanong sa agent mo ang "Anong mga repositoryo ang ikinonekta ko?" — sinusubok nito ang authentication at repository_context mula simula hanggang dulo.
  5. Magtanong ng isang tunay na tanong tungkol sa repo na iyon na ang sagot ay kaya mong markahan. Dapat mong makita ang mga path ng file at mga numero ng linya mula sa naka-index na tree.
repository_context
{
  "name": "repository_context",
  "arguments": {
    "action": "list"
  }
}

May problema sa mga key, bridge, o nawawalang repo? Pag-troubleshoot.

Magtanong bago ka mag-edit

#

I-map ang mga symbol at saklaw ng epekto bago baguhin ang shared code. Hindi binabago ng mga tool ng Maguyva ang mga repository mo — nagbibigay ang mga ito ng batayan para sa edit na inilalapat ng client mo locally.

  1. Kung alam mo ang pangalan ng symbol, tawagan ang find_symbol upang mapunta sa mga kahulugan at paggamit.
  2. Kung mayroon ka lang paglalarawan ng gawain ("idagdag ang SSO", "ayusin ang webhook sa pagsingil"), magsimula sa get_task_context o intelligent_search.
  3. Bago i-edit ang isang shared symbol, tawagan ang dependency_search gamit ang dependents/impact analysis (o ipasa ang mga nabagong path para sa PR-style impact) para makita mo ang saklaw ng epekto.
  4. Buksan ang mga binanggit na file (lokal na read para sa mga file sa disk; get_file para sa remote/cross-repo path) at kumpirmahin ang plano laban sa totoong code.
  5. Pagkatapos mag-edit, suriin muli ang parehong mga simbolo gamit ang dependency_search, na may verify_after_edit=true at targets o changed_paths. Naka-index na graph ang binabasa nito, hindi ang mga lokal na pagbabagong hindi pa naka-commit: tingnan ang indexed_commit_sha at kung gaano kabago ang index bago ituring itong ebidensiya para sa bagong revision, at patakbuhin ang mga lokal na test.
dependency_search
{
  "name": "dependency_search",
  "arguments": {
    "repository": "owner/repo",
    "target": "getCurrentUser",
    "exact_match": true,
    "analysis_type": "impact",
    "depth": "shallow",
    "include_metrics": true,
    "limit": 10
  }
}

Buong mga parameter: Sanggunian sa MCP API.

Maghanap, pagkatapos ay baguhin

#

Isang default na agent loop: i-explore → pin symbols → i-edit gamit ang ebidensya.

  1. Magsimula sa intelligent_search at isang query sa simpleng wika ("paano gumagana ang pag-expire ng session", "nasaan ang retry logic").
  2. Limitahan gamit ang mga filter ng wika o path kapag maraming di-kaugnay na resulta sa unang batch. Inaalis ng language_filter ang graph sa auto/hybrid; ang auto query na dinadala lang sa graph ay bumabalik sa semantic at text search. Tinatanggihan ang tahasang graph mode na may language_filter. Tingnan ang routing_decision.modalities_used para makita ang napiling plano ng paghahanap; lumilitaw lang ang warnings kapag may binanggit na babala ang server.
  3. I-promote ang mga promising hit sa find_symbol o dependency_search sa halip na muling itanong ang parehong hindi malinaw na tanong.
  4. Gamitin lang ang get_file kapag kailangan mo ng partikular na naka-index na landas na wala sa disk.
  5. I-edit sa iyong normal na tool ng kliyente. Ang Maguyva ay para sa pagtuklas at pag-verify — hindi nagsusulat.
intelligent_search
{
  "name": "intelligent_search",
  "arguments": {
    "repository": "owner/repo",
    "query": "How does session expiry work?",
    "limit": 5
  }
}

Bakit gumagana ang loop na ito: Paano Ito Gumagana.

Walang resulta o kulang sa detalye

#

Kapag walang ibinabalik na kapaki-pakinabang ang mga tool, ayusin muna ang resolution at indexing sa halip na paulit-ulit na baguhin ang query.

  1. Kumpirmahin na ang repository ay konektado at tapos na ang pag-index sa app.maguyva.ai.
  2. Suriin ang repository string: ginagamit ng "owner/repo" ang default branch; pini-pin ng "owner/repo:branch" ang isang branch. Case-insensitive ang matching, hindi fuzzy — hindi awtomatikong naitatama ang mga typo.
  3. Tawagan ang repository_context gamit ang action="info" at siyasatin ang resolution metadata (halimbawa metadata.resolution_reason).
  4. Alisin lamang ang repository kapag ang iyong MCP na kliyente ay nag-supply ng default na kahilingan o maaaring ma-access ng key ang eksaktong isang repositoryo; kung hindi ay ipasa ito nang tahasan.
  5. Subukang muli gamit ang isang mas partikular na query, isang kilalang pangalan ng symbol sa pamamagitan ng find_symbol, o isang filter ng wika/path. Kung ang koneksyon mismo ay sira, gamitin ang Pag-troubleshoot.
repository_context
{
  "name": "repository_context",
  "arguments": {
    "action": "info",
    "repository": "owner/repo:main"
  }
}

Mga pagkabigo sa pag-setup: Pag-troubleshoot.

Magtrabaho sa maraming repositoryo

#

I-target ang tamang na-index na repo kapag ang isang key ay nakakakita ng higit sa isa.

  1. Tawagan ang repository_context gamit ang action="list" nang isang beses upang malaman ang eksaktong mga slug na maaaring hanapin ng iyong key.
  2. Ipasa ang repository nang tahasan sa paghahanap at mga tool ng symbol kapag kailangan mo ng hindi default na repo (halimbawa, "owner/other-repo" o "owner/other-repo:develop").
  3. Panatilihin ang isang tanong = isang repositoryo maliban kung sinasadya mong ihambing ang mga repo sa magkakahiwalay na tawag.
  4. Gamitin ang get_file kapag nasa isang naka-index na repo ang file, at hindi iyon ang kasalukuyan mong working tree.
  5. Tandaan: ang mga tool ay hindi kailanman sumulat sa GitHub — multi-repo context ay para lamang sa pagbabasa at pagpaplano.

Mga detalye ng format ng repository: Sanggunian sa MCP API.

Unang beses mag-setup? Magsimula sa Quickstart, saka gamitin ang mga gabay na ito para sa pang-araw-araw na gawain.

Mga susunod na hakbang

#