How do I use mcp-mdns?

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-mdns List all HTTP services on my network" 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-mdns

by daedalus

Overview Schema Related Servers Score Discussions

Python

Local

mcp-mdns — MCP server for mDNS service discovery

PyPI Python Ruff

MCP server that exposes mDNS (Multicast DNS) service discovery functionality via the Model Context Protocol. Enables LLMs to discover and query zero-configuration network services on the local network.

mcp-name: io.github.daedalus/mcp-mdns

Install

pip install mcp-mdns

Related MCP server: @lex-tools/codebase-context-dumper

Usage

# Run the MCP server
mcp-mdns

Or run directly with Python:

python -m mcp_mdns

MCP Server Configuration

Configure your MCP client with:

{
  "mcpServers": {
    "mdns": {
      "command": "mcp-mdns",
      "env": {}
    }
  }
}

Available Tools

mdns_list_service_types — List all service types advertised on the local network
mdns_browse_services — Browse for services of a specific type (e.g., _http._tcp, _printer._tcp)
mdns_get_service_info — Get detailed information about a specific service (host, port, TXT records)
mdns_resolve_hostname — Resolve a .local hostname to IP addresses
mdns_register_service — Register a new service on the local network
mdns_unregister_service — Unregister a previously registered service

Development

git clone https://github.com/daedalus/mcp-mdns.git
cd mcp-mdns
pip install -e ".[test]"

# run tests
pytest

# format
ruff format src/ tests/

# lint
ruff check src/ tests/

# type check
mypy src/

License

MIT

Available Tools

6 tools

mdns_browse_servicesA

Read-onlyIdempotent

Browse for services of a specific type on the local network.

This tool searches for all services matching a given type (e.g., _http._tcp, _printer._tcp). It returns the names of all discovered services that can be used with mdns_get_service_info to retrieve detailed information.

Args: params (BrowseServicesInput): Validated input parameters containing: - service_type (str): Service type to search for (e.g., '_http._tcp') - timeout (Optional[float]): Query timeout in seconds (default: 5.0) - response_format (ResponseFormat): Output format preference

Returns: str: List of discovered services or error message

Example: >>> mdns_browse_services(BrowseServicesInput(service_type="_http._tcp", timeout=5.0)) "# Services of Type: _http._tcp\n\nFound 1 service(s):\n\n- My Server._http._tcp.local."

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it returns a list of discovered services and provides an example output, but does not elaborate on network dependencies or variability beyond the openWorldHint.

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-organized with sections (intro, Args, Returns, Example), but the first two sentences are redundant, and the Args section largely duplicates the schema, making it slightly longer than necessary.

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 description covers the tool's purpose, parameters, return value (with example), and relationship to a sibling tool. It does not discuss error conditions or network prerequisites, but for a browse tool this is adequate.

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

Parameters3/5

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

The input schema already contains detailed descriptions for all parameters (service_type, timeout, response_format), so the description's 'Args' section adds minimal new information beyond restating the 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 uses a specific verb ('browse') and resource ('services of a specific type') and differentiates from sibling tools by mentioning that the results can be used with mdns_get_service_info for details, distinguishing it from related tools like mdns_list_service_types.

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 clearly states when to use the tool (to browse for services of a given type) and implies that mdns_get_service_info is for detailed info, but does not explicitly exclude other use cases or provide guidance on when not to use it.

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

mdns_get_service_infoA

Read-onlyIdempotent

Get detailed information about a specific mDNS service.

This tool retrieves complete information about a discovered service including:

Hostname and IP addresses
Port number
TXT records (metadata)
Service type and name

Args: params (ServiceInfoInput): Validated input parameters containing: - service_type (str): Service type (e.g., '_http._tcp.local.') - service_name (str): Full service name from browse results - timeout (Optional[float]): Query timeout in seconds (default: 10.0) - response_format (ResponseFormat): Output format preference

Returns: str: Detailed service information or error message

Example: >>> mdns_get_service_info(ServiceInfoInput(service_type="_http._tcp", service_name="My Server._http._tcp.local.")) "# Service: My Server._http._tcp.local.\n\nType: _http._tcp.local.\nServer: myserver.local\nPort: 8080\nAddresses: 192.168.1.100"

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint=false. Description adds context that it retrieves 'complete information' with specific fields. No contradictions. Could mention network/timeout behavior but annotations cover safety.

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?

Description is well-structured with purpose first, then details, then args, then example. Slightly verbose with full Args section and example, but every part adds value. Could be trimmed but still good.

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 read tool, description covers input parameters, return value (string with markdown example), and usage example. Annotations provide safety profile. Output schema not in input but described in text. Fairly complete given tool 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 provides full descriptions for all parameters (service_type, service_name, timeout, response_format). Description includes a clear 'Args' section that restates and slightly augments (e.g., default timeout 10.0). Adds value by summarizing parameter purpose beyond schema, even though schema coverage is high.

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?

