Skip to main content
Glama
zenmode87

svara-mcp

by zenmode87
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Svara MCP server

Send native LinkedIn voice notes from Claude, Cursor, VS Code or any other MCP client.

Svara is a REST API for sending voice notes on LinkedIn. This server exposes it as MCP tools, so your AI assistant can upload a recording, validate a send, deliver a voice note to one of your LinkedIn contacts, and check whether it arrived.

What it does

  • Upload an audio file (MP3, M4A/AAC, OGG/Opus, WAV or WebM, up to 4 MB).

  • Send it as a native LinkedIn voice note to someone you can already message on LinkedIn.

  • Check delivery status (queued, sent, failed, expired).

  • Check your plan usage.

Sends are dry runs by default: nothing is delivered unless dry_run is explicitly set to false.

Related MCP server: linkedin-mcp

Prerequisites

  1. A Svara account and an API key: create one at https://svarapi.io/dashboard.

  2. The Svara Chrome extension installed.

  3. You are signed in to LinkedIn in that Chrome browser.

  4. Node.js 20 or newer (for npx).

Setup

All clients run the same command: npx -y svara-mcp with SVARA_API_KEY in the environment.

Claude Desktop

Add to claude_desktop_config.json (Settings > Developer > Edit Config):

{
  "mcpServers": {
    "svara": {
      "command": "npx",
      "args": ["-y", "svara-mcp"],
      "env": { "SVARA_API_KEY": "your_svara_api_key" }
    }
  }
}

Claude Code

claude mcp add svara --env SVARA_API_KEY=your_svara_api_key -- npx -y svara-mcp

Cursor

Add to ~/.cursor/mcp.json (or .cursor/mcp.json in a project):

{
  "mcpServers": {
    "svara": {
      "command": "npx",
      "args": ["-y", "svara-mcp"],
      "env": { "SVARA_API_KEY": "your_svara_api_key" }
    }
  }
}

VS Code

Add to .vscode/mcp.json:

{
  "inputs": [
    { "type": "promptString", "id": "svara-api-key", "description": "Svara API key", "password": true }
  ],
  "servers": {
    "svara": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "svara-mcp"],
      "env": { "SVARA_API_KEY": "${input:svara-api-key}" }
    }
  }
}

Tools

Tool

What it does

upload_audio

{ file_path } Uploads a local audio file and returns an audio_url. Sends nothing.

send_linkedin_voice_note

{ recipient, audio_url? , file_path?, dry_run = true } Sends a voice note. recipient is a LinkedIn profile URL (preferred) or name. Give exactly one of audio_url or file_path (a file is uploaded first).

get_send_status

{ id } Delivery status of a send.

get_usage

{} Current plan usage and limits.

Example prompt: "Upload ~/Desktop/intro.m4a and do a dry run of sending it to https://www.linkedin.com/in/example. If it validates, send it for real."

Safety

send_linkedin_voice_note sends a real LinkedIn message to a real person from your own LinkedIn account when dry_run is false. It cannot be unsent.

  • dry_run defaults to true, which validates the request without sending anything.

  • The tool is marked as destructive, so MCP clients that support tool annotations will ask you to confirm before it runs. Keep that confirmation on.

  • Only send to people you can already message on LinkedIn, and only messages you would send yourself.

Pricing

Plans and limits: https://svarapi.io/pricing. When you hit a limit, the tool error includes an upgrade link.

Support

Email hello@svarapi.io.

License

MIT

Available Tools

4 tools
get_send_statusGet send statusA
Read-onlyIdempotent

