iletiMerkezi SMS API를 위한 Model Context Protocol 서버입니다. MCP를 지원하는 LLM 클라이언트(Claude Code, Cursor, Codex CLI, Gemini CLI, VS Code+Cline, Claude Desktop 등)가 도구 호출을 통해 SMS를 발송하고, 발송 보고서를 조회하며, 발신자 및 블랙리스트를 관리할 수 있도록 합니다.
iletiMerkezi는 터키의 BTK 인증을 받은 대량 SMS / OTP / A2P 플랫폼입니다. 도구 형태(입력 스키마, 설명, 문서 링크)는 공식 엔드포인트 문서에서 생성된 표준 API 매니페스트에서 파생되므로, 이 서버는 설계상 라이브 API와 항상 동기화된 상태를 유지합니다.
도구 | API 엔드포인트 | 참고 |
|
| 하나 이상의 번호로 SMS 발송 |
|
| 발송 전 예약된 주문 취소 |
|
| 단일 주문 발송 보고서 (요약 + 수신자별) |
|
| 날짜 범위 내 주문 요약 목록 (최대 10일) |
|
| 계정 잔액 (TL + SMS 크레딧) |
|
| 승인된 발신자(헤더) 목록 |
|
| 차단된 번호 (페이지네이션) |
|
| 번호 차단 (멱등성) |
|
| 번호 차단 해제 |
|
| İYS 동의 기록 등록 (일괄, 최대 5000건) |
|
| 수신자의 İYS 동의 상태 조회 |
Related MCP server: ileti-merkezi-mcp
5개의 클라이언트가 동일한 JSON mcpServers 스키마를 공유하며, Claude Code와 Codex CLI는 한 줄 CLI 명령어도 제공합니다. 아래에서 사용 중인 클라이언트를 선택하세요.
클라이언트 | 설정 파일 | 형식 |
Claude Code |
| JSON |
Cursor |
| JSON |
Gemini CLI |
| JSON |
VS Code + Cline |
| JSON |
Claude Desktop |
| JSON |
Codex CLI |
| TOML |
관련 설정 파일에 다음 블록을 추가하세요:
{
"mcpServers": {
"iletimerkezi": {
"command": "npx",
"args": ["-y", "@iletimerkezi/mcp-server"],
"env": {
"ILETIMERKEZI_API_KEY": "your-api-key",
"ILETIMERKEZI_API_HASH": "your-api-hash"
}
}
}
}클라이언트를 완전히 종료한 후 다시 실행하세요. 11개의 도구가 iletimerkezi 서버 아래에 나타납니다.
사용자 범위 (모든 프로젝트에서 사용 가능):
claude mcp add iletimerkezi -s user \
-e ILETIMERKEZI_API_KEY=your-api-key \
-e ILETIMERKEZI_API_HASH=your-api-hash \
-- npx -y @iletimerkezi/mcp-server현재 Claude Code 세션을 닫고 새로 시작하세요. 도구는 mcp__iletimerkezi__*로 나타납니다. 제거하려면 claude mcp remove iletimerkezi -s user를 사용하세요.
CLI를 통한 방법:
codex mcp add iletimerkezi \
--env ILETIMERKEZI_API_KEY=your-api-key \
--env ILETIMERKEZI_API_HASH=your-api-hash \
-- npx -y @iletimerkezi/mcp-server또는 ~/.codex/config.toml을 직접 편집하세요:
[mcp_servers.iletimerkezi]
command = "npx"
args = ["-y", "@iletimerkezi/mcp-server"]
[mcp_servers.iletimerkezi.env]
ILETIMERKEZI_API_KEY = "your-api-key"
ILETIMERKEZI_API_HASH = "your-api-hash"처음 사용할 때 get_balance와 get_sender를 시도해 보세요. 둘 다 읽기 전용이며 크레딧을 소모하지 않습니다.
이 클라이언트들은 원격 MCP(HTTPS 엔드포인트)가 필요하며 로컬 npx 명령을 생성하지 않습니다. 이 서버는 현재 stdio(로컬) 모드로만 제공됩니다. 호스팅 지원은 로드맵에 포함되어 있습니다.
두 값 모두 panel.iletimerkezi.com → Settings → Security → API Access에서 확인할 수 있습니다. 그대로 복사하세요. 직접 해시하지 마십시오. 패널에서 미리 계산된 해시를 제공합니다.
또한 Settings → Security → Access Permissions에서 Allow API access를 활성화해야 합니다. 그렇지 않으면 모든 호출이 401을 반환합니다. 이는 가장 흔한 온보딩 실수이며, 서버의 401 오류 메시지가 이 토글을 가리킵니다.
전체 인증 계약은 https://www.iletimerkezi.com/docs/api/authentication을 참조하세요.
부팅 시 서버는 다음 순서대로 시도합니다:
~/.cache/iletimerkezi-mcp/manifest.json에 있는 로컬 캐시 (24시간 유효).
https://www.iletimerkezi.com/api/manifest.json의 라이브 페치 (5초 타임아웃). 성공 시 캐시를 원자적으로 새로 고침.
npm 패키지와 함께 제공되는 빌드 시점 폴백 (dist/manifest.fallback.json) — npm publish 시점의 매니페스트 스냅샷.
즉, 매니페스트에 게시된 새로운 엔드포인트나 스키마 변경 사항은 npm update 없이도 24시간 이내에 실행 중인 클라이언트에 전파됩니다. 이 저장소 어디에도 수동으로 작성된 도구 스키마는 없으며, API 문서가 유일한 진실의 원천입니다.
스테이징/미리보기 환경의 경우 ILETIMERKEZI_MANIFEST_URL을 사용하여 매니페스트 URL을 재정의할 수 있습니다.
npm install
npm run build
npm test셸에 자격 증명을 입력하여 라이브 API에 대해 서버를 스모크 테스트하세요:
ILETIMERKEZI_API_KEY=... ILETIMERKEZI_API_HASH=... node dist/index.js이것은 stdio를 통해 MCP를 통신합니다. MCP 클라이언트를 사용하여 상호 작용하거나 디버깅을 위해 JSON-RPC 핸드셰이크를 수동으로 파이프하세요.
MCP 설정 가이드: https://www.iletimerkezi.com/docs/mcp (TR) · /en/docs/mcp (EN)
매니페스트 (기계 판독 가능): https://www.iletimerkezi.com/api/manifest.json
릴리스 노트: CHANGELOG.md
MIT — LICENSE를 참조하세요.
The add-blacklist endpoint adds one phone number to your account's blacklist so it is skipped by send-sms. Idempotent: re-adding the same number returns 200 instead of an error. One number per request.
Reference: https://www.iletimerkezi.com/en/docs/api/add-blacklist
| Name | Required | Description | Default |
|---|---|---|---|
| blacklist | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses idempotency (re-adding returns 200) and the effect on send-sms. This goes beyond the schema but lacks details on auth, rate limits, or side effects. Still, it provides key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a reference link, with no unnecessary words. Every sentence adds value: purpose, idempotency, limit per request.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation, idempotency, and the relationship to send-sms. It lacks output format details (no output schema), but for a simple add operation this is acceptable. The reference link provides additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a description for the 'number' parameter with accepted formats, so the description adds only 'one number per request.' With 0% schema description coverage counted, the tool description compensates partially but does not add significant extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('adds one phone number'), the target resource ('to your account's blacklist'), and the effect ('so it is skipped by send-sms'). It distinguishes from sibling tools like delete_blacklist (removal) and get_blacklist (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions idempotency and 'one number per request,' which are important usage constraints. However, it does not explicitly state when to use this tool versus alternatives (e.g., delete_blacklist, get_blacklist), though the context of blacklist management makes it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The cancel-order endpoint cancels an order created via send-sms with a sendDateTime in the future, before it is dispatched to the carrier. Only orders that have not started sending can be cancelled; once the order enters the send pipeline, the cancel window has closed and the request returns 455.
Reference: https://www.iletimerkezi.com/en/docs/api/cancel-order
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the cancel window and the error condition (455). However, it does not mention idempotency or side effects like irreversible cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a reference link. The core action and condition are front-loaded. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description should explain what the tool returns on success. It only mentions the error case (455). Missing description of the success response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. The description explains that the order.id comes from a previous send-sms call and must be for a future-scheduled order. This adds context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that cancel_order cancels a future-scheduled SMS order created via send-sms before dispatch. It distinguishes this tool from siblings like send_sms by specifying the precondition of a future sendDateTime.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: only for orders that have not started sending. States that once in the send pipeline, cancellation fails with error 455. Provides a reference link for more details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The delete-blacklist endpoint removes a phone number from your account's blacklist. After removal, send-sms can deliver to that number again. One number per request; not idempotent, removing a number that is not on the list returns an error.
Reference: https://www.iletimerkezi.com/en/docs/api/delete-blacklist
| Name | Required | Description | Default |
|---|---|---|---|
| blacklist | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses non-idempotency and error behavior, and references external docs. It could be more explicit about authentication or rate limits but covers the key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences with a reference, front-loading the purpose and effect without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers purpose, behavior, error case, and provides an external reference, making it complete enough for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the number parameter with accepted formats. The description adds no additional parameter semantics beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes a phone number from the blacklist and explicitly distinguishes from sibling tools like add_blacklist and get_blacklist by specifying the effect on SMS delivery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context when to use (to allow delivery to a number) and mentions non-idempotency and error conditions. However, it does not explicitly contrast with add_blacklist for adding numbers or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The get-balance endpoint returns the TL balance remaining on your account and the number of standard SMS messages that balance can fund. It has no side effects and consumes no credits, making it the safest call for verifying authentication and checking remaining budget before a campaign.
Reference: https://www.iletimerkezi.com/en/docs/api/get-balance
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the tool has no side effects and consumes no credits, which is critical behavioral information. With no annotations provided, the description fully carries the burden of transparency, and it does so effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the core function and then provide usage context. A reference link is included. Every sentence is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description fully covers what the tool returns (balance and SMS count) and its side-effect-free behavior. It is complete enough for an agent to understand when to use and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds value by explaining what the response contains (balance and SMS count), which goes beyond simply naming the tool. Given the absence of parameters, this explanation is valuable for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns TL balance and number of standard SMS messages it can fund. It uses a specific verb ('get') and resource ('balance'). No sibling tools serve a similar purpose, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is safe for verifying authentication and checking remaining budget before a campaign, giving clear context for when to use. It does not explicitly mention when not to use or alternatives, but no sibling performs a similar function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The get-blacklist endpoint returns the list of phone numbers that you have blocked on your account. Numbers on this list are skipped during send-sms delivery. The call has no side effects and consumes no credits.
Reference: https://www.iletimerkezi.com/en/docs/api/get-blacklist
| Name | Required | Description | Default |
|---|---|---|---|
| blacklist | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no side effects and no credit consumption, which is good. However, omits details on pagination and filtering behavior beyond what is in the schema. With no annotations, description carries full burden but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a reference link. Efficient and front-loaded with purpose. Minimal wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing details on pagination behavior, filter usage, and return format. No output schema provided. For a tool with nested parameters, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has detailed descriptions for all parameters (page, rowCount, filter), so baseline is 3. Description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the list of blocked phone numbers and explains the effect (skipped during send-sms). Distinguishes from siblings like add_blacklist and delete_blacklist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'no side effects and consumes no credits', which implies safe usage, but does not explicitly state when to use versus alternatives or when not to use. No comparative guidance with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The get-report endpoint returns the delivery report for an order created via send-sms. One response carries the overall order status, summary counters (total / delivered / undelivered / waiting), timestamps, sender, order price, and per-recipient delivery status. Large orders paginate via page + rowCount.
Reference: https://www.iletimerkezi.com/en/docs/api/get-report
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It thoroughly describes the response structure (status, counters, timestamps, sender, price, per-recipient status) and pagination. However, it does not mention authentication requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs covering response contents and pagination. A reference link is included. Could be slightly more streamlined but effectively communicates necessary info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately explains the return values and pagination. It references external docs for completeness. Sibling context is clear. Minor gap: no error scenario coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has detailed descriptions for each parameter (id, page, rowCount), so the description adds little beyond confirming pagination. Schema description coverage is effectively high, keeping baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns delivery reports for orders created via send-sms, listing specific fields. This distinguishes it from sibling tools like get_reports and get_balance, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after a send-sms call but does not explicitly state when not to use it or compare with alternatives like get_reports. Pagination details are mentioned but not prerequisites or error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The get-reports endpoint returns the aggregate summary list of all SMS orders created within a given date range. For each order the response carries counters (total / delivered / undelivered / waiting), timestamps, and sender; per-recipient breakdown is not included. For recipient-level details, call get-report for the specific order. This endpoint backs the Reports > Bulk SMS History screen in the panel. Typical use cases: dashboards, periodic analytics, queries like "list orders from the last week".
Reference: https://www.iletimerkezi.com/en/docs/api/get-reports
| Name | Required | Description | Default |
|---|---|---|---|
| filter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates this is a read-only retrieval (returns list, no destructive language) and describes the response contents (counters, timestamps, sender). It does not explicitly say 'read-only', but the context implies it. The lack of explicit destructive caveats is acceptable for a 'get' tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loads the main purpose, and uses every sentence to add value (purpose, limitations, use cases, sibling reference). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list endpoint without output schema, the description sufficiently explains the response (counters, timestamps, sender), pagination (page parameter), and typical usage. It also links to external documentation. The sibling tools are contextually relevant for disambiguation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meanings. However, the description only mentions 'given date range' and does not describe the structure of the filter parameter, the start/end format, the page parameter, or the constraints (e.g., 10-day limit). The schema does provide some parameter descriptions, but the tool description fails to add value beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an aggregate summary list of SMS orders within a date range, differentiating it from the per-recipient detail tool (get_report). It identifies the resource (SMS orders), the verb (returns list), and the scope (summary, date-filtered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for aggregated summaries) and when to use an alternative ('For recipient-level details, call get-report'). It provides typical use cases like dashboards and periodic analytics. However, it does not explicitly state when not to use the tool beyond the sibling reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The get-sender endpoint returns the list of sender IDs (headers) registered and approved on your account. The order.sender field of send-sms only accepts values from this list; using anything else is rejected. The call has no side effects and consumes no credits.
Reference: https://www.iletimerkezi.com/en/docs/api/get-sender
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'no side effects and consumes no credits,' which are critical behavioral traits. With no annotations, this disclosure is sufficient. Could mention rate limits, but not necessary for a simple list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences plus a reference link. Each sentence adds value: purpose, usage context, and behavioral notes. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers what the tool does, its purpose in relation to send-sms, and its safety profile. No output schema needed since return value is clearly described as a list of sender IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema (0 params, 100% coverage), so description doesn't need to add param info. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the list of sender IDs (headers) registered and approved on the account. The verb 'returns' and resource 'sender IDs' are specific. Siblings include unrelated tools like blacklist and balance, so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains that the result is used in send-sms's order.sender field and that non-list values are rejected. Provides clear context for when to use, though no direct alternatives or when-not-to-use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The iys-check endpoint returns the current İYS (İleti Yönetim Sistemi) consent status for a given recipient. Use it to verify a record submitted via iys-register has been processed, to check ONAY (consent) / RET (rejection) before a commercial send, or to produce audit reports. The call has no side effects and consumes no credits.
Reference: https://www.iletimerkezi.com/en/docs/api/iys-check
| Name | Required | Description | Default |
|---|---|---|---|
| consent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It states no side effects and no credit consumption, but lacks details on rate limits, authentication, or error behavior. Reference to external docs partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and every sentence adds value. No wasted words, and the reference link is appropriately placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested input schema and no output schema, the description covers basic usage but lacks details on return format, error handling, or comparison with sibling tools. Complete enough for a simple check tool but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, so description must compensate. The description does not explain individual fields (e.g., brandCode, recipientType), only mentions 'recipient' and 'consent status'. This is insufficient for proper parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('returns') and resource ('current İYS consent status'), and distinguishes from the sibling tool iys_register by mentioning verification of a submitted record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided (verifying processed records, checking consent before sending, audit reports), and it states no side effects, but does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The iys-register endpoint creates İYS (İleti Yönetim Sistemi) consent records, the legally required Turkish national registry for commercial electronic messaging. Consents (or rejections) collected via web forms, signed contracts, call-center confirmations, etc. are submitted to iletiMerkezi through this endpoint and forwarded to the national İYS registry. Up to 5000 recipients per request. İYS registration is mandatory for any commercial SMS sent in Turkey. Without a valid consent record, the corresponding send-sms call with iys: "1" is rejected with code 468 / 469 / 470.
Reference: https://www.iletimerkezi.com/en/docs/api/iys-register
| Name | Required | Description | Default |
|---|---|---|---|
| consent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses atomicity (one bad record fails the whole batch), the 5000 limit, and the legal requirement. It lacks response details and authentication requirements, but the disclosed traits are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise, front-loaded with the core purpose, and includes a reference link. It could be slightly more streamlined but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested parameters, no output schema, no annotations), the description should discuss response behavior, authentication, and error handling for the endpoint itself. It only mentions downstream rejection errors. Atomicity and limits help, but overall completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds only minimal parameter insight: the 5000 per request limit and atomicity. It does not explain brandCode, list structure, or consentDate constraints beyond what the schema provides. Since schema description coverage is 0%, the description should compensate but falls short.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates İYS consent records for the Turkish national registry, with a specific verb ('creates') and resource ('İYS consent records'). It distinguishes from sibling tools like iys_check and send_sms by focusing on registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong context: it emphasizes mandatory registration for commercial SMS and warns of rejection codes 468/469/470 if consent is missing. It does not explicitly list when not to use this tool, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The send-sms endpoint delivers an SMS to one or many mobile numbers in a single request. Each request is treated as an order; the response returns an orderId you can use to retrieve delivery reports or cancel scheduled orders. One order per request, one sender (header) per order.
Reference: https://www.iletimerkezi.com/en/docs/api/send-sms
| Name | Required | Description | Default |
|---|---|---|---|
| order | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: the intentional misspelling of 'receipents' for backward compatibility, APITEST sender restrictions, scheduling nuances, and the automatic appending of B186 operator code. However, it omits rate limits or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a reference link. It front-loads the main action and provides a reference for details. However, it could be slightly more structured (e.g., bullet points) for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity with nested objects and no output schema, the description fairly covers the essential behavioral aspects like order handling, sender restrictions, and scheduling. It also includes a reference for additional details, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal parameter info beyond what the input schema already provides. The schema has detailed descriptions for parameters like iys and sender, so the baseline is 3 due to high schema description coverage. The description does mention the 'receipents' misspelling, which is helpful but not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool delivers SMS to one or many numbers in a single request and returns an orderId. It distinguishes from sibling tools like get_report or cancel_order by focusing on sending SMS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives, but the purpose is clear. It could mention that for checking delivery reports, use get_report, but overall it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_blacklistcancel_orderdelete_blacklistget_balanceget_blacklistget_reportget_reportsget_senderiys_checkiys_registersend_smsEach tool has a distinct, clearly defined purpose. Blacklist, order, and İYS operations each have separate tools for different actions (add/delete/get, cancel/report, check/register), with no overlap.
All tool names follow a consistent verb_noun pattern in snake_case, such as add_blacklist, get_report, send_sms. No deviations or mixed conventions.
11 tools is appropriate for the scope of an SMS API server, covering sending, blacklisting, reporting, balance, sender IDs, and İYS compliance. Neither too few nor too many.
The tool set covers the main operations: send SMS (CRUD on orders indirectly via cancel and reporting), blacklist management (add, delete, get), balance, sender info, and İYS consent (register and check). No obvious gaps for the advertised domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Send SMS, manage contacts and groups, and read delivery reports. OAuth 2.1 SureSMS login.
Send SMS/MMS, manage contacts, and read campaigns, messages and media on SimpleTexting.
SMS Verify: SMS Verify API is a secure and easy-to-integrate service that sends verification codes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/iletimerkezi/iletimerkezi-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
