How do I use localsend-mcp?

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., "@localsend-mcp discover nearby devices and send the PDF to my phone" 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.

localsend-mcp

by Aaradhya-Dev-Tamrakar

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

LocalSend MCP Server (`localsend-mcp`)

License: MIT Runtime: Node.js 22+ Protocol: LocalSend v2.1

A high-performance, zero-external-dependency Model Context Protocol (MCP) server that connects AI assistants (Google Antigravity, Claude Desktop, Cursor) directly to physical devices across your local Wi-Fi / LAN using the LocalSend protocol.

⚡ Key Capabilities

Bidirectional Local P2P Sharing:
- Outbound (AI Agent $\rightarrow$ Device): Deliver generated artifacts, code files, research papers, and images directly to smartphones, tablets, and laptops.
- Inbound (Device $\rightarrow$ AI Agent): Send photos, voice memos, logs, or documents from your phone directly into the agent's download folder.
Direct Text & Clipboard Push: Send code snippets, terminal commands, or notes straight to target devices without writing temporary files to disk.
LAN Auto-Discovery: Finds active LocalSend peers via UDP multicast (224.0.0.167:53317) and catches HTTP registration handshakes.
Desktop App Co-existence: Runs a persistent background listener on port 53318 so both the official LocalSend desktop application (53317) and this MCP server run seamlessly together on the same machine.
Clean LocalSend Favoriting: Actively responds to POST /api/localsend/v2/register with 200 OK, allowing mobile and desktop LocalSend apps to favorite/star the agent without connection errors.
In-Process X.509 Cryptography: Generates TLS keys and ASN.1 DER certificates purely in-memory using Node.js crypto—no external openssl binary required on Windows, Linux, or macOS.

Related MCP server: filesystem-mcp

🛠️ MCP Tools Exposed

Tool	Parameters	Description
`localsend_devices`	`timeoutSeconds` (opt)	Scans the Wi-Fi/LAN for online LocalSend peers, returning their alias, IP, port, and device model.
`localsend_send`	`to` (req), `files` (opt), `text` (opt), `pin` (opt)	Sends files, directories, or direct text snippets to a peer by alias or IP.
`localsend_status`	none	Displays local network IPs, active listening port, fingerprint, and inbox statistics.
`localsend_history`	none	Lists files received into the agent's download directory.
`localsend_setup`	`alias` (opt), `downloadDir` (opt)	Configures the broadcast alias, auto-save directory, and transport protocol.

🚀 Installation & Build

cd F:\Aaradhya-Dev-Tamrakar\localsend-mcp

# Install dependencies
npm install

# Compile TypeScript to dist/
npm run build

🔄 Automated Git Synchronization (`sync.ps1`)

The repository includes a dedicated PowerShell synchronization script that enforces pre-commit secret scans, automatically recompiles TypeScript when source files change, and formats conventional commits:

# Routine build, commit, and push
.\sync.ps1

# Custom commit message
.\sync.ps1 -m "feat(localsend): add automatic clipboard sync"

# Safe rebase pull only
.\sync.ps1 -PullOnly

# Dry-run mode (preview without changing git state)
.\sync.ps1 -WhatIf

⚙️ Configuration

Antigravity (`mcp_servers` configuration)

Add localsend-mcp to your Antigravity MCP settings:

{
  "mcpServers": {
    "localsend": {
      "command": "node",
      "args": ["F:\\Aaradhya-Dev-Tamrakar\\localsend-mcp\\dist\\index.js"]
    }
  }
}

Claude Desktop (`claude_desktop_config.json`)

{
  "mcpServers": {
    "localsend": {
      "command": "node",
      "args": ["F:\\Aaradhya-Dev-Tamrakar\\localsend-mcp\\dist\\index.js"]
    }
  }
}

🧪 Usage Examples

1. Discover Devices on LAN

{
  "name": "localsend_devices",
  "arguments": {
    "timeoutSeconds": 3
  }
}

2. Send an Artifact or Report to Your Phone

