What can you do with this server?

This MCP server enables AI assistants to send and manage SMS messages through Sweden's 46elks telecommunications infrastructure. Core Capabilities: * Send SMS Messages - Dispatch messages to international phone numbers with custom sender IDs, flash SMS support, and dry-run mode for testing without incurring costs * Retrieve Message History - Access up to 100 inbound/outbound messages with filtering by direction * Check Message Status - Monitor delivery status and details using unique message IDs * Estimate SMS Costs - Calculate pricing and message segment counts before sending to avoid unexpected charges * Check Account Balance - Verify available funds in your 46elks account * Analyze Delivery Statistics - Review success rates and delivery analytics from recent SMS activities Key Features: * Safety & Security - OWASP MCP Top 10 compliant with dry-run mode enabled by default, input validation, rate limiting (100 SMS/minute), and audit logging * Cost Protection - Real-time cost estimation and multi-part SMS handling with automatic character limit detection * Integration - Works with MCP clients like Claude Desktop and VS Code Copilot using environment variables for secure API credential management * Deployment - Supports Docker containers for isolated and secure operation

Which integrations are available for this server?

Runtime environment used to execute the MCP server Programming language used to implement the MCP server

How do I use 46elks MCP Server?

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., "@46elks MCP Server send SMS to +46701234567 with message 'Meeting at 3 PM tomorrow'" 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.

46elks MCP Server

by palhamel

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

46elks MCP Server

License: MIT Node.js TypeScript Docker OWASP MCP Top 10

MCP server for 46elks SMS API - Send SMS messages through Swedish telecommunications infrastructure.

Enable Claude Desktop, VS Code Copilot, and other MCP-compatible tools to send SMS messages through Sweden's leading SMS provider. Built with security-first design following OWASP MCP Top 10 guidelines, including rate limiting, audit logging, and input sanitization.

⚠️ Disclaimer: This is an unofficial community project and is not affiliated with or endorsed by 46elks AB.

Getting Started

Prerequisites: You'll need Node.js 22+ (LTS recommended) and one of these MCP clients: Claude Desktop, VS Code with Copilot, or Cursor.

Step 1: Get 46elks Credentials

Before installing the MCP server, you'll need 46elks credentials:

1.1 Create Account & Add Funds

Sign up at 46elks.com
Complete verification process
Add funds to your account wallet - SMS sending requires account balance
Go to the 46elks dashboard

💰 Important: You need money in your 46elks wallet to send real SMS messages. Each SMS has a cost (typically ~0.50-1.00 SEK per message depending on destination).

In your 46elks dashboard, go to the Account tab
Look for the API section
Copy your API username (starts with u)
Copy your API password (starts with p)

⚠️ Important: Use your API credentials (found under Account → API), NOT your 46elks account login credentials. The API credentials are specifically for integrations like this MCP server.

1.3 Get Phone Number

In your dashboard, go to Phone Numbers
Purchase or note your existing phone number
Use the full international format (e.g., +46701234567)

Step 2: Install MCP Server

# Clone the repository
git clone https://github.com/palhamel/46elks-mcp-server.git
cd 46elks-mcp-server

# Install dependencies
npm install

# Build the project
npm run build

Step 3: Configure Your MCP Client

Choose your preferred MCP client. See examples/ for complete configuration examples.

Option A: Claude Desktop

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "sms-46elks": {
      "command": "node",
      "args": ["/path/to/46elks-mcp-server/dist/index.js"],
      "env": {
        "ELKS_API_USERNAME": "your_46elks_api_username",
        "ELKS_API_PASSWORD": "your_46elks_api_password",
        "ELKS_PHONE_NUMBER": "your_46elks_phone_number",
        "DRY_RUN": "true"
      }
    }
  }
}

Note: The config key sms-46elks must not start with a number. Starting with a number (e.g., 46elks) can cause the MCP server to not be recognized by some clients.

Important: Replace /path/to/46elks-mcp-server with the actual path where you cloned the repository.

Option B: VS Code Copilot

Add this to your VS Code MCP configuration file:

