What can you do with this server?

The MCP System Bridge server provides cross-platform tools to interact with the operating system: * Open URLs: Launch one or multiple URLs in the default web browser * Clipboard Management: Copy text directly to the system clipboard * Date & Time Information: Retrieve comprehensive date/time details including ISO 8601 formats, Unix timestamps, week numbers, quarter information, leap year status, and time components * System Notifications: Send native system notifications across Windows, macOS, and Linux with customizable title, message, and app name All operations are designed as safe, read-only tools for system integration through the Model Context Protocol.

Which integrations are available for this server?

Provides a tool runner called 'uvx' which is part of the uv package manager from Astral, used for running the MCP server.

How do I use MCP System Bridge?

1. Click on "Install 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., "@MCP System Bridge open https://github.com/leynier/mcp-sys-bridge" 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.

MCP System Bridge

by leynier

Overview Schema Related Servers Score Discussions

Python

Local

MCP System Bridge

License: MIT Version Tests

mcp-sys-bridge is a local Model Context Protocol (MCP) server that lets MCP clients open web URLs, copy text to the clipboard, send native notifications, and inspect the local date and time.

Installation

The server requires Python 3.12 or newer and runs directly with uvx. Add it to your MCP client configuration:

{
  "mcpServers": {
    "mcp-sys-bridge": {
      "command": "uvx",
      "args": ["mcp-sys-bridge"]
    }
  }
}

It can also be started manually:

uvx mcp-sys-bridge

For a local checkout, use either entry point after uv sync:

uv run mcp-sys-bridge
uv run python -m mcp_sys_bridge

Related MCP server: Command Executor MCP Server

Available tools

`open_urls`

Opens HTTP or HTTPS URLs in the default browser. URLs without a scheme use HTTPS. Other schemes are rejected so an MCP client cannot accidentally invoke arbitrary protocol handlers.

The tool preserves input order and duplicates. Each requested URL receives its own result:

[
  {
    "requested_url": "example.com:8080/docs",
    "normalized_url": "https://example.com:8080/docs",
    "opened": true,
    "error": null
  }
]

An invalid URL or browser failure does not stop the rest of the batch.

`copy_to_clipboard`

Copies the provided text to the local clipboard. This replaces the current clipboard contents. Provider failures are returned to the client as MCP tool errors.

`send_notification`

Sends a local system notification with a title, message, optional application name, and a non-negative timeout. Provider failures are returned as MCP tool errors. Some operating systems may ignore the requested timeout.

`get_current_date_info`

Returns local calendar and clock fields, including ISO calendar values, English day and month names, timezone name, and UTC offset. iso_datetime is timezone-aware, for example 2026-08-08T20:30:00-06:00.

Platform notes

Windows and macOS normally provide the required browser, clipboard, and notification integrations.
Linux requires an active graphical session and compatible system providers. Clipboard support may require wl-clipboard, xclip, or xsel, depending on the session; desktop notifications typically require a working notification service and D-Bus integration.
Clipboard and notification tools are expected to fail cleanly in headless sessions where those providers are unavailable.
MCP annotations identify URL opening, clipboard writes, and notifications as side effects so compatible clients can apply their normal confirmation policy.

Development

make tests   # Ruff plus tests with 100% line and branch coverage
make audit   # Audit the locked environment for known vulnerabilities
make build   # Build the wheel and source distribution

Tests mock browser, clipboard, and notification calls; they do not modify the developer's desktop state.

Changelog

0.2.0

Changed open_urls to return ordered structured results and restricted it to HTTP/HTTPS.
Corrected MCP side-effect annotations and MCP error reporting.
Made date-time output timezone-aware and added timezone metadata.
Renamed the import package from src to mcp_sys_bridge.
Added functional tests, dependency auditing, cross-platform CI, and OIDC-based publishing.

src.* imports and the dictionary result previously returned by open_urls are not compatible with 0.2.0. The documented mcp-sys-bridge command remains unchanged.

0.1.5

Added the cross-platform send_notification tool.

0.1.4

Added tool annotations.

0.1.3

Added get_current_date_info.

0.1.2

Changed open_url to open_urls for batch URL opening.

0.1.0

Added URL opening and clipboard support.

License

MIT License. See license.

Available Tools

4 tools

copy_to_clipboardD

Read-only

Copy text to the clipboard.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

TDQS