{
  "name": "localsend_send",
  "arguments": {
    "to": "V2029",
    "files": ["F:\\Aaradhya-Dev-Tamrakar\\brainstorm\\report\\main.pdf"]
  }
}

3. Push a Code Snippet Directly to Clipboard

{
  "name": "localsend_send",
  "arguments": {
    "to": "SFG16",
    "text": "Get-Process localsend_app | Select-Object Id, ProcessName",
    "textFileName": "inspect.ps1"
  }
}

4. Check Inbox for Files Sent From Mobile

{
  "name": "localsend_history",
  "arguments": {}
}

🔒 Security & Privacy

100% Local: No internet connection, cloud servers, or third-party relays are used. All network packets stay strictly within your local subnet.
Mutual TLS (mTLS): All transfers use TLS encryption with client certificate presentation matching the LocalSend v2 specification.
Path Traversal Protection: Remote file names are sanitized to prevent directory traversal attacks.

📄 License

MIT © Aaradhya Dev Tamrakar

Available Tools

5 tools

localsend_devicesA

Scan the local Wi-Fi/LAN for active LocalSend devices and list their aliases, IPs, and models.

ParametersJSON Schema

Name	Required	Description	Default
`timeoutSeconds`	No	How many seconds to scan for LAN devices. Default 3, max 30.

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 the full behavioral disclosure burden. It accurately conveys the scan-and-list behavior, but it does not mention potential nuances like network permissions, how long the scan may take, or what happens when no devices are found. This is adequate but not richly transparent.

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?

A single, front-loaded sentence that states the action, scope, and returned information with no filler. Every word contributes 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?

For a simple discovery tool with one optional parameter and no output schema, the description is nearly complete. It tells the agent what the tool does and what it returns; the only minor gap is not stating that scanning can consume up to timeoutSeconds, though the schema already covers that.

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?

Schema description coverage is 100%, so the input schema already documents timeoutSeconds with default and max values. The tool description adds no additional parameter meaning beyond what the schema provides, matching the baseline expectation.

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 states a specific verb ('Scan'), a precise resource ('local Wi-Fi/LAN'), and the exact output ('aliases, IPs, and models'). This clearly distinguishes the tool from siblings like localsend_send, localsend_status, localsend_history, and localsend_setup, all of which serve different purposes.

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 establishes clear context: use this tool to discover active LocalSend devices on the network. Though it does not explicitly say 'use before sending' or name when not to use it, the sibling names make the intended role obvious.

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

localsend_historyA

List incoming files received by the LocalSend MCP server inbox.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/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 the behavioral transparency burden. It indicates a read-only listing operation, but it does not detail the output format, ordering, retention, or whether listed files remain in inbox.

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?

A single, front-loaded sentence with no waste: it states the action and object clearly. Every word contributes to understanding.

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 tool has zero parameters, no annotations, and no output schema, the description is sufficient for an agent to select and invoke it correctly. 'List incoming files' adequately conveys the expected result.

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 tool has zero parameters and schema coverage is 100%, so description need not add parameter detail. Baseline for zero-param tool is 4; description correctly focuses on behavior.

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 the specific verb 'List' with a clear resource: 'incoming files received by the LocalSend MCP server inbox.' This makes the tool's function obvious and distinguishes it from sibling tools like localsend_send or localsend_devices.

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 when to use this tool (to retrieve incoming file history) and its action is distinct from siblings, but it does not explicitly state when to prefer it over alternatives or mention any exclusions.

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

localsend_sendA

Send files, folders, or direct text/clipboard snippets to a LocalSend device on LAN by alias or IP.

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Target device alias (e.g. 'SFG16' or 'iPhone') or IP address (e.g. '192.168.1.11').
`pin`	No	PIN if requested by receiving device.
`port`	No	Custom port if sending directly to IP (default 53317).
`text`	No	Text snippet, note, or code to send directly as a text transfer.
`files`	No	List of absolute or relative file or folder paths to send.
`protocol`	No	Transport protocol (default: 'https').
`textFileName`	No	Optional filename for text snippet (default: 'note.txt').
`timeoutSeconds`	No	Timeout waiting for recipient to accept in seconds (default 60).

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the basic action but omits important behavioral aspects: that the operation waits for recipient acceptance (timeout), may require a PIN, uses a default port/protocol, and could fail if the device is unreachable. The description does not contradict annotations, but it is too thin to adequately prepare an agent for the tool's runtime behavior.

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 a single concise sentence that front-loads the core action and scope. Every word contributes to the purpose, with no unnecessary filler. It is appropriately sized for the tool's complexity.

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?

