Attributes

Attributes on your own classes and methods tell MentorAgent what the agent may do. MentorAgent finds them in the assemblies listed in ScanAssemblies. Register every class whose methods become tools in dependency injection (DI). If the container cannot create a class, MentorAgent leaves its methods out and logs a warning.

[TeamMember] and [TeamTerminationCondition] are in the global namespace, so they need no using. Which level to use explains when to use actions, specialists or teams.

Put it on a public method of a service you register in DI: the method becomes a tool the agent can call. A method with only [Description] from System.ComponentModel is an action too, with no rules: no roles and no confirmation. The default confirmation of RequireConfirmationForWrites covers [MentorAction] methods only.

public class CaseService(ICaseStore store)
{
    // Only reads: it never asks for confirmation
    [MentorAction(Description = "Gets the status of a support case", ReadOnly = true)]
    public Task<string> GetStatusAsync(string caseNumber)
        => store.GetStatusAsync(caseNumber);

    [MentorAction(
        Description = "Closes a support case with a resolution",
        Category = "Cases",
        RequiresConfirmation = true,
        RequiredRoles = ["Supervisors", "Admins"],
        ProactiveHint = "Suggest checking the case status first",
        NavigateTo = "/cases")]
    public Task CloseCaseAsync(string caseNumber, string resolution)
        => store.CloseAsync(caseNumber, resolution);
}

• Tool names. The tool name comes from the method name: PascalCase becomes snake case (lowercase words joined by underscores), and a trailing Async is dropped first. CloseCaseAsync is close_case. Options that name tools, such as RequiresApproval, use this name.
• Roles on a server. On the SignalR hub, on /mentor/chat and over A2A, MentorAgent reads the user from the request. AddMentorAgentServer() (or AddMentorAgentA2A() for A2A alone) gives it the caller, whatever the order of AddRazorComponents() and AddMentorAgentServer() in a Blazor Web App. In a Blazor circuit, it asks the AuthenticationStateProvider of the host. A claim that only your own provider adds is not seen on the hub, on /mentor/chat or over A2A: add it with an IClaimsTransformation, which ASP.NET Core applies to HttpContext.User and so to the user of the hub connection.
• Which methods become tools. MentorAgent finds the public instance methods declared on the class itself that have [MentorAction] or a [Description] with a text. It ignores inherited methods, static methods and an empty [Description]. The same rules apply to a specialist and to the Tools of a team member.
• Every level. The same checks apply when a specialist or a team member calls the method. See Roles, confirmation and governance.

Put it on a class to make it a specialist: its [Description] and [MentorAction] methods become the specialist's tools, and the coordinator hands it the requests it can handle. Register the class in DI. Specialists need ChatClient. Implementing IMentorAgent is optional: MentorAgent never reads it.

[MentorAgent(
    Name = "CaseAgent",
    Description = "Handles support cases: status, history and closing",
    HandoffTo = ["BillingAgent"])]
public class CaseAgent(ICaseStore store) : IMentorAgent
{
    [Description("Gets the status of a support case")]
    public Task<string> GetCaseStatusAsync(string caseNumber)
        => store.GetStatusAsync(caseNumber);
}

Put it on a class to define a group chat: the members discuss the request, then the coordinator answers with the result. The team is a tool of the coordinator, named after the team: EscalationReview becomes escalation_review. Teams need ChatClient. Implementing IMentorTeam is optional.

[MentorTeam(
    Name = "EscalationReview",
    Description = "Reviews a request to escalate a support case",
    TriggerOn = ["escalation review"],
    MaxIterations = 6,
    HandoffTo = ["CaseAgent"])]
public class EscalationReviewTeam : IMentorTeam
{
    [TeamMember(
        Role = "Analyst",
        Instructions = "Summarize the case history and propose a decision.",
        Tools = [typeof(CaseReports)])]
    public object? Analyst { get; set; }

    [TeamMember(
        Role = "Approver",
        Instructions = "Review the proposal and approve or reject it, with reasons.")]
    public object? Approver { get; set; }

    [TeamTerminationCondition]
    public bool ShouldTerminate(string lastMessage, string lastSpeaker)
        => lastSpeaker == "Approver"
           && (lastMessage.Contains("[TEAM:APPROVED]", StringComparison.Ordinal)
               || lastMessage.Contains("[TEAM:REJECTED]", StringComparison.Ordinal));
}

Put it on a property of a [MentorTeam] class, one property per member, as in the example above.

Writes belong to the specialists named in the team's HandoffTo, which keep their own role and confirmation checks.

Put it on one method of the team class, with the signature bool ShouldTerminate(string lastMessage, string lastSpeaker): the discussion ends when it returns true. Without it, the members speak in turn until MaxIterations. The attribute has no parameters.

MentorAgent instructs the members to mark their decision with [TEAM:APPROVED] or [TEAM:REJECTED], and removes both before the text reaches the user. Your condition can end the discussion on any text it looks for, but only [TEAM:APPROVED], anywhere in the discussion, makes the result ask the coordinator to hand off.

Put it on a routable Blazor page to let the agent open it with navigate_to. The agent knows the page from the start, without visiting it first. In a .razor file, write it with @attribute. With a front end of your own, such as React, put it on an empty class, one per page, in a scanned assembly. Your client then receives the URL, in the NavigationRequested event or in the navigation frame over Server-Sent Events, and routes to it.

@page "/cases"
@using Novior.MentorAgent.Attributes
@attribute [MentorPage(Url = "/cases", Name = "Cases",
    Description = "The list of support cases, with filters by status")]

Put it on a class to register a skill: instructions the model loads with load_skill only when it needs them, while the prompt carries just the name and the description. The class's [Description] and [MentorAction] methods become tools, so register it in DI when it has any. Skills need EnableSkills.

[MentorSkill(
    Name = "case-escalation",
    Description = "Rules for escalating a support case to a supervisor",
    InstructionsFile = "Skills/case-escalation/SKILL.md")]
public class CaseEscalationSkill
{
}

When no file is found, the instructions are just the skill's name and description; a path you gave that does not exist also logs a warning.