MCP, tools i centralny dostęp
- data
- kategoria
- AI Agents
- czytanie
- 1 min / 270 słów
Implementer Agent nie tylko czyta kod.
Musi również wykonać akcje:
read Jira issue
push branch
create PR
comment on ticket
read CI result
W local environment developer często podłączał tools sam.
Na przykład:
local agent
|
v
local MCP
|
v
GitHub PAT
|
v
GitHub
Przy większej skali oznacza to dziesiątki osobnych tokenów, konfiguracji i scopes.
Co wprowadzamy
Wspólną warstwę tools:
Approved Tools
|
┌─────────────┼─────────────┐
v v v
GitHub Jira CI/CD
\ | /
\ | /
MCP / Tool Gateway
|
agents
Agent nadal widzi proste capabilities:
jira.get_issue()
github.create_pull_request()
ci.get_build_result()
Skąd agent wie, którego toola użyć
Tak samo jak przy RAG.
Każdy tool ma:
- nazwę,
- description,
- input schema.
Przykład:
github.create_pull_request
Use when implementation is complete,
required tests have passed and code should be submitted for review.
Model wybiera tool na podstawie taska i aktualnego stanu workflow.
Autoryzacja
MCP nie rozwiązuje auth automatycznie.
Organizacja może natomiast zbudować auth wokół wspólnej warstwy:
agent identity
|
v
policy
|
v
tool gateway / MCP
|
v
GitHub
Dzięki temu developer nie musi tworzyć własnego PAT-a.
Gdzie to konfigurujemy
Platform team
- GitHub App / OAuth,
- Jira integration,
- allowed repos,
- read/write,
- policy,
- audit,
- approved MCP servers.
Repo agenta
Deklaruje:
tools:
- jira.get_issue
- github.push_branch
- github.create_pull_request
Repo produktu
Może określić dodatkowe ograniczenia:
- nie pushuj bezpośrednio do main
- PR zawsze do main
- production deployment wymaga human approval
Narzędzia na rynku
| Rozwiązanie | Cloud / typ | Rola |
|---|---|---|
| Microsoft Foundry tools / MCP | Azure | tools dla managed agents i integracje MCP |
| Amazon Bedrock AgentCore Gateway | AWS | bezpieczny gateway do tools/MCP, auth i policies |
| Google Agent Gateway / managed MCP | GCP | kontrolowany dostęp agentów do tools |
| własny MCP server | dowolne | pełna kontrola, ale auth i utrzymanie po twojej stronie |
Co zmienia się organizacyjnie
Pytanie przestaje brzmieć:
Jak każdy developer podłączy GitHuba do swojego agenta?
Zaczyna brzmieć:
Jakie operacje GitHuba organizacja udostępnia agentom i na jakich zasadach?
To jest duża zmiana odpowiedzialności.