D1.9/5.0

Behavior1/5

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

The description states a write operation ('copy to clipboard'), but annotations set readOnlyHint=true, which is a clear contradiction. No additional behavioral traits are disclosed beyond this inconsistency.

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

Conciseness3/5

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

The description is very short and front-loaded, but the single sentence provides minimal value. It is concise but lacks substance.

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?

For a simple clipboard tool, the description omits important context such as that it replaces current clipboard content or scope limitations (e.g., system vs. browser). Incomplete given the lack of output schema and parameter description.

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?

Schema description coverage is 0%, and the description does not explain the 'text' parameter beyond its name and type from the schema. No guidance on text format, limitations, or effect.

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

Purpose2/5

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

The description 'Copy text to the clipboard.' essentially restates the tool name 'copy_to_clipboard' without adding new information. It is a tautology and does not differentiate from siblings, though siblings are unrelated.

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 or any prerequisites. The description lacks any context about appropriate usage scenarios.

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

get_current_date_infoA

Read-only

Get comprehensive information about the current date.

Returns:
    DateInfo: A dictionary containing comprehensive date and time information:
        - full_datetime (str): Full date and time in YYYY-MM-DD HH:MM:SS format
        - iso_date (str): ISO 8601 date format (YYYY-MM-DD)
        - iso_datetime (str): ISO 8601 datetime format with timezone
        - timestamp (int): Unix timestamp (seconds since epoch)
        - year (int): Current year (e.g., 2024)
        - month (int): Current month (1-12)
        - day (int): Current day of the month (1-31)
        - day_of_year (int): Day number in the year (1-366)
        - day_of_week_number (int): Day of the week (0=Monday, 6=Sunday)
        - day_name (str): Full name of the day (e.g., "Monday")
        - day_name_short (str): Short name of the day (e.g., "Mon")
        - month_name (str): Full name of the month (e.g., "January")
        - month_name_short (str): Short name of the month (e.g., "Jan")
        - is_leap_year (bool): True if current year is a leap year
        - week_number (int): ISO 8601 week number (1-53)
        - iso_year (int): ISO 8601 year (may differ from calendar year)
        - weekday_iso (int): ISO weekday (1=Monday, 7=Sunday)
        - quarter (int): Quarter of the year (1-4)
        - days_in_month (int): Total days in the current month
        - hour (int): Current hour (0-23)
        - minute (int): Current minute (0-59)
        - second (int): Current second (0-59)
        - microsecond (int): Current microsecond (0-999999)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true. The description adds value by listing return fields but does not disclose behaviors beyond that (e.g., caching, timezone source). With annotations, the bar is higher; description does not enrich beyond the read-only nature.

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?

Purpose sentence is front-loaded. The extensive list of return fields is informative but somewhat verbose. Could be more concise, but structure is clear.

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

Completeness5/5

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

For a zero-parameter informational tool with annotations, the description thoroughly explains all return values. No output schema exists, so the description fulfills completeness.

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, and input schema is empty with 100% coverage. Description does not need to add parameter info; baseline 4 applies.

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 'Get comprehensive information about the current date' with a specific verb and resource. Siblings are entirely different (clipboard, URLs, notifications), so no confusion.

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?

No explicit 'when to use' or alternatives mentioned, but the tool is self-explanatory and siblings are unrelated, so usage context is clear implicitly.

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

open_urlsC

Read-only

Open a list of URLs in the default browser.

ParametersJSON Schema

Name	Required	Description	Default
`urls`	Yes

TDQS

C2.7/5.0

Behavior1/5

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

The description contradicts the readOnlyHint annotation; opening URLs in browser is a side effect, not read-only. No additional behavioral context.

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

Conciseness3/5

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

Single sentence is concise but too minimal; could expand slightly without verbosity.

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?

Lacks details on error handling, behavior on empty list, whether it opens in new tabs, etc. Incomplete for a one-parameter tool.

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?

0% schema description coverage, and the description only mentions 'URLs' without specifying format, protocol, or behavior for invalid URLs.

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?

States clearly that the tool opens a list of URLs in the default browser, with a specific verb and resource. Different from siblings (clipboard, date, notification).

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 vs alternatives, no exclusions or context provided.

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

send_notificationA

Read-only

Send a system notification.

Displays a native operating system notification with the specified title and message.
Works across Windows, macOS, and Linux platforms.