macOS: ~/Library/Application Support/Code/User/mcp.json Windows: %APPDATA%/Code/User/mcp.json

{
  "mcpServers": {
    "sms-46elks": {
      "command": "node",
      "args": ["/path/to/46elks-mcp-server/dist/index.js"],
      "env": {
        "ELKS_API_USERNAME": "your_46elks_api_username",
        "ELKS_API_PASSWORD": "your_46elks_api_password",
        "ELKS_PHONE_NUMBER": "your_46elks_phone_number",
        "DRY_RUN": "true"
      }
    }
  }
}

For detailed VS Code setup instructions, see: VS Code MCP Documentation

Related MCP server: Twilio SMS Server

Available Tools

Note: This MCP server supports sending SMS and checking message history. You can send SMS and check for incoming replies using the get_sms_messages tool. Real-time SMS receiving (webhooks) is not implemented - use message history checking instead.

`send_sms`

Send SMS messages with validation and cost estimation.

Parameters:

to (required): Recipient phone number in international format
message (required): SMS message text
from (optional): Custom sender ID or phone number (see security notes below)
flashsms (optional): Set to "yes" for flash SMS (see Flash SMS limitations below)
dryRun (optional): Override environment DRY_RUN setting

FROM Parameter Security:

Default: Uses your configured ELKS_PHONE_NUMBER (recommended for replies)
Custom Sender ID: Max 11 alphanumeric characters, must start with letter
Phone Number: Any valid international number (⚠️ ensure you have permission)
Validation: Blocks impersonation attempts (BANK, POLICE, etc.)
Best Practice: Use your own business name or verified phone number

Examples:

Send SMS to +46701234567 with message "Hello from Claude!"

Send SMS to +46701234567 from "MyApp" with message "Your order is ready!"

Send flash SMS to +46701234567 with message "URGENT: System maintenance in 5 minutes"

⚠️ Flash SMS Note: Flash SMS may not display correctly on iPhone/iPad devices. See Flash SMS section below for device compatibility details.

🔒 Dry Run Safety: By default, DRY_RUN=true simulates SMS sending without actual delivery or charges. Set to false only when ready to send real messages.

`get_sms_messages`

Retrieve SMS message history with filtering options.

Parameters:

direction (optional): "inbound", "outbound", or "both" (default: "both")
limit (optional): Number of messages to retrieve (1-100, default: 10)

Examples:

Get my last 20 SMS messages

Show me only incoming SMS messages from the last hour

💡 Checking Responses: Use this tool to check if someone has replied to your SMS! While not instant like a chat, you can easily see incoming messages to your 46elks phone number. Perfect for checking customer responses or confirmations.

`check_sms_status`

Check delivery status and details of sent messages.

Parameters:

messageId (required): The message ID returned from send_sms

Example:

Check status of SMS message id abc123

`estimate_sms_cost`

Get cost estimates without sending SMS.

Parameters:

to (required): Recipient phone number
message (required): SMS message text

`check_account_balance`

Verify 46elks account balance and information.

Example:

Check my 46elks account balance

`get_delivery_statistics`

Analyze SMS delivery success rates and statistics.

Configuration Options

Environment Variables

Variable	Required	Description	Example
`ELKS_API_USERNAME`	Yes	Your 46elks API username	`u1234567890abcdef`
`ELKS_API_PASSWORD`	Yes	Your 46elks API password	`p1234567890abcdef`
`ELKS_PHONE_NUMBER`	Yes	Your 46elks phone number	`+46701234567`
`DRY_RUN`	No	Enable dry run mode (default: true)	`true` or `false`

Dry Run Mode (Cost Protection)

Enabled (DRY_RUN=true):
- SMS messages are simulated with realistic cost estimates
- No actual messages sent or charges incurred
- Perfect for testing and development
- Default setting for safety
Disabled (DRY_RUN=false):
- SMS messages are actually sent through 46elks
- Real charges apply to your account wallet
- Only use when ready for production

