Which integrations are available for this server?

Provides tools for querying and managing bugs and merge requests on GitHub, including searching and submitting bugs, and fetching merge requests. Provides tools for querying and managing bugs, packages, versions, and merge requests on Launchpad, including searching and submitting bugs, fetching package details, and retrieving version information. Provides tools for querying package and version information on Snapcraft, including fetching package details and version data.

How do I use Ubuntu MCP Servers?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ubuntu MCP Servers search for bugs about snapd" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Ubuntu MCP Servers

by lvoytek

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Ubuntu MCP Servers

MCP servers for querying and submitting Ubuntu data via ubq. Each server exposes a focused set of tools and resources for a single data domain — bugs, packages, versions, or merge requests.

Requirements

Python >= 3.13
uv (recommended) or pip

Related MCP server: quads-mcp

Installation

git clone https://github.com/lvoytek/ubuntu-mcp.git && cd ubuntu-mcp
uv sync

This installs the five entry-point commands:

Command	Server
`ubuntu-mcp-bugs`	Bug data
`ubuntu-mcp-packages`	Package data
`ubuntu-mcp-versions`	Package version data
`ubuntu-mcp-merge-requests`	Merge request data
`ubuntu-mcp-all`	All of the above at once

Running a server

All servers share the same CLI flags:

ubuntu-mcp-bugs                                           # streamable-http on 0.0.0.0:8000 (default)
ubuntu-mcp-bugs --transport streamable-http --host 127.0.0.1 --port 9000
ubuntu-mcp-bugs --transport stdio                         # for MCP clients that spawn the process

Replace ubuntu-mcp-bugs with any of the commands above.

Running all servers

Use ubuntu-mcp-all to start every server at once on sequential ports:

ubuntu-mcp-all                              # bugs=8000, packages=8001, versions=8002, merge-requests=8003
ubuntu-mcp-all --host 127.0.0.1 --port 9000 # bugs=9000, packages=9001, versions=9002, merge-requests=9003

Connecting an MCP client

For an HTTP server, add the URL to your client config:

{
  "mcp": {
    "ubuntu-mcp-bugs": {
      "type": "remote",
      "url": "http://127.0.0.1:8000/mcp"
    },
    "ubuntu-mcp-packages": {
      "type": "remote",
      "url": "http://127.0.0.1:8001/mcp"
    },
    "ubuntu-mcp-versions": {
      "type": "remote",
      "url": "http://127.0.0.1:8002/mcp"
    },
    "ubuntu-mcp-merge-requests": {
      "type": "remote",
      "url": "http://127.0.0.1:8003/mcp"
    }
  }
}

For stdio, point the client at the entry-point command directly.

Authentication

Most tools require an authenticated session before they can query data. Call login_provider first.

Launchpad

Launchpad supports three authentication modes:

Mode	When
Anonymous	No credentials provided — read-only public access. Best for CI or headless environments.
Credential file	`credential_file` path points to a file containing a Launchpad OAuth token.
Inline token	`token` (and optionally `username`) passed directly.

A default credential file path is also checked automatically: ~/.config/ubq/launchpad-credentials. If this file exists and no other credentials are provided, its contents are used as the token.

Anonymous (no credentials)

{
  "tool": "login_provider",
  "arguments": { "provider_name": "launchpad" }
}

Credential file

{
  "tool": "login_provider",
  "arguments": {
    "provider_name": "launchpad",
    "credential_file": "/path/to/launchpad-token"
  }
}

Inline token

{
  "tool": "login_provider",
  "arguments": {
    "provider_name": "launchpad",
    "token": "oauth-token-value"
  }
}

GitHub

GitHub requires a personal access token passed via token:

{
  "tool": "login_provider",
  "arguments": {
    "provider_name": "github",
    "token": "ghp_xxxxxxxxxxxx"
  }
}

Snapcraft

Snapcraft requires a token passed via token:

{
  "tool": "login_provider",
  "arguments": {
    "provider_name": "snapcraft",
    "token": "snap-token-value"
  }
}

Servers and tools

Bugs — `ubuntu-mcp-bugs`

