elicitationtools

func ActionSpecs ¶

func ActionSpecs(client *gitlabclient.Client) []toolutil.ActionSpec

ActionSpecs returns canonical specs for standalone interactive elicitation actions.

func CancelledResult ¶

func CancelledResult(message string) *mcp.CallToolResult

CancelledResult delegates to elicitation.CancelledResult.

func ConfirmAction ¶

func ConfirmAction(ctx context.Context, req *mcp.CallToolRequest, message string) *mcp.CallToolResult

ConfirmAction delegates to elicitation.ConfirmAction.

func FormatResult ¶

func FormatResult(result any) *mcp.CallToolResult

FormatResult renders elicitation outputs and expected control outcomes.

func IssueCreate ¶

func IssueCreate(ctx context.Context, req *mcp.CallToolRequest, client *gitlabclient.Client, input IssueInput) (issues.Output, error)

IssueCreate guides the user through creating a GitLab issue via step-by-step elicitation prompts for title, description, labels, and confidentiality, then confirms before calling issues.Create. On multi round-trip sessions each prompt travels as an input request and the handler is re-invoked with the accumulated answers.

The summary is written row by row rather than through toolutil.Card, and the reason is toolutil.EscapeConsentValue: it defangs a URL scheme on top of the code span a card writes, which is what a line asking for approval needs and what a result card does not. See [cardDirective] in cmd/audit_md_escaping.

func MRCreate ¶

func MRCreate(ctx context.Context, req *mcp.CallToolRequest, client *gitlabclient.Client, input MRInput) (mergerequests.Output, error)

MRCreate guides the user through creating a GitLab merge request via step-by-step elicitation prompts for branches, title, description, labels, and merge options, then confirms before calling mergerequests.Create. On multi round-trip sessions each prompt travels as an input request and the handler is re-invoked with the accumulated answers.

func ProjectCreate ¶

func ProjectCreate(ctx context.Context, req *mcp.CallToolRequest, client *gitlabclient.Client, _ ProjectInput) (projects.Output, error)

ProjectCreate guides the user through creating a GitLab project via step-by-step elicitation prompts for name, description, visibility, README initialization, and default branch, then confirms before calling projects.Create. On multi round-trip sessions each prompt travels as an input request and the handler is re-invoked with the accumulated answers.

func ReleaseCreate ¶

func ReleaseCreate(ctx context.Context, req *mcp.CallToolRequest, client *gitlabclient.Client, input ReleaseInput) (releases.Output, error)

ReleaseCreate guides the user through creating a GitLab release via step-by-step elicitation prompts for tag name, release name, and description, then confirms before calling releases.Create. On multi round-trip sessions each prompt travels as an input request and the handler is re-invoked with the accumulated answers.

func UnsupportedResult ¶

func UnsupportedResult(actionID, toolName, alternative string) *mcp.CallToolResult

UnsupportedResult returns the refusal a wizard answers with when the MCP client does not support elicitation, naming the flow that was refused and the one action that does the same work without it.

It is prose in the one refusal envelope toolutil.ErrorResult writes, which is what gives it the normalization and the annotation every other refusal carries. The alternative used to be introduced by a bolded label, which is the shape of a card row and is not one: this result is about no GitLab object, so it has no rows.

Both actions are named by catalog ID because the tool that runs one differs by surface: the dynamic surface runs issue.create and the flow itself through gitlab_execute_action and registers no tool of its own for either, meta runs issue.create as an action of the issue domain's tool, and individual as a tool of its own. A sentence naming a per-surface tool is right for one surface of three. The alternative used to name the meta tools, and the issue and merge request ones whichever flow was refused, while each flow's description promised its own; each flow now hands in the one its description names. The refused flow used to be named by its tool alone, which the default surface does not register, so it now leads with the ID and gives the tool only as the name the other two surfaces call it by. cmd/audit_action_ids reads toolutil.ErrorResult's message, but this one is a format whose three values are this function's parameters, which that rule passes over as values the sentence reports: the tool name is one of them on purpose. So no source gate holds the IDs to the catalog here either: a test of the catalog in internal/tools holds every flow's two IDs to actions it serves, and the e2e scenario that quotes both holds the served text.