Konrad Kowalski (rootsher)Principal Platform & Reliability Architect101010011101110000001100111010100111110101001111

MCP, tools and central access

date
category
AI Agents
also in
Infrastructure & Cloud Security
reading
2 min / 315 words

The Implementer Agent does more than read code.

It also has to take actions:

text
read Jira issue
push branch
create PR
comment on ticket
read CI result

In a local environment the developer often wired up the tools themselves.

For example:

text
local agent
|
v
local MCP
|
v
GitHub PAT
|
v
GitHub

At a larger scale that means dozens of separate tokens, configurations and scopes.

What we introduce

A shared tool layer:

text
                 Approved Tools
                       |
         ┌─────────────┼─────────────┐
         v             v             v
       GitHub         Jira         CI/CD
          \            |            /
           \           |           /
              MCP / Tool Gateway
                       |
                     agents

The agent still sees simple capabilities:

text
jira.get_issue()
github.create_pull_request()
ci.get_build_result()

How the agent knows which tool to use

The same way as with RAG.

Each tool has:

  • a name,
  • a description,
  • an input schema.

Example:

text
github.create_pull_request

Use when implementation is complete,
required tests have passed and code should be submitted for review.

The model picks a tool based on the task and the current state of the workflow.

Authorization

MCP does not solve auth for you.

What the organization can do is build auth around the shared layer:

text
agent identity
|
v
policy
|
v
tool gateway / MCP
|
v
GitHub

That way the developer does not have to create their own PAT.

Where we configure it

Platform team

  • GitHub App / OAuth,
  • Jira integration,
  • allowed repos,
  • read/write,
  • policy,
  • audit,
  • approved MCP servers.

Agent repo

Declares:

text
tools:
- jira.get_issue
- github.push_branch
- github.create_pull_request

Product repo

Can add further restrictions:

text
- do not push directly to main
- PRs always target main
- production deployment requires human approval

Tools on the market

SolutionCloud / typeRole
Microsoft Foundry tools / MCPAzuretools for managed agents and MCP integrations
Amazon Bedrock AgentCore GatewayAWSsecure gateway to tools/MCP, auth and policies
Google Agent Gateway / managed MCPGCPcontrolled agent access to tools
your own MCP serveranyfull control, but auth and maintenance are on you

What changes organizationally

The question stops being:

How will every developer connect GitHub to their agent?

It becomes:

Which GitHub operations does the organization expose to agents, and on what terms?

That is a big shift in responsibility.

Materials

top