Tool	Description
`login_provider`	Authenticate with a bug data provider
`list_bug_providers`	List available bug data provider names
`get_bug`	Fetch a bug by ID
`search_bugs`	Search bugs by criteria
`submit_bug`	Submit a new bug

Resources:

ubq://bugs/providers — available bug data providers
ubq://bugs/sessions — active bug data provider sessions

`get_bug`

bug_id: str          — the bug ID
provider_name: str   — e.g. "launchpad" or "github"
metadata_only: bool  — set True to skip comments and tasks

`search_bugs`

provider_name: str          — e.g. "launchpad" or "github"
title: str | None           — filter by title substring
tags: list[str] | None      — filter by tags
status: str | None          — e.g. "New", "Fix Released"
importance: str | None      — e.g. "Medium", "High"
owner: str | None           — username of the bug owner
assignee: str | None        — username of the assignee
milestone: str | None       — milestone name
created_since: str | None   — ISO 8601 date (e.g. "2025-01-01")
created_before: str | None  — ISO 8601 date
modified_since: str | None  — ISO 8601 date

`submit_bug`

title: str                  — bug title (required)
provider_name: str          — e.g. "launchpad" or "github"
package_names: list[str]    — affected package names
description: str | None     — bug description
importance: str | None      — e.g. "Medium"
status: str | None          — e.g. "New"
tags: list[str] | None      — tags to apply
assignee: str | None        — username to assign
private: bool               — mark the bug private (default False)
milestone: str | None       — target milestone

Packages — `ubuntu-mcp-packages`

Tool	Description
`login_provider`	Authenticate with a package data provider
`list_package_providers`	List available package data provider names
`get_package`	Fetch a package by name

Resources:

ubq://packages/providers — available package data providers
ubq://packages/sessions — active package data provider sessions

`get_package`

package_name: str    — the source package name
provider_name: str   — e.g. "launchpad" or "snapcraft"

Versions — `ubuntu-mcp-versions`

Tool	Description
`login_provider`	Authenticate with a version data provider
`list_version_providers`	List available version data provider names
`get_version`	Fetch the version of a package in an Ubuntu series

Resources:

ubq://versions/providers — available version data providers
ubq://versions/sessions — active version data provider sessions

`get_version`

package_name: str    — the source package name
series: str          — Ubuntu codename (e.g. "noble", "jammy")
provider_name: str   — e.g. "launchpad" or "snapcraft"
pocket: str | None   — "Release", "Security", "Updates", "Proposed", or None for default

Merge Requests — `ubuntu-mcp-merge-requests`

Tool	Description
`login_provider`	Authenticate with a merge request provider
`list_merge_request_providers`	List available merge request provider names
`get_merge_request`	Fetch a merge request by ID
`get_merge_requests_from_user`	Fetch merge requests assigned to a user

Resources:

ubq://merge-requests/providers — available merge request providers
ubq://merge-requests/sessions — active merge request provider sessions

`get_merge_request`

merge_request_id: str  — the merge request ID
provider_name: str     — e.g. "launchpad" or "github"

`get_merge_requests_from_user`

user_id: str         — username
provider_name: str    — e.g. "launchpad" or "github"

Available providers

Provider	Domains
`launchpad`	Bugs, packages, versions, merge requests
`github`	Bugs, merge requests
`snapcraft`	Packages, versions

Development

uv sync                    # install all dependencies
uv run ruff check .         # lint
uv run pytest tests/ -v    # run tests

License

GPL-3.0

Available Tools

5 tools

get_bugA

Fetch a bug by ID from the given provider.

Set metadata_only to True to skip fetching comments and tasks.

ParametersJSON Schema