⚠️ Cost Protection: We default to DRY_RUN=true to prevent accidental SMS sending and unexpected charges. This protects you from:

Accidentally sending test messages to real numbers
Incurring costs during development and testing
Sending messages with wrong content or recipients

Recommended: Always test thoroughly with DRY_RUN=true before switching to false for production use.

SMS Costs & Limits

Message Costs

Typical Cost: ~0.50-1.00 SEK per SMS (varies by destination)
Multi-part Messages: Charged per SMS part (160 chars = 1 part, 320 chars = 2 parts)
International: Higher rates for non-Swedish numbers
Real-time Estimates: Use estimate_sms_cost tool for exact pricing

Message Limits

Character Limits:
- 160 characters (standard GSM characters)
- 70 characters (with emojis/special characters)
Rate Limits: 100 SMS per minute per account (enforced by 46elks API)
Multi-part: Long messages automatically split and reassembled

Rate Limiting Behavior

Enforcement: Rate limits are enforced by 46elks at the API level, not by our MCP server
What Happens: If you exceed 100 SMS per minute, 46elks will return rate limit errors
Bulk Operations: For large batches (CSV files, etc.), you'll need to pace your requests
Recommendation: For bulk sending, send SMS in batches of 90-95 per minute with 1-minute pauses
Error Handling: Rate limit errors are returned clearly with instructions to retry after waiting

Flash SMS

Use Case: Urgent notifications that display immediately
Behavior: Shows on screen instantly, not stored in inbox
Cost: Same as regular SMS
Device Compatibility:
- ✅ Android: Displays as popup overlay (supported)
- ❌ iPhone/iPad: Shows as regular SMS (not supported by iOS)
- ✅ Feature Phones: Usually supported
- ⚠️ Carrier-dependent: Some networks may not support Flash SMS

Important: Flash SMS is not supported by iPhone/iPad devices. iOS ignores the flash flag and displays Flash SMS messages as regular SMS messages in the Messages app.

Learn More:

46elks Flash SMS Tutorial - Complete guide to Flash SMS
46elks SMS API Documentation - Technical implementation details

Usage Examples

Basic SMS Sending

Claude, send an SMS to +46701234567 saying "Meeting starts in 30 minutes"

Check Message History

Show me my last 10 SMS messages

Cost Estimation

How much would it cost to send "Long message..." to +46701234567?

Account Management

What's my current 46elks account balance?

Bulk SMS Operations

⚠️ Important: For large-scale SMS sending (100+ messages), we strongly recommend using 46elks' dedicated bulk SMS service instead of this MCP server.

Recommended for Bulk SMS:

46elks JustSend: justsend.46elks.com
Features: CSV upload, scheduling, delivery reports, bulk pricing
Benefits: No rate limits, optimized for large volumes, professional bulk tools

If Using This MCP Server for Small Batches (<100 SMS):

I have 50 customer phone numbers. Help me send promotional SMS within rate limits.

Estimate the cost to send "Event reminder" to 30 customers, and plan the timing.

Small Batch Strategy (Under 100 SMS):

Batch Size: Maximum 90 SMS per minute to stay under limits
Time Required: ~1 minute per 90 messages + brief pauses
Cost Planning: Use estimate_sms_cost for accurate pricing
Safety First: Always test with DRY_RUN=true before sending
Monitoring: Check account balance before starting

Why Use JustSend for Large Volumes:

No Rate Limits: Send thousands of SMS efficiently
CSV Support: Upload contact lists directly
Professional Tools: Scheduling, templates, delivery tracking
Bulk Pricing: Better rates for high volumes
Reliability: Purpose-built for bulk operations

Testing

✅ Successfully tested with:

Claude Desktop (macOS/Windows)
VS Code Copilot (macOS/Windows)

⏳ Expected to work with:

Cursor (not yet verified)
Other MCP-compatible tools

Docker Support

Run the MCP server in a Docker container for isolated, secure deployment.

Build and Run with Docker

# Build the Docker image
docker build -t 46elks-mcp-server .

