Skip to main content
Glama
hongsw

Aligo SMS MCP Server

by hongsw

Aligo SMS MCP Server

A server that can access the Aligo SMS API using the Model Context Protocol (MCP). MCP-compatible AI agents, such as Claude AI, can send SMS messages or query related information.

installation

{
  "mcpServers": {
    "aligo-sms-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "github:hongsw/aligo-sms-mcp-server",
        "mcp-server"
      ]
    }
  }
}

Related MCP server: Twilio MCP Server

setting

Your API key settings are stored in the .garakrc file. Create the following file in your home directory:

https://smartsms.aligo.in/admin/api/auth.html

ALIGO_API_KEY=발급받은_API_키
ALIGO_USER_ID=발급받은_사용자_아이디
ALIGO_TEST_MODE=Y  # 테스트 모드 (Y/N)

How to use

Find the tool list icon and click on it

After completing the above settings, you will see the following screen.

Aligo SMS MCP Server Screen


010xxxxyyyy 에서 010xxxxyyyy 로 문자를 보내줘 "안녕하세요 MCP 22222입니다." 라는 내용으로

If you send using the above prompt,

Aligo SMS MCP Server Screen

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

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

Acknowledgments

  • Aligo for providing the SMS API

  • Model Context Protocol for standardizing tools and resource access

Available Tools

1 tool
send-smsC

Send SMS messages through the Aligo API

ParametersJSON Schema
NameRequiredDescriptionDefault
destinationNoOptional formatted destination with names (01011112222|홍길동,01033334444|아무개)
image_pathNoOptional image file path for MMS
messageYesSMS message content
msg_typeNoMessage type: SMS, LMS, or MMS
receiverYesRecipient's phone number, or comma-separated list for multiple recipients
schedule_dateNoOptional schedule date (YYYYMMDD)
schedule_timeNoOptional schedule time (HHMM)
senderYesSender's phone number (registered with Aligo)
titleNoMessage title (required for LMS/MMS)

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 only states the basic action. It fails to mention critical aspects like whether this is a mutation (likely yes, as it sends messages), potential costs, rate limits, error handling, or response format, leaving 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 with zero wasted words. It's appropriately sized and front-loaded, clearly stating the core function 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?

Given the tool's complexity (9 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral traits, usage context, or return values, making it inadequate for an agent to fully understand how to invoke and interpret results from this tool.

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 schema fully documents all 9 parameters. The description adds no additional parameter information beyond what's in the schema, such as explaining interactions between parameters (e.g., 'title' required for LMS/MMS) or usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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 messages') and target ('through the Aligo API'), providing a specific verb+resource combination. However, it doesn't distinguish from siblings since there are none, and it could be more precise about the full capability (handling SMS, LMS, and MMS).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, prerequisites, or constraints. The description lacks context about appropriate use cases, rate limits, or authentication requirements, offering no usage direction beyond the basic function.

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

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'send-sms' has a clear and distinct purpose, making it impossible for an agent to misselect between multiple options.

Naming Consistency5/5

The single tool name 'send-sms' follows a consistent verb-noun pattern, using kebab-case. Since there is only one tool, there is no inconsistency in naming conventions, and the pattern is straightforward and predictable.

Tool Count2/5

The server has only one tool, which feels thin for an SMS service domain. While it covers the core functionality of sending SMS, typical SMS APIs include additional operations like checking status, managing templates, or retrieving messages, making this set under-scoped for the apparent purpose.

Completeness2/5

The tool set is severely incomplete for an SMS service. It only provides 'send-sms', lacking essential operations such as checking delivery status, retrieving sent messages, managing contacts, or handling errors, which are common in SMS APIs and necessary for robust agent workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • -
    license
    A
    quality
    Not graded
    maintenance
    A Model Context Protocol server that enables Claude to help developers implement SMS and MMS messaging features in web and mobile applications through direct integration with BaaS API services.
    4
    4
  • A
    license
    B
    quality
    B
    maintenance
    MCP server for sending SMS via the SMSPM API. Send transactional SMS from Claude Desktop, Cursor, Windsurf, Cline, or any MCP client.
    1
    48
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hongsw/aligo-sms-mcp-server'

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