Given the tool's complexity (8 parameters, no output schema), the description is only partially complete. It explains what is sent and to whom, but does not cover the handshake process, potential prompts, or the blocking nature with timeout. The schema covers parameter specifics, but the overall workflow context is missing, leaving an agent to infer that sending may be asynchronous or interactive.

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 100% coverage for all 8 parameters with detailed descriptions. The tool description adds minimal value beyond the schema, only referencing 'files, folders, or text/clipboard snippets' which maps to the 'files' and 'text' parameters. Since the schema is comprehensive, a 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 a specific action ('Send'), the resource types (files, folders, text/clipboard snippets), and the target context (LocalSend device on LAN by alias or IP). It effectively distinguishes itself from sibling tools like localsend_devices (which lists devices) and localsend_status (which checks status).

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 when to use it (when you want to send content) but does not explicitly mention alternatives or conditions like discovering devices first (localsend_devices) or checking status (localsend_status). It lacks guidance on when not to use it, such as if the target device is not on the LAN.

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

localsend_setupC

Update LocalSend MCP server configuration (alias, download directory, or transport).

ParametersJSON Schema

Name	Required	Description	Default
`alias`	No	New broadcast alias for the AI agent (e.g. 'Antigravity Agent').
`downloadDir`	No	Directory path where incoming files are automatically saved.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states that configuration is updated. It does not say whether changes persist, require a restart, take effect immediately, or are reversible; the mention of 'transport' also hints at a capability not present in the schema.

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 one compact sentence with the operation and target front-loaded. It wastes no words, though the unsupported 'transport' item is an accuracy issue rather than a structure issue.

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?

For a simple two-optional-parameter tool, the schema plus short description is mostly sufficient to form a call. However, with no annotations and no output schema, the description omits whether at least one parameter must be supplied, whether the update is incremental, and what kind of confirmation or error the agent should expect.

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 coverage is 100%, so the schema already fully documents alias and downloadDir. The description adds no useful meaning beyond that and instead introduces 'transport' as a third setting that is not represented in the schema, which is misleading for parameter selection.

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?

The description uses a specific verb ('Update') and names the resource ('LocalSend MCP server configuration'), making the tool's purpose immediately recognizable against siblings like localsend_send and localsend_status. Clarity is slightly reduced because it lists 'transport' as an updatable setting even though the input schema only exposes alias and downloadDir.

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?

There is no guidance about when to call this tool versus alternatives, no prerequisites, and no exclusions. The only usage signal is the implied role of a configuration-update tool, which the agent must infer from the name and sibling contrast.

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

localsend_statusA

Inspect local network addresses, active MCP listening port, certificate fingerprint, and inbox status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the behavioral burden. The word 'Inspect' clearly signals a read-only operation, and the listed data categories set expectations about what the tool accesses. It does not mention permissions, output shape, or errors, but for a zero-parameter status tool this is reasonably transparent.

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?

One sentence with no filler. The main verb and the four inspected areas are front-loaded and every word earns its place. This is appropriately concise for a simple status 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?

Given zero parameters, no annotations, and no output schema, the description is largely complete: it names the major categories of information returned. It could be slightly more explicit about the output format or whether any setup is required, but for a low-complexity status inspection it covers the essential context.

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 has zero parameters, and the baseline for zero-parameter tools is 4. There are no parameter details needed, and the description correctly focuses on what the tool reports rather than on inputs.

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 ('Inspect') and names concrete resources: local network addresses, MCP listening port, certificate fingerprint, and inbox status. It clearly differentiates from siblings like localsend_send and localsend_setup, so an agent can tell what this tool is for without opening schemas.

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 the tool is for reading current status and diagnostics, but it does not explicitly state when to use it versus alternatives like localsend_devices or localsend_setup. There is no exclusion or direct sibling comparison, so usage guidance is only implied, not explicit.

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 updatesv1.0.0Sep 19, 2026
- First observedlocalsend_devices
- First observedlocalsend_history
- First observedlocalsend_send
- First observedlocalsend_setup
- First observedlocalsend_status

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.8/5.0

