Agents, Skills, MCP and Webhooks: Connect Without Overgranting
Configure a read-only Azure DevOps MCP connection, separate agent instructions from permissions, and verify cross-platform work-item links.
A technician needs a procedure, a toolbox, and a key
Giving a technician a repair checklist does not give them a building key. Likewise, an agent’s instructions, reusable skills, tool connection, and account permissions are different controls.
| Building block | Job | What it does not guarantee |
|---|---|---|
| Agent instructions | Define role, boundaries, and completion evidence | Enforced service authorization |
| Skill | Package task instructions, scripts, and resources | Automatic trust or availability in every client |
| MCP server | Expose tools and context through a standard protocol | Permission beyond the authenticated identity |
| Webhook | Deliver a subscribed event to an endpoint | A complete business process or safe receiver |
| Agent loop | Observe, act, check, and decide whether to continue | Correctness or an unlimited execution budget |
A useful development contract names the allowed repository, permitted files, test commands, read/write boundaries, budget, approval points, and stop conditions. “Keep working until fixed” is not a safe production authorization policy.
Configure a narrow Azure DevOps connection
Microsoft’s documentation checked on 30 October 2026 recommends the remote Azure DevOps MCP server for supported clients. It uses Microsoft Entra authentication and requires an Entra-backed Azure DevOps organization; standalone Microsoft-account organizations are not supported for that remote path. Client support and authentication differ.
For a supported VS Code MCP configuration, this documented shape limits discovery to selected toolsets and read-only operations:
{
"servers": {
"ado-sandbox": {
"type": "http",
"url": "https://mcp.dev.azure.com/YOUR-ORGANIZATION",
"headers": {
"X-MCP-Toolsets": "repos,wit,wiki",
"X-MCP-Readonly": "true"
}
}
},
"inputs": []
}Replace the organization placeholder. This is a client-specific example, not a universal configuration for every assistant. Use that client’s current setup instructions, complete its sign-in flow, and inspect discovered tools before running anything. The local stdio server is an alternative when the client cannot use remote authentication; it has different configuration and domain selection.
Ask for the sandbox project’s name and one known work item. Verify the returned identifier and URL against Azure DevOps. A successful connection message alone does not establish access to the intended project.
For GitHub MCP, use the official server setup for your client, the narrowest necessary toolsets, and organization-approved authentication. Effective access still depends on token or OAuth scopes, repository access, and organization policy. A tool advertised by the server can still be unavailable to your identity.
Make Boards and GitHub agree on one change
MCP is a way for an assistant to call supported APIs, not a substitute for the Azure Boards-to-GitHub repository connection.
- Confirm the sandbox Boards project is connected to the intended GitHub repository.
- Use read-only tools to fetch the work item and candidate draft PR. Ask the assistant to show both URLs before proposing a change.
- If permitted, separately authorize the specific PR-description edit to add the correct
AB#reference. This requires an appropriate GitHub write tool and permission; the read-only example above deliberately cannot perform writes in Azure DevOps. - Inspect the PR description in GitHub and the development link in Boards. Verify the same work item, repository, and PR on both sides.
This avoids a common failure: a fluent answer saying “linked” when the tool only retrieved two unrelated records. For direct Copilot-from-Boards features, check their distinct prerequisites; the documented integration requires a GitHub repository and GitHub App authentication, not an arbitrary Azure Repos/PAT substitute.
Use event-driven integration deliberately
A webhook is suitable when a completed build or PR event should trigger a receiver. Validate its signature using the provider’s documented method, accept only intended event types, and deduplicate by delivery identifier. Retry handling must not create duplicate tickets or messages.
MCP fits an assistant asking, “Which failed run belongs to this work item?” A skill can encode the repeatable investigation steps and required evidence. These can cooperate, but adding all three does not automatically improve a simple process.
For a feedback loop, define termination: stop after collecting the failing task log, reproducing once, and proposing a reviewed patch; escalate if permissions are missing or the same failure repeats. Agent output must not become the next iteration’s unquestioned ground truth.
Keep client boundaries visible
An IDE assistant, Copilot cloud agent, and code-review agent do not necessarily share secrets, skill locations, approvals, or MCP capabilities. Repository-configured cloud-agent tools can run autonomously, and the documented code-review integration requires read-only tool annotations. Do not assume an IDE confirmation prompt protects cloud execution.
Skills are executable trust packages when they include scripts. Review provenance and pin reviewed versions. Never paste a personal token into repository configuration or enable unrestricted shell access merely to make a skill work.
An agent's instructions say 'read only', but its identity and tools allow PR edits. Which change provides the clearest additional enforcement?
Try it: prove one read, then one proposed link
Prerequisites: an approved supported client, Entra-backed sandbox organization for remote Azure DevOps MCP, project read access, and a connected sandbox GitHub repository if testing links. AI subscriptions and organization policies may limit access.
Configure read-only discovery, retrieve one known item, and ask for a proposed PR-description diff without executing it. Compare the IDs and URLs yourself. If you have separate permission to apply the edit, verify the resulting development link in Boards; otherwise leave it as a proposal.
Expected observation: successful reads identify the right resources; disallowed writes are not silently treated as completed work.
Cleanup: remove the sandbox MCP entry and revoke only any credentials you created for this exercise. Close your disposable PR if used. Do not disconnect a shared production integration.
Decision check: an agent cannot see a repository
Inspect its actual execution surface, authenticated identity, tool allowlist, and organization policy. Do not solve a read-access issue by granting unrestricted organization administration.