# Run with environment variables
docker run -i --rm \
  -e ELKS_API_USERNAME=your_username \
  -e ELKS_API_PASSWORD=your_password \
  -e ELKS_PHONE_NUMBER=+46701234567 \
  -e DRY_RUN=true \
  46elks-mcp-server

Docker Compose

For easier local testing:

# Copy .env.example to .env and fill in your credentials
cp .env.example .env

# Run with Docker Compose
docker-compose up --build

Claude Desktop with Docker

Configure Claude Desktop to use the Docker container:

{
  "mcpServers": {
    "46elks-sms": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
        "-e", "ELKS_API_USERNAME=your_username",
        "-e", "ELKS_API_PASSWORD=your_password",
        "-e", "ELKS_PHONE_NUMBER=+46701234567",
        "46elks-mcp-server"]
    }
  }
}

Docker MCP Catalog

This server is being submitted to the Docker MCP Catalog for trusted distribution with:

Container isolation
Cryptographic signatures
Software Bill of Materials (SBOM)
Automatic security updates

Development

Local Setup

# Clone the repository
git clone https://github.com/palhamel/46elks-mcp-server.git
cd 46elks-mcp-server

# Install dependencies
npm install

# Run tests
npm test

# Run linter
npm run lint

# Format code
npm run format

# Start development mode (auto-rebuild)
npm run dev

# Build for production
npm run build

# Test the server
npm start

Available Scripts

npm run build - Compile TypeScript to JavaScript
npm run dev - Watch mode for development
npm test - Run test suite
npm run test:watch - Run tests in watch mode
npm run test:coverage - Generate test coverage report
npm run lint - Check code with ESLint
npm run lint:fix - Auto-fix linting issues
npm run format - Format code with Prettier
npm run format:check - Check code formatting
npm run type-check - Type check without emitting files

Project Structure

46elks-mcp-server/
├── src/
│   ├── __tests__/        # Unit tests
│   ├── index.ts          # Main MCP server
│   ├── config.ts         # Configuration management
│   ├── elks-client.ts    # 46elks API client
│   ├── validation.ts     # Input validation
│   ├── utils.ts          # Utility functions
│   └── errors.ts         # Error handling
├── examples/             # Example configurations
├── dist/                 # Compiled JavaScript
├── .github/              # GitHub Actions workflows
├── package.json
└── README.md

Contributing

We welcome contributions! Please see CONTRIBUTING.md for guidelines on:

Setting up your development environment
Running tests and linters
Submitting pull requests
Code style and conventions

Code Quality

This project uses:

TypeScript for type safety
ESLint for code linting
Prettier for code formatting
Vitest for testing with 33+ unit tests
GitHub Actions for CI/CD

All code is automatically tested and linted on push.

Security

This MCP server has been hardened following OWASP MCP Top 10 guidelines. See SECURITY.md for full details.

API & Credential Security

API credentials are passed through MCP client configuration (not stored in code)
Credential validation on startup - Server fails fast if credentials are invalid
Dry run mode prevents accidental SMS sending during development
Input validation prevents malicious phone numbers and messages
No sensitive data is logged or stored

OWASP MCP Compliance Features

Rate Limiting: Prevents abuse through rapid tool calls (10 SMS/min, 60 queries/min)
Audit Logging: Structured JSON logs for security monitoring (phone numbers masked)
Input Sanitization: Control character stripping, URL detection warnings
Message ID Validation: Prevents injection through malformed IDs

Configure rate limits via environment variables:

RATE_LIMIT_SMS_PER_MINUTE=10      # Default: 10
RATE_LIMIT_QUERIES_PER_MINUTE=60  # Default: 60

Enhanced Security Features

46elks Flexibility: 46elks provides excellent flexibility in sender ID options, allowing custom sender names and phone numbers for various business needs.

Our Additional Security Layer: To help users follow best practices and avoid common pitfalls, we've added responsible validation features:

