Skip to content

SPIKE: Discuss API tool design for MCP tool

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Problem to solve

All MCP tools are currently defined via an API setting that maps 1:1 with our GitLab API. This works well for fast delivery of tools that are basic API calls with the GitLab API, however, there are limitations/pitfalls with the following approach.

Pitfalls:

  • Every MCP tool needs to have an API endpoint to annotate to create a new MCP tool
    • This is an issue because not all useful MCP tools correspond directly to a single GitLab API endpoint
    • We don't support tools that potential only have a GraphQL endpoint to request information and not a private/public facing API
    • Example: (Soon-to-be-implement Codebase Search)
  • The 1:1 mapping approach limits flexibility and composability
    • Cannot easily combine multiple API calls into a single coherent tool
    • Ex: gitlab_search
      • This should be able to access a project/group/namespace without creating three separate tools to the api

We need to investigate how we are currently supporting tools going forward in our GitLab MCP server. Our current approach is either to directly call our api/v4/endpoint or annotate the API endpoint with a new route setting that maps to required params 1:1.

Security for to ensure proper authorization needs to top of mind given these external tools need to be isolated to ensure not accessing resource beyond the user's namespace.

Desired Outcome

  • Define how to determine what kind of tool to build
  • Document what's required for each tool type
  • Create MCP tool development guide (similar to GitLab's migration style guide)
  • Document what kind of tools are supported (granular and complex from #566146)

Proposal

TBD

Resource

Edited by 🤖 GitLab Bot 🤖