Name	Required	Description	Default
`bug_id`	Yes
`provider_name`	Yes
`metadata_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the 'metadata_only' flag behavior (skipping comments/tasks), but lacks details on authentication, error handling, rate limits, or effects of missing IDs. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no redundant words. Purpose and a key parameter option are conveyed efficiently. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (declared via context signals), the description need not detail return values. Parameter semantics are mostly covered. Missing usage guidelines and some behavioral details, but adequate for a simple fetch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 3 parameters with 0% coverage, so description must compensate. It explains 'metadata_only' clearly. 'bug_id' and 'provider_name' are implied in the action phrase, but format or valid values are not specified. Overall adds meaningful context beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'fetch', resource 'bug', and specifies retrieval by ID from a given provider. It effectively distinguishes from sibling tools like 'search_bugs' (which searches) and 'list_bug_providers' (which lists providers).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you have a bug ID and provider name, but it does not explicitly state when to use this tool versus alternatives like 'search_bugs' or 'submit_bug'. No guidance on when not to use it or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_bug_providersA

List all available bug data provider names.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The 'list' verb suggests a read-only operation, but the description does not elaborate on behavior like ordering, filtering, or side effects. Minimal disclosure beyond the obvious.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no unnecessary words. Efficient and appropriately sized for a simple listing tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and an output schema, the description is nearly complete. It names the output (provider names). Lacks mention of potential return format or ordering, but the output schema likely covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds no parameter-specific information, which is acceptable as baseline for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all available bug data provider names, which is specific and distinguishes it from sibling tools that deal with specific bugs or login.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives, but the simplicity and unique function (listing providers) makes usage implicit. Could benefit from context like 'Use this before searching or submitting bugs to reference provider names.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

login_providerA

Authenticate with a bug data provider (e.g. 'launchpad', 'github').

For Launchpad: provide a token directly, a credential file path containing the token, or omit both to authenticate anonymously.

ParametersJSON Schema

Name	Required	Description	Default
`provider_name`	Yes
`username`	No
`token`	No
`credential_file`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It mentions anonymous authentication but does not reveal potential side effects, session management, or error behaviors. Some behavioral context is provided, but additional details would be helpful for a mutation tool like login.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The first sentence immediately states the overall purpose, and the second provides specific usage details. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has an output schema (not shown) that likely covers return values. The description covers the main authentication modes. It does not discuss prerequisites or integration with sibling tools, but overall it provides sufficient context for a login tool of moderate complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It explains the purpose of 'token' and 'credential_file' parameters, adding meaning beyond type info. However, 'username' is left undocumented. The description partially bridges the gap, earning above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Authenticate with a bug data provider'. It uses a specific verb ('Authenticate') and resource ('bug data provider') with examples, distinguishing it from sibling tools like get_bug, list_bug_providers, which are about data retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on authentication modes for Launchpad, including when to provide a token, credential file, or omit both for anonymous access. It implies usage context but does not explicitly state when not to use the tool or mention alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_bugsB

Search for bugs matching criteria on the given provider.

Date arguments should be ISO 8601 format (e.g. '2025-01-01').

ParametersJSON Schema

Name	Required	Description	Default
`provider_name`	Yes
`title`	No
`tags`	No
`status`	No
`importance`	No
`owner`	No
`assignee`	No
`milestone`	No
`created_since`	No
`created_before`	No
`modified_since`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must carry the full behavioral disclosure. It only mentions date arguments but does not disclose whether the search is read-only, pagination behavior, required authentication, or what happens with no results. This is insufficient for a search tool with many parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with only two sentences, no redundant information. It is front-loaded with the main purpose and a key usage note. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (11 parameters, no schema descriptions, no annotations, output schema exists but not described), the description is incomplete. It misses critical details on criterion combination (AND/OR), sorting, pagination, and return structure. The agent may misinterpret how to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 11 parameters with 0% description coverage. The description only clarifies date format for date-related parameters, ignoring all other parameters like title, tags, status, etc. It adds minimal semantic value beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'search' and the resource 'bugs on a provider'. It is distinct from sibling tools: get_bug (single), list_bug_providers (list providers), login_provider (authentication), submit_bug (create). No ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a date format guideline but does not explain when to use this tool versus alternatives like get_bug (for a known bug) or submit_bug (to create). No explicit 'when not to use' guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit_bugC

Submit a new bug to the given provider.

Returns the created bug record, or None on failure.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`provider_name`	Yes
`package_names`	No
`description`	No
`importance`	No
`status`	No
`tags`	No
`assignee`	No
`private`	No
`milestone`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses that it returns the created bug record or None on failure, but provides no info on side effects (creation), required permissions, rate limits, or additional behavioral traits. Since annotations are absent, the description carries the full burden and falls short.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that state purpose and return value without redundancy. However, the extreme brevity omits critical parameter and usage details, which could be added without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters, 2 required, and zero parameter descriptions in either schema or description, the tool is severely underdocumented. The output schema exists but is not shown; the description does not fill the gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the 10 parameters (e.g., title, provider_name, importance). The agent gets no help understanding what each parameter means or how to use them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the verb 'Submit' and resource 'new bug', and the tool's action is distinct from siblings like get_bug or search_bugs. However, it does not specify what 'provider' means or how it relates to providers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites (e.g., requires login via login_provider), and no conditions for success or failure beyond the return value.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0May 13, 2026
- First observedget_bug
- First observedlist_bug_providers
- First observedlogin_provider
- First observedsearch_bugs
- First observedsubmit_bug

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-05-13 13:25 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: listing providers, authentication, searching, fetching by ID, and submitting. No overlaps or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscore separation (e.g., get_bug, list_bug_providers, login_provider, search_bugs, submit_bug).

Tool Count5/5

Five tools cover the essential bug tracking workflow without being excessive or insufficient for a focused server.

Completeness4/5

Basic operations (list, auth, search, get, create) are present, but update and delete/close operations are missing, leaving minor gaps in full lifecycle management.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111
MCP Verify B
io.sentinelsignal
Trust, freshness, policy, and discovery layer for public MCP servers.
Agent Orchestration Developer Tools Testing & QA Tools
222
Muninx MCP Server AOAuth
com.muninx
Remote MCP server for managing Muninx tickets, messages, ticket search, and support analytics.
Customer Support Project Management
2
SupabaseOAuth
com.supabase
MCP server for interacting with the Supabase platform
Cloud Platforms Databases Developer Tools
32,908

Related MCP Servers

poly-git-mcp
Version Control CI/CD & DevOps Developer Tools
Grifex-0
F
license
Not graded
quality
C
maintenance
Unified MCP server for Git forge management across GitHub, GitLab, Gitea, and Bitbucket, enabling repository, issue, PR, and CI/CD operations via CLI tools and APIs.
Updated 3 months ago (2026-06-16 13:16 UTC)
-
quads-mcp
Cloud Platforms Virtualization
grafuls
A
license
Not graded
quality
D
maintenance
MCP server for interacting with QUADS infrastructure systems via API, enabling resource management and automation through LLM applications.
Updated a year ago (2025-07-10 11:07 UTC)
MIT
space-mcp
Version Control CI/CD & DevOps
bindreams
F
license
A
quality
C
maintenance
MCP server for JetBrains Space merge requests and Patronus CI dry runs, enabling creation, viewing, and management of merge requests as well as starting and monitoring CI dry runs.
Updated 2 months ago (2026-07-10 16:12 UTC)
16
-
Launchpad MCP Server
Project Management Search
bnbhat
F
license
Not graded
quality
B
maintenance
Read-only MCP server that exposes Launchpad bug-tracking data for a single project to AI agents, enabling search and retrieval of bugs, milestones, and comments with canonical URLs.
Updated 3 months ago (2026-06-28 21:54 UTC)
-

Ubuntu MCP Servers

Requirements

Installation

Running a server

Running all servers

Connecting an MCP client

Authentication

Launchpad

Anonymous (no credentials)

Credential file

Inline token

GitHub

Snapcraft

Servers and tools

Bugs — ubuntu-mcp-bugs

get_bug

search_bugs

submit_bug

Packages — ubuntu-mcp-packages

get_package

Versions — ubuntu-mcp-versions

get_version

Merge Requests — ubuntu-mcp-merge-requests

get_merge_request

get_merge_requests_from_user

Available providers

Development

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Bugs — `ubuntu-mcp-bugs`

`get_bug`

`search_bugs`

`submit_bug`

Packages — `ubuntu-mcp-packages`

`get_package`

Versions — `ubuntu-mcp-versions`

`get_version`

Merge Requests — `ubuntu-mcp-merge-requests`

`get_merge_request`

`get_merge_requests_from_user`