Get the delivery status (queued, sent, failed or expired) of a voice note sent with send_linkedin_voice_note.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe id returned by send_linkedin_voice_note.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully established. The description adds the status vocabulary and the relationship to the send operation, which is useful, but it does not disclose additional behavioral details such as whether statuses have timeouts or how the id is used internally. With strong annotations, this is adequate.

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 states the operation, the possible status values, and the relevant sibling tool. There is no filler, and the key context appears immediately.

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 one-parameter status lookup, the description is complete. It identifies the required input's origin, enumerates the expected statuses, and benefits from annotations covering safety and idempotency. No output schema is present, but the description names the returned concept clearly enough for an agent.

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 coverage is 100%, and the single parameter 'id' is already described as 'The id returned by send_linkedin_voice_note.' The tool description does not need to add much, and it confirms the id's origin by mentioning the send tool. Baseline 3 applies because the schema carries the parameter semantics.

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 ('Get'), a specific resource ('delivery status'), and enumerates the possible states (queued, sent, failed, expired). It also ties the tool to send_linkedin_voice_note, clearly distinguishing it from the sibling send tool and other unrelated operations.

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 implies when to use it: after sending a voice note via send_linkedin_voice_note, to check delivery status. It does not explicitly list exclusions or alternatives, but the association with the send tool is enough to route an agent correctly among siblings.

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

get_usageGet usageA
Read-onlyIdempotent

Get the current Svara plan usage and limits for this API key.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond those: it is a 'current' snapshot scoped to 'this API key,' implying that results may reflect live plan state for the caller's key rather than arbitrary workspace data.

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, front-loaded sentence with no filler. Every word contributes to identifying what is fetched and for whom.

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?

This is a simple read-only, no-parameter tool with rich annotations. The description conveys the core return subject (usage and limits) and scope (current, per API key), which is sufficient for an agent to call it correctly without needing output schema details.

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?

There are zero parameters, and the rubric sets a baseline of 4 for such tools. The description does not need to explain parameters since none exist; its statement about the API key scope is sufficient context.

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 names the verb (get), resource (Svara plan usage and limits), and scope (current, for this API key). It is immediately distinguishable from siblings like upload_audio or send_linkedin_voice_note, which involve creating or sending rather than reading plan state.

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 clear context: use this when you need current plan usage and limits tied to the API key. It does not explicitly name alternatives or when-not-to-use conditions, but the zero-parameter read nature and sibling differentiation make the intended usage obvious.

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

send_linkedin_voice_noteSend LinkedIn voice noteA
Destructive

Send a native LinkedIn voice note to a person via Svara. WARNING: when dry_run is false this sends a REAL LinkedIn voice message to a real person, from the user's own LinkedIn account. It cannot be unsent. Only call with dry_run=false when the user has explicitly asked you to send this voice note to this recipient. dry_run defaults to true, which validates the request without sending anything. The recipient must be someone the user can already message on LinkedIn (for example a 1st-degree connection); pass their LinkedIn profile URL (preferred) or the name part after /in/ (not their display name). Provide exactly one of audio_url (from upload_audio) or file_path (a local audio file, uploaded first). Delivery requires the Svara Chrome extension to be installed and the user to be signed in to LinkedIn in Chrome. Returns a message id; check delivery with get_send_status.

ParametersJSON Schema
NameRequiredDescriptionDefault
dry_runNoDefaults to true (validate only, nothing is sent). Set false ONLY when the user explicitly asked to send.
audio_urlNoaudio_url returned by upload_audio. Provide this OR file_path.
file_pathNoLocal audio file to upload and send. Provide this OR audio_url.
recipientYesLinkedIn profile URL (preferred), e.g. https://www.linkedin.com/in/jane-doe, or just the name part after /in/. Must be someone the user can already message on LinkedIn.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark destructiveHint=true, but the description goes far beyond: it warns that a real message 'cannot be unsent', clarifies it is sent from the user's own LinkedIn account, explains dry_run behavior, and notes external prerequisites (Chrome extension, LinkedIn sign-in). This materially adds destructive and environmental context above what annotations alone provide.

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 a single dense paragraph of about 160 words. Every sentence earns its place, especially the front-loaded warning about destructive real-world sending. It could benefit slightly from bullet formatting, but there is no fluff or repetition of schema content.

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 destructive send tool with 4 parameters, no output schema, and safety-critical preconditions, the description covers the full workflow: input selection (dry_run, recipient, one of two audio sources), environmental requirements, what is returned (message id), and how to follow up (get_send_status). Nothing an agent needs to call it correctly is left ambiguous.

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?

