Tharga.Team.Mcp 3.8.1

Tharga Team Mcp

Team bridge for Tharga.Mcp. Connects MCP tool and resource invocations to Tharga.Team's authentication, scope enforcement, and audit logging.

Renamed from Tharga.Platform.Mcp. NuGet package IDs cannot be renamed, so this is a new ID and the old one is deprecated. Migrating is a deliberate step with two breaking changes: mcp.AddPlatform() is now mcp.AddTeam(), and every resource URI moved from platform:// to team:// — update any MCP client that references them by string.

What it does

• Populates IMcpContext from the authenticated HttpContext.User (works with both OIDC and API Key authentication)
• Enforces provider scope class: McpScope.System requires Roles.Developer, McpScope.Team requires team membership
• Emits audit log entries for every MCP tool invocation — success and failure
• Registers built-in mcp:* scopes in both of Team's scope registries — see below
• Requires authentication on the MCP endpoint — anonymous requests are rejected

Quick start

builder.Services.AddThargaMcp(mcp =>
{
    mcp.AddTeam();        // bridge to Team auth/scopes/audit
    // ... other provider packages (e.g. mcp.AddMongoDB())
});

app.UseThargaMcp();

Granting mcp:discover

AddTeam() registers the built-in mcp:* scopes in both the team and the system registry, because both routes to holding one are legitimate. mcp:discover can therefore be granted three ways:

IMcpScopeChecker accepts either provenance. A system grant authorizes with no team selected; a team grant authorizes only alongside a TeamKey claim — a scope claim without a team context is not a grant, and is refused.

public sealed class MyTool(IMcpScopeChecker scopeChecker)
{
    public Task<string> ListAsync()
    {
        scopeChecker.Require(McpScopes.Discover);   // throws UnauthorizedAccessException if not held
        ...
    }
}

IMcpScopeChecker is an opt-in helper for tools that want to enforce a scope imperatively; nothing in this package or Tharga.MongoDB.Mcp calls it for you.

Behaviour change. mcp:discover was previously registered as a team scope but checked only against system claims, so an access-level grant could never satisfy it and a tool calling Require(McpScopes.Discover) rejected every caller — including a team Owner. If you wrote a test asserting that rejection, it now passes the caller instead.

User and team resources

Always-on resource providers that surface the authenticated caller's own data. Both providers self-gate on the principal's claims, so anonymous and system-only callers see no resources.

User scope (McpScope.User)

Listed when the principal carries a NameIdentifier (or equivalent) claim. Read fails with UnauthorizedAccessException if IUserService.GetCurrentUserAsync returns null.

Team scope (McpScope.Team)

Listed only when the principal carries a TeamKey claim. Read fails with UnauthorizedAccessException if no team is selected. Cross-tenant team listing (reading other teams) is intentionally not supported here — that's a future system-scope provider once ITeamService.GetAllTeamsAsync is added.

System-scope diagnostic resources (opt-in)

Expose read-only diagnostic data under team://system/* for callers with the Developer role. Non-developers see no resources and get UnauthorizedAccessException on read.

builder.Services.AddThargaMcp(mcp =>
{
    mcp.AddTeam(o =>
    {
        o.ExposeSystemResources = true;
    });
});

Available resources (listed only when the matching dependency is registered):

Per-team API-key listings now ship under team://team/apikeys (see "Team scope" above). Cross-tenant team listings remain deferred — they require a new ITeamService.GetAllTeamsAsync method.

Related packages