Description clearly states 'Get detailed information about a specific mDNS service' and lists specific data items (hostname, IP, port, TXT records). Distinguishes from sibling tools like mdns_browse_services (listing) and mdns_register_service (write operation).

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?

Description implies use after browsing (service name from browse results) but does not explicitly state when to use vs alternatives or when not to. No exclusions or alternative tool mentions. Usage context is implied but not explicit.

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

mdns_list_service_typesA

Read-onlyIdempotent

List all service types advertised on the local network via mDNS.

This tool queries the local network for all advertised mDNS service types. Common service types include _http._tcp (web servers), _printer._tcp (printers), _airplay._tcp (Apple TV), _smb._tcp (SMB shares), and many others.

Args: params (ServiceTypeInput): Validated input parameters containing: - timeout (Optional[float]): Query timeout in seconds (default: 5.0) - response_format (ResponseFormat): Output format preference

Returns: str: Formatted list of discovered service types or error message

Example: >>> mdns_list_service_types(ServiceTypeInput(timeout=5.0, response_format=ResponseFormat.MARKDOWN)) "# mDNS Service Types\n\nFound 3 service type(s):\n\n- _http._tcp\n- _printer._tcp\n- _airplay._tcp"

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false. The description adds that it queries the local network and uses a timeout, with no contradictions.

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 a clear verb and resource first, followed by details. The example is helpful but adds length; still concise enough.

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?

Given the annotations (read-only, idempotent) and presence of an output schema, the description is complete: it explains what the tool does, its parameters, and provides an example output, making it fully actionable.

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?

The description explains both parameters (timeout and response_format) including defaults and example usage. Although the input schema also has descriptions, the description adds value by clarifying defaults and the example output.

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 service types advertised via mDNS, and the example with common types distinguishes it from sibling tools like mdns_browse_services or mdns_get_service_info.

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 indicates when to use (to list mDNS service types) and implies context (local network), but does not explicitly state when not to use or suggest alternatives, though sibling names provide that context.

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

mdns_register_serviceA

This tool registers a service so other devices on the network can discover it. The service will be advertised with the specified type, port, and optional TXT records.

Args: params (RegisterServiceInput): Validated input parameters containing: - name (str): Service name (e.g., 'My Web Server') - service_type (str): Service type (e.g., '_http._tcp') - port (int): Port number - host (Optional[str]): Host IP (auto-detected if not provided) - text_records (Optional[Dict[str, str]]): TXT record key-value pairs

Returns: str: Registration result or error message

Example: >>> mdns_register_service(RegisterServiceInput(name="MyServer", service_type="_http._tcp", port=8080)) "Successfully registered service: MyServer._http._tcp.local. on port 8080"

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations provide readOnlyHint=false and destructiveHint=false. The description adds that the service will be advertised and host auto-detection is attempted. It does not contradict annotations and adds useful behavioral context beyond them.

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 a clear purpose sentence, an Args section, returns note, and example. It is front-loaded and reasonably concise, though the Args section could be trimmed without losing value.

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 tool has a nested parameter object and output schema exists, the description covers registration parameters, return value, and includes an example. It lacks error conditions or network constraints, but is fairly complete for the complexity level.

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

Parameters3/5

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

The input schema already provides descriptions for all parameters (name, service_type, port, host, text_records). The description repeats these in an Args section but adds minimal new meaning beyond summarizing them. With high schema coverage, baseline score of 3 is appropriate.

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 'Register a new service on the local network via mDNS' and 'registers a service so other devices on the network can discover it'. The verb 'register' is specific and distinct from sibling tools like mdns_browse_services, mdns_unregister_service, 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 registering mDNS services but does not explicitly state when to use versus alternatives, prerequisites like network permissions, or when not to use. No direct alternative mentions.

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

mdns_resolve_hostnameA

Read-onlyIdempotent

Resolve an mDNS hostname (.local) to IP addresses.

This tool resolves a local network hostname (ending in .local) to its IP address(es). This is useful for finding the IP address of devices that don't have static IPs but have registered with mDNS/Bonjour.

Args: params (ResolveHostnameInput): Validated input parameters containing: - hostname (str): Hostname to resolve (e.g., 'mydevice.local') - timeout (Optional[float]): Query timeout in seconds (default: 5.0) - response_format (ResponseFormat): Output format preference

Returns: str: Resolved IP addresses or error message