✅ Smart Defaults: Uses your verified ELKS_PHONE_NUMBER as default sender for reliable delivery
✅ Best Practice Guidance: Helps avoid sender IDs that might be filtered (BANK, POLICE, etc.)
✅ Format Validation: Ensures sender IDs meet 46elks requirements (max 11 chars, must start with letter)
✅ Professional Recommendations: Encourages use of legitimate business names or owned numbers
✅ Permission Awareness: Alerts when using phone numbers as sender IDs

Benefits: These features help ensure:

Better SMS delivery rates by following carrier best practices
Professional appearance and brand consistency
Compliance with SMS regulations and carrier guidelines
Reduced risk of messages being filtered or blocked

This approach enhances 46elks' powerful API with additional guidance for optimal results.

Troubleshooting

Common Issues

Error: "Missing required environment variables"

Check your MCP client configuration file
Ensure all required environment variables are set
Verify file paths are absolute paths

Error: "Invalid phone number format"

Use international format: +46701234567
Don't use spaces or dashes in phone numbers

Messages not sending (DRY_RUN=false)

Verify 46elks account has sufficient balance
Check phone number is valid and not blocked
Ensure 46elks account is in good standing

Rate Limit Errors (429 responses)

You've exceeded 100 SMS per minute - wait 1 minute before retry
For bulk operations: pace requests to 90-95 SMS per minute
Use cost estimation tools to plan large batches before sending
Consider implementing delays between messages for CSV bulk operations

MCP Server Best Practices (Small Batches Only)

Recommended Limit: Use this MCP server for <100 SMS at a time
Large Operations: Use justsend.46elks.com for bulk SMS instead
Rate Limits: Stay under 90 SMS per minute if using MCP server
Testing: Always test with DRY_RUN=true before any batch sending

Build errors

Ensure Node.js 22+ LTS is installed (Node.js 20 is End of Life as of April 2026)
Run npm install to install dependencies
Delete node_modules and package-lock.json, then npm install

Getting Help

For 46elks API, account, pricing, and service questions:

Visit: 46elks.com/support
Official 46elks documentation: 46elks.com/docs

For bulk SMS sending or CSV upload:

Use 46elks' dedicated service: justsend.46elks.com

For MCP server issues:

Check the Issues page for this project
Check MCP documentation for your client (Claude Desktop, VS Code, etc.)

Contributing

Bug reports and pull requests are welcome on GitHub. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the code of conduct.

License

This project is licensed under the MIT License - see the LICENSE file for details.

⚠️ Disclaimer: This is an unofficial community project and is not affiliated with or endorsed by 46elks AB. 46elks is a registered trademark of 46elks AB.

🇸🇪 Made for the Swedish developer community with ❤️ for AI-powered SMS automation.

Available Tools

6 tools

check_account_balanceB

Check 46elks account balance and account information to verify funds availability for SMS sending

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It mentions the tool's purpose but doesn't disclose behavioral traits like authentication requirements, rate limits, whether it's read-only or has side effects, or what specific information is returned. The description is functional but lacks operational transparency.

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, efficient sentence that states the tool's purpose clearly. It's appropriately sized for a simple tool and front-loads the essential information without unnecessary elaboration.

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 financial checking tool with no annotations and no output schema, the description is insufficient. It doesn't explain what specific account information is returned, the format of the balance, whether this requires special permissions, or how the agent should interpret the results. The context demands more 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?

The tool has zero parameters with 100% schema coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters, which is correct for a parameterless tool. Baseline is 4 for zero parameters.

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 clearly states the verb ('check') and resource ('46elks account balance and account information') with a specific purpose ('to verify funds availability for SMS sending'). It distinguishes from siblings by focusing on account-level information rather than SMS operations, though it doesn't explicitly name alternatives.

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 context ('to verify funds availability for SMS sending'), suggesting this should be used before sending SMS messages. However, it doesn't provide explicit guidance on when to use this versus other tools or mention any prerequisites or exclusions.

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

check_sms_statusA

Check delivery status and details of a sent SMS

ParametersJSON Schema

Name	Required	Description	Default
`message_id`	Yes	46elks message ID returned when SMS was sent

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool checks status and details, but does not disclose behavioral traits such as required permissions, rate limits, error handling, or what specific details are returned (e.g., delivery timestamps, error codes). This leaves gaps for a read operation.

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, efficient sentence that front-loads the core purpose ('Check delivery status and details') without any wasted words. It is appropriately sized for a simple lookup tool.

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 low complexity (one parameter, read-only operation) and lack of annotations or output schema, the description is minimally adequate. However, it does not fully compensate for missing behavioral context (e.g., what details are returned, error cases), leaving some gaps for an agent to understand the tool's complete behavior.

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 100% description coverage, clearly documenting the single required 'message_id' parameter. The description adds no parameter-specific information beyond what the schema provides, but with only one parameter and high schema coverage, the baseline is appropriately met without needing extra details.

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 specific action ('Check delivery status and details') and the resource ('a sent SMS'), distinguishing it from siblings like 'send_sms' (creation) and 'get_delivery_statistics' (aggregate data). It precisely communicates the tool's function without redundancy.

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 checking status of sent SMS messages, but does not explicitly state when to use this tool versus alternatives like 'get_sms_messages' (which might retrieve multiple messages) or 'get_delivery_statistics' (which could provide broader analytics). No exclusions or prerequisites are mentioned.

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

estimate_sms_costA

Estimate cost and message segments for SMS without sending it

ParametersJSON Schema

Name	Required	Description
`from`	No	Sender phone number or name (optional, uses default if not specified)
`message`	Yes	SMS message content to estimate cost for
`to`	Yes	Recipient phone number with country code (e.g., +46XXXXXXXXX for Swedish numbers)

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses the tool's non-destructive nature ('without sending it'), which is useful behavioral context. However, it lacks details on rate limits, authentication needs, or error handling, leaving gaps for a tool that interacts with billing/systems.

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 that efficiently conveys the tool's purpose and key constraint ('without sending it'). There is no wasted verbiage, and every word earns its place in clarifying the tool's function.

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 moderate complexity (cost estimation with 3 parameters) and no annotations or output schema, the description is adequate but incomplete. It covers the core purpose but lacks details on output format (e.g., cost breakdown, segment count) or prerequisites, which would help an agent use it effectively.

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 has 100% description coverage, so parameters are well-documented there. The description adds no additional parameter semantics beyond implying the tool uses 'message' and 'to' for estimation, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Estimate cost and message segments') and the resource ('SMS'), distinguishing it from sibling tools like 'send_sms' (which sends) and 'check_sms_status' (which checks status). It explicitly mentions 'without sending it' to differentiate from the sending functionality.

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 for when to use this tool: to estimate costs before sending an SMS. It implies an alternative ('send_sms' for actual sending) but does not explicitly name it or specify when not to use this tool (e.g., for real-time cost checks vs. historical data).

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

get_delivery_statisticsC

Get SMS delivery statistics and success rates from recent messages

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Number of recent messages to analyze for statistics (default: 50, max: 100)

TDQS

C2.9/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 tool retrieves statistics, implying a read-only operation, but doesn't cover aspects like authentication requirements, rate limits, data freshness, or what 'recent messages' entails. This leaves significant gaps in understanding the tool's 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized for its function, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what statistics are returned (e.g., success rates, delivery times), how data is formatted, or any error conditions. For a tool with one parameter but missing structured context, more detail is needed to fully guide the 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?

The input schema has 100% description coverage, with the 'limit' parameter well-documented. The description adds no additional parameter details beyond what the schema provides, such as clarifying 'recent messages' or statistical metrics. This meets the baseline for high schema coverage.

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 clearly states the action ('Get') and resource ('SMS delivery statistics and success rates from recent messages'), making the tool's purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'check_sms_status' or 'get_sms_messages', which might also involve SMS message data, so it doesn't reach the highest score.

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?

The description provides no guidance on when to use this tool versus alternatives like 'check_sms_status' or 'get_sms_messages'. It lacks context on prerequisites, such as needing recent messages or specific account permissions, leaving the agent with minimal usage direction.

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

get_sms_messagesC

Retrieve SMS message history from 46elks

ParametersJSON Schema

Name	Required	Description	Default
`direction`	No	Filter messages by direction (default: both)
`limit`	No	Maximum number of messages to retrieve (default: 10, max: 100)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't mention whether this is a read-only operation, what permissions might be required, potential rate limits, or how results are returned (e.g., pagination, format). While 'Retrieve' implies reading, the lack of detail about behavioral traits is a significant gap.

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

Conciseness5/5

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

The description is extremely concise at just one sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential function without unnecessary elaboration, making it easy for an agent to parse quickly.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete for a retrieval tool with two parameters. It doesn't explain what the returned data looks like, how historical messages are organized, or any behavioral constraints. While the schema covers parameters well, the overall context for proper tool invocation remains inadequate.

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 schema description coverage is 100%, with both parameters ('direction' and 'limit') fully documented in the schema itself. The description adds no additional parameter information beyond what's already in the structured schema, so it meets the baseline expectation but provides no extra value.

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 clearly states the action ('Retrieve') and resource ('SMS message history from 46elks'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate this retrieval tool from sibling tools like 'check_sms_status' or 'get_delivery_statistics', which might also involve SMS message data access.

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?

The description provides no guidance on when to use this tool versus alternatives like 'check_sms_status' or 'get_delivery_statistics'. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent with insufficient information to make informed usage decisions among related SMS tools.

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

send_smsC

Send SMS message via 46elks

ParametersJSON Schema

Name	Required	Description
`dry_run`	No	Test mode - verify request without sending actual SMS (optional, defaults to environment setting)
`flashsms`	No	Set to "yes" for flash SMS that displays immediately and is not stored (optional)
`from`	No	Sender phone number or name (optional, uses default if not specified)
`message`	Yes	SMS message content (max 160 characters for single SMS)
`to`	Yes	Recipient phone number with country code - MUST be a real phone number, not a placeholder (e.g., +46XXXXXXXXX for Swedish numbers)

TDQS

C2.9/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 but offers minimal information. It mentions the service provider ('46elks') but doesn't cover critical aspects like authentication requirements, rate limits, error handling, or what happens upon sending (e.g., confirmation, costs, delivery status). This is inadequate for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is extremely concise with just four words ('Send SMS message via 46elks'), making it front-loaded and efficient. Every word contributes essential information (action, resource, provider), with no wasted sentences or redundant phrasing.

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

Completeness2/5

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

Given the complexity of a mutation tool (sending SMS) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., costs, delivery guarantees), error scenarios, or what the tool returns, leaving significant gaps for an AI agent to understand the tool's full context and implications.

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 schema description coverage is 100%, meaning all parameters are documented in the input schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain parameter interactions or provide examples), so it meets the baseline for high schema coverage without compensating with extra value.

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 clearly states the action ('Send SMS message') and specifies the service provider ('via 46elks'), which provides a specific verb+resource combination. However, it doesn't differentiate this tool from its siblings like 'check_sms_status' or 'get_sms_messages', which would require explicit comparison to achieve a perfect score.

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?

The description provides no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, when-not-to-use scenarios, or comparisons with sibling tools like 'estimate_sms_cost' for planning or 'check_sms_status' for verification, leaving the agent without contextual usage instructions.

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.

6 tool updatesv1.0.0Sep 23, 2025
- First observedcheck_account_balance
- First observedcheck_sms_status
- First observedestimate_sms_cost
- First observedget_delivery_statistics
- First observedget_sms_messages
- First observedsend_sms

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

Scored 2026-04-18 08:45 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap. For example, check_account_balance focuses on account funds, check_sms_status tracks individual SMS delivery, estimate_sms_cost provides pre-send calculations, get_delivery_statistics analyzes aggregate success rates, get_sms_messages retrieves historical data, and send_sms handles message transmission. The descriptions make it easy for an agent to select the right tool without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as check_account_balance, estimate_sms_cost, and send_sms. This predictable naming convention enhances readability and makes the tool set easy to navigate, with no deviations in style or structure across the six tools.

Tool Count5/5

With 6 tools, the server is well-scoped for SMS management on the 46elks platform. Each tool serves a specific and necessary function, from sending messages to monitoring costs and statuses, without being overly sparse or bloated. This count aligns perfectly with the domain's typical operations.

Completeness5/5

The tool set provides complete coverage for SMS lifecycle management on 46elks. It includes core operations like sending SMS, checking status and history, estimating costs, monitoring account balance, and analyzing delivery statistics. There are no obvious gaps; agents can handle end-to-end workflows from planning to sending and reviewing messages.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

sms-mcpOAuth
com.mobile-text-alerts
The Mobile Text Alerts SMS MCP server enables your AI to send SMS messages & manage contacts
Communication Customer Support App Automation
2
AgentLine AOAuth
io.github.AgentLineHQ
Give AI agents a phone number. Voice calls, SMS, and phone number management for MCP clients.
Communication Autonomous Agents
2
HailOAuth
io.github.hail-hq
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Communication Email Agent Orchestration
229
AgentPhoneOAuth
io.github.AgentPhone-AI
Give AI agents real phone numbers, messages, and voice calls via MCP.
Communication Speech Processing
2123

Related MCP Servers

Twilio MCP Server
Communication App Automation
griffinwork40
A
license
Not graded
quality
D
maintenance
Enables AI-powered SMS messaging through Twilio with automatic conversation threading, message status tracking, and webhook support for receiving inbound messages.
Updated 9 months ago (2026-01-02 04:10 UTC)
45 npm
1
MIT
Twilio SMS Server
Communication App Automation Developer Tools
mustafa-boorenie
A
license
B
quality
D
maintenance
Enables AI assistants to send SMS messages via Twilio through the Model Context Protocol or a standalone REST API. It supports standard messaging, automated greetings, and creative content generation using natural language.
Updated a year ago (2025-06-25 16:08 UTC)
1
13 npm
MIT
Twilio SMS MCP Server
Communication App Automation
0x-Professor
A
license
C
quality
D
maintenance
Enables AI agents to send, receive, schedule, and manage SMS and MMS messages using the Twilio Programmable Messaging API. It provides comprehensive tools for handling bulk messaging, conversation threads, and real-time inbox monitoring through a secure, production-grade architecture.
Updated 6 months ago (2026-03-10 18:27 UTC)
16
1
MIT
MojaWave MCPofficial
Communication
mojawave
A
license
A
quality
C
maintenance
Connects any MCP-compatible AI assistant to the MojaWave SMS Gateway, enabling sending SMS, checking credit balances, and managing bulk SMS jobs.
Updated 18 days ago (2026-09-02 14:24 UTC)
10
MIT

46elks MCP Server

Getting Started

Step 1: Get 46elks Credentials

1.1 Create Account & Add Funds

1.2 Get API Credentials (NOT your account login)

1.3 Get Phone Number

Step 2: Install MCP Server

Step 3: Configure Your MCP Client

Option A: Claude Desktop

Option B: VS Code Copilot

Available Tools

send_sms

get_sms_messages

check_sms_status

estimate_sms_cost

check_account_balance

get_delivery_statistics

Configuration Options

Environment Variables

Dry Run Mode (Cost Protection)

SMS Costs & Limits

Message Costs

Message Limits

Rate Limiting Behavior

Flash SMS

Usage Examples

Basic SMS Sending

Check Message History

Cost Estimation

Account Management

Bulk SMS Operations

Testing

Docker Support

Build and Run with Docker

Docker Compose

Claude Desktop with Docker

Docker MCP Catalog

Development

Local Setup

Available Scripts

Project Structure

Contributing

Code Quality

Security

API & Credential Security

OWASP MCP Compliance Features

Enhanced Security Features

Troubleshooting

Common Issues

Getting Help

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MojaWave MCPofficial

`send_sms`

`get_sms_messages`

`check_sms_status`

`estimate_sms_cost`

`check_account_balance`

`get_delivery_statistics`