Args:
    title: The title of the notification (required)
    message: The message body of the notification (required)
    app_name: The name of the application sending the notification (optional)
    timeout: Duration in seconds to display the notification (default: 10)

Returns:
    A success message if the notification was sent successfully, or an error message if it failed.

Examples:
    send_notification("Task Complete", "Your build has finished successfully")
    send_notification("Warning", "Low disk space detected", app_name="System Monitor", timeout=5)

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`message`	Yes
`app_name`	No
`timeout`	No

TDQS

A3.5/5.0

Behavior1/5

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

The description indicates a write operation ('Send', 'Displays') but the annotation declares readOnlyHint=true, creating a contradiction. No other behavioral traits (e.g., permissions, failure modes) are disclosed beyond the annotation's misalignment.

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?

The description is well-structured with Args, Returns, and Examples sections, making it easy to parse. It is slightly verbose with repeated info (e.g., 'required' in Args), but overall concise relative to the content provided.

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

Completeness3/5

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

The description covers purpose, parameters, return value, and examples, which is adequate for a simple notification tool. However, it lacks error handling details and behavioral context, partly due to the annotation contradiction, reducing completeness.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by explaining each parameter's role (e.g., 'title of the notification', 'message body', 'name of the application', 'Duration in seconds'). It adds defaults and examples, providing rich semantics beyond the schema's bare types.

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 'Send a system notification' and 'Displays a native operating system notification', providing a specific verb and resource with cross-platform context. It is distinct from sibling tools like copy_to_clipboard, open_urls, etc.

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 for sending notifications but does not explicitly state when to use this tool versus alternatives or provide exclusions. Sibling tools are distinct, so ambiguity is low, but no direct guidance is given.

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. Dates show when Glama detected each change.

1 tool updatev1.0.0Jan 2, 2026
- Addedsend_notification
3 tool updatesAug 15, 2025
- First observedcopy_to_clipboard
- First observedget_current_date_info
- First observedopen_urls

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3/5.0

Disambiguation5/5

Each tool has a completely distinct purpose: clipboard text, current date/time, opening URLs, and sending notifications. No overlap or ambiguity.

Naming Consistency4/5

All names use snake_case and start with verbs, but the structure varies slightly (e.g., 'copy_to_clipboard' vs 'get_current_date_info' vs 'open_urls'). Mostly consistent.

Tool Count4/5

Four tools is a bit low for a 'system bridge' but still reasonable for a focused set covering common system interactions. Could be expanded slightly without feeling overwhelming.

Completeness3/5

The set covers clipboard, date/time, URL opening, and notifications, but misses obvious complementary operations like reading clipboard or more system info. There are noticeable gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Mercado PagoOAuth
com.mercadopago.mcp
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Finance E-commerce & Retail App Automation
2
Remote MCP A
com.remote-mcp.mcp
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Developer Tools Search Agent Orchestration
13
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

MCP Personal Assistant Agent
Calendar Management App Automation Home Automation & IoT
zhangzhongnan928
F
license
Not graded
quality
D
maintenance
A versatile Model Context Protocol server that enables AI assistants to manage calendars, track tasks, handle emails, search the web, and control smart home devices.
Updated 2 years ago (2025-03-04 06:13 UTC)
23
-
Command Executor MCP Server
Shell Access Code Execution Command Line
Sunwood-ai-labs
A
license
B
quality
D
maintenance
A Model Context Protocol server that allows secure execution of pre-approved commands, enabling AI assistants to safely interact with the user's system.
Updated 2 years ago (2024-12-22 05:16 UTC)
1
8
22
ISC
MCP Tools
Shell Access File Systems
ZbigniewTomanek
A
license
Not graded
quality
D
maintenance
A custom Model Context Protocol server that gives Claude Desktop and other LLMs access to file system operations and command execution capabilities through standardized tool interfaces.
Updated a year ago (2025-04-16 09:10 UTC)
23
Apache 2.0
MCP Toolkit
File Systems Databases Version Control
zxfgds
A
license
Not graded
quality
D
maintenance
A comprehensive Model Context Protocol server implementation that enables AI assistants to interact with file systems, databases, GitHub repositories, web resources, and system tools while maintaining security and control.
Updated 2 years ago (2025-03-04 13:13 UTC)
81
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/leynier/mcp-sys-bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server