Example: >>> mdns_resolve_hostname(ResolveHostnameInput(hostname="raspberrypi.local", timeout=5.0)) "# Resolution: raspberrypi.local\n\nIP Address: 192.168.1.50"

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, etc. The description adds behavioral context such as .local suffix requirement and default timeout, which is consistent with annotations. No contradictions.

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 concise, well-structured with Args, Returns, and Example sections. Every sentence is necessary and adds value without redundancy.

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 simple tool with one required parameter, the description covers all necessary aspects: purpose, parameters, return format, and an example. The output schema is implied and sufficient.

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?

The input schema provides descriptions for all parameters, so schema description coverage is high. The description adds value with examples and default values, enhancing understanding beyond the 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 tool resolves .local hostnames to IP addresses, specifying the exact resource and action. It distinguishes from sibling tools that handle service browsing or registration, as this is solely for hostname resolution.

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 explains it is useful for finding IPs of mDNS-registered devices without static IPs, but does not explicitly state when not to use it or mention alternatives. The context from sibling tools partially covers this.

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

mdns_unregister_serviceA

DestructiveIdempotent

Unregister a previously registered mDNS service.

This tool removes a service from the local network, stopping its advertisement.

Args: params (UnregisterServiceInput): Validated input parameters containing: - service_name (str): Service name to unregister

Returns: str: Unregistration result or error message

Example: >>> mdns_unregister_service(UnregisterServiceInput(service_name="MyServer._http._tcp.local.")) "Successfully unregistered service: MyServer._http._tcp.local."

ParametersJSON Schema

Name	Required	Description	Default
`params`	Yes

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?

The description adds context that the tool removes and stops advertisement, aligning with the destructiveHint annotation. However, it does not elaborate on potential side effects, error conditions, or permission requirements beyond what annotations already convey.

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 sections for purpose, arguments, returns, and an example. It is concise, though the Args section repeats information already present in the input schema.

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 simple tool with one parameter, the description covers purpose, usage, parameter details, return value, and provides an example. It is contextually complete given the tool's low complexity and the presence of annotations.

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?

With schema description coverage at 0%, the description compensates by explicitly listing the parameter (service_name) with type and a clear example. This adds meaningful semantic value beyond the schema's minimal description.

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 uses a specific verb 'unregister' and identifies the resource as 'mDNS service', clearly distinguishing it from sibling tools like mdns_register_service (opposite) and mdns_browse_services (browsing). It explains the effect of removing the service and stopping its advertisement.

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 implies usage for removing previously registered services, which is a clear context. However, it does not explicitly state when not to use the tool or provide alternatives, but the sibling tool names are available for context.

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.

6 tool updatesv0.1.2May 30, 2026
- First observedmdns_browse_services
- First observedmdns_get_service_info
- First observedmdns_list_service_types
- First observedmdns_register_service
- First observedmdns_resolve_hostname
- First observedmdns_unregister_service

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a distinct purpose: browsing services, getting service info, listing service types, registering, unregistering, and resolving hostnames. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow the consistent pattern 'mdns_verb_noun' (e.g., mdns_browse_services, mdns_register_service). The naming is perfectly uniform and predictable.

Tool Count5/5

With 6 tools, the server covers the core mDNS operations without being too few or too many. Each tool earns its place for a focused networking utility.

Completeness4/5

The tool set covers browsing, querying, registration, and hostname resolution. Missing an update tool for registered services, but this is a minor gap; core workflows are well-supported.

Maintenance

ActivityInactive

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

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
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
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

mcp-llm
Code Execution Autonomous Agents
sammcj
A
license
B
quality
C
maintenance
An MCP server that provides LLMs access to other LLMs
Updated a year ago (2025-03-15 05:37 UTC)
4
48
78
MIT
@lex-tools/codebase-contextofficial
Code Analysis Developer Tools Documentation Access
lex-tools
A
license
A
quality
D
maintenance
A Model Context Protocol (MCP) server designed to easily dump your codebase context into Large Language Models (LLMs).
Updated a year ago (2025-08-02 06:43 UTC)
1
12
3
Apache 2.0
FastMCP
RAG Systems Developer Tools
Dev00355
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that bridges MCP clients with local LLM services, enabling seamless integration with MCP-compatible applications through standard tools like chat completion, model listing, and health checks.
Updated a year ago (2025-08-03 11:53 UTC)
-
mcp-cli-catalog
Shell Access
abcpro1
A
license
Not graded
quality
D
maintenance
An MCP server that publishes CLI tools on your machine for discoverability by LLMs
Updated 10 months ago (2025-11-16 20:50 UTC)
14
1
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/daedalus/mcp-mdns'

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

mcp-mdns — MCP server for mDNS service discovery

Install

Usage

MCP Server Configuration

Available Tools

Development

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@lex-tools/codebase-contextofficial

Latest Blog Posts

MCP directory API