Struct GitLabSchemaEnricher 

pub struct GitLabSchemaEnricher;

Static schema enricher for GitLab provider.

GitLab doesn’t support:

• priority (no built-in priority on issues)
• parentId (no subtask hierarchy via API)
• customFields (no custom fields)
• issueType (no issue types)
• components (no components)
• projectId (single project scope, not needed)
• points (no story points)

Trait Implementations

impl ToolEnricher for GitLabSchemaEnricher

fn value_model(&self, tool_name: &str) -> Option<ToolValueModel>

Paper 3 — value-model annotations for GitLab read-only tools.

Speculative pre-fetch wins for the canonical list → detail chains: after get_merge_requests the agent almost always reads discussions / diffs of the top hit; after get_issues it reads comments. We annotate the read-only endpoints (Pure for inside-of-TTL, ReadOnly otherwise) and leave mutating endpoints (create_issue, update_issue, …) as the default Indeterminate so they are never speculated.

fn rate_limit_host(&self, _tool_name: &str, _args: &Value) -> Option<String>

Paper 3 — gitlab.com for SaaS, picked up from the runtime args if the tool carries an explicit instance URL. We don’t look at args here because GitLab tools live behind one configured client per session; the host falls back to the tool’s static rate_limit_host annotation.

fn supported_categories(&self) -> &[ToolCategory]

Which tool categories this provider/enricher supports. Tools from other categories won’t be shown when this enricher is active.

fn enrich_schema(&self, tool_name: &str, schema: &mut ToolSchema)

Modify the tool schema during tools/list.

fn transform_args(&self, _tool_name: &str, _args: &mut Value)

Transform arguments before tool execution.

fn project_args( &self, _prev_tool: &str, _prev_result: &Value, _link: &FollowUpLink, ) -> Option<Value>

Build the JSON arguments for a speculatively pre-fetched follow-up call.