Scored 2026-09-19 12:40 across 5 tools

Disambiguation5/5

Each tool targets a distinct concern: device discovery, sending, server status, receiving history, and configuration. There is no overlap or ambiguity between tools.

Naming Consistency4/5

Names consistently use a localsend_ prefix and snake_case. However, not all follow a strict verb_noun pattern—devices, status, and history are nouns while send and setup are verbs—so it is mostly consistent with minor deviation.

Tool Count5/5

Five tools is well-scoped for a focused LocalSend integration. Each tool covers a necessary capability without redundancy or bloat.

Completeness5/5

The set covers the full local workflow: discovering devices, sending content, checking server status, reviewing received files, and updating configuration. No major gaps are apparent for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Geolocate MeOAuth
com.guleki
Give any AI assistant real-time access to your phone's GPS and location history.
Location Services OS Automation
2
SRIFT A
app.srift
Secure P2P File Transfer, Encrypted Chat & Communication | Decentralized P2P & AES-256-GCM encryption | Zero cloud logs. Zero registration. For humans and autonomous AI agents / MCP servers.
Communication File Systems Networking & Infrastructure
811
BasinOAuth
co.getbasin
Your AI assistants coordinate with other people's in one shared library across tools and companies.
Knowledge & Memory RAG Systems
1
OneAIMemoryOAuth
io.github.AmxnCode
Cross-device AI memory with encrypted activity capture and context handoff between AI tools
Knowledge & Memory RAG Systems Autonomous Agents
1

Related MCP Servers

Anytype MCP Server
Note Taking Knowledge & Memory File Systems
Qwinty
F
license
A
quality
D
maintenance
Enables AI assistants to interact with Anytype data through the local API, allowing search, creation, modification, and export of objects, spaces, and lists.
Updated a year ago (2025-08-07 08:07 UTC)
18
24
-
filesystem-mcp
File Systems Developer Tools
LincolnBurrows2017
A
license
A
quality
F
maintenance
Enables AI assistants to read, write, and manage files on the local system with security features like path restrictions and optional read-only mode.
Updated 6 months ago (2026-03-11 06:15 UTC)
9
2
MIT
iotforge
Home Automation & IoT Networking & Infrastructure
ashlarforge
A
license
B
quality
D
maintenance
Enables AI assistants to discover and control IoT devices on local networks and via Bluetooth LE.
Updated 6 months ago (2026-03-12 18:57 UTC)
7
1
MIT
Esco
Agent Orchestration Communication
JonusNattapong
A
license
Not graded
quality
B
maintenance
Enables AI coding agents to communicate asynchronously via a decentralized, peer-to-peer LAN bridge with automatic discovery and direct messaging.
Updated 2 months ago (2026-07-09 06:50 UTC)
MIT

LocalSend MCP Server (localsend-mcp)

⚡ Key Capabilities

🛠️ MCP Tools Exposed

🚀 Installation & Build

🔄 Automated Git Synchronization (sync.ps1)

⚙️ Configuration

Antigravity (mcp_servers configuration)

Claude Desktop (claude_desktop_config.json)

🧪 Usage Examples

1. Discover Devices on LAN

2. Send an Artifact or Report to Your Phone

3. Push a Code Snippet Directly to Clipboard

4. Check Inbox for Files Sent From Mobile

🔒 Security & Privacy

📄 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

LocalSend MCP Server (`localsend-mcp`)

🔄 Automated Git Synchronization (`sync.ps1`)

Antigravity (`mcp_servers` configuration)

Claude Desktop (`claude_desktop_config.json`)