Even though schema coverage is 100%, the description adds critical meaning: it enforces 'exactly one' of audio_url or file_path (a constraint missing from the schema), identifies audio_url as coming from upload_audio, clarifies file_path must be uploaded first, and details recipient format ('LinkedIn profile URL (preferred), or just the name part after /in/'). This goes well beyond the schema's individual field descriptions.

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 opens with a specific verb and resource: 'Send a native LinkedIn voice note to a person via Svara.' It immediately distinguishes itself from siblings by referencing upload_audio (source of audio_url) and get_send_status (delivery check) within the same text. An agent can infer exactly what this tool does and how it differs from nearby tools without inspecting schemas.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: only call with dry_run=false when 'the user has explicitly asked you to send this voice note to this recipient.' It also states dry_run defaults to true for validation, defines recipient eligibility ('someone the user can already message on LinkedIn'), and names required preconditions like the Svara Chrome extension and LinkedIn sign-in. This is thorough routing and guardrail guidance.

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

upload_audioUpload audioA

Upload a local audio file (MP3, M4A/AAC, OGG/Opus, WAV or WebM, max 4 MB) to Svara. Returns an audio_url to pass to send_linkedin_voice_note. Uploading does not send anything.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYesAbsolute path to a local audio file.

TDQS

A4/5.0
Behavior3/5

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

Annotations include destructiveHint=false and readOnlyHint=false, so the description doesn't need to cover safety. It does mention format and size constraints, which adds value. But it doesn't clarify behavior on upload failure or whether the file is deleted after upload.

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 redundancy. The key constraints (formats, size, return value) are front-loaded, and the note about not sending is a useful clarification in a single short clause.

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 upload tool with one parameter and strong schema coverage, the description is mostly complete. It explains the return value and the relationship to send_linkedin_voice_note. The only gap is error handling or side effects, but that is minor given the tool's simplicity.

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 coverage is 100%, so the file_path parameter is already described as 'Absolute path to a local audio file.' The description mentions formats and size (4 MB), which adds meaning beyond the schema, but it doesn't explain what happens if the format or size is invalid.

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 a specific action (upload), the resource (local audio file), lists accepted formats and size limit, and notes the return value (audio_url). The phrase 'does not send anything' clearly distinguishes it from sibling send_linkedin_voice_note.

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?

Clearly states the purpose and result, and implicitly differentiates from send_linkedin_voice_note by noting it does not send. However, it doesn't explicitly state when to use it vs alternatives, or any exclusion conditions beyond format/size.

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.

  1. 4 tool updatesv0.1.0
    • First observedget_send_status
    • First observedget_usage
    • First observedsend_linkedin_voice_note
    • First observedupload_audio
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

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct step in the workflow: uploading audio, sending a voice note, checking delivery status, and viewing account usage. There is no meaningful overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a clear verb_noun pattern: upload_audio, send_linkedin_voice_note, get_send_status, get_usage. The get_ prefix is used consistently for read-only operations.

Tool Count5/5

Four tools is well-scoped for this server's narrow purpose: upload, send, check status, and view usage. Each tool earns its place, and none feel redundant or missing as core operations.

Completeness4/5

The main workflow of upload, send, and verify delivery is fully covered, plus usage tracking. Minor gaps exist such as no ability to list past sends or manage uploaded audio, but these are not critical for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • linkedin-mcp

    2060-io
    A
    license
    A
    quality
    C
    maintenance
    Enables AI agents to publish posts, images, comments, and reactions to LinkedIn as the authenticated user, with built-in safety features like daily budgets and deduplication.
    9
    11 npm
    Apache 2.0

  • linkedin-mcp

    jmougeot
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables sending LinkedIn messages and invitations, reading conversations, and managing outreach through natural language by automating a real LinkedIn session via a Chrome extension.
    11 npm
    MIT