Model Context Protocol-Server für die iletiMerkezi SMS-API. Ermöglicht MCP-fähigen LLM-Clients (Claude Code, Cursor, Codex CLI, Gemini CLI, VS Code+Cline, Claude Desktop, …) das Senden von SMS, das Abfragen von Zustellberichten und die Verwaltung von Absendern/Blacklists durch Tool-Aufrufe.
iletiMerkezi ist eine türkische, BTK-lizenzierte Plattform für Massen-SMS, OTP und A2P. Die Tool-Strukturen (Eingabeschemata, Beschreibungen, Dokumentations-Links) werden aus einem kanonischen API-Manifest abgeleitet, das aus der offiziellen Endpunkt-Dokumentation erstellt wurde. Dadurch bleibt dieser Server konzeptionsbedingt stets synchron mit der Live-API.
Tool | API-Endpunkt | Hinweise |
|
| SMS an eine oder mehrere Nummern senden |
|
| Zukünftigen Auftrag vor dem Versand stornieren |
|
| Zustellbericht für einen einzelnen Auftrag (Zusammenfassung + pro Empfänger) |
|
| Liste der Auftragszusammenfassungen innerhalb eines Datumsbereichs (max. 10 Tage) |
|
| Kontostand (TL + SMS-Guthaben) |
|
| Liste der genehmigten Absender (Header) |
|
| Blockierte Nummern (paginiert) |
|
| Nummer blockieren (idempotent) |
|
| Nummer entsperren |
|
| İYS-Einwilligungsdatensätze registrieren (Batch, max. 5000) |
|
| İYS-Einwilligungsstatus für einen Empfänger abrufen |
Related MCP server: ileti-merkezi-mcp
Fünf Clients teilen sich dasselbe JSON-mcpServers-Schema; Claude Code und Codex CLI bieten zudem einen einzeiligen CLI-Befehl. Wählen Sie Ihren Client unten aus.
Client | Konfigurationsdatei | Format |
Claude Code |
| JSON |
Cursor |
| JSON |
Gemini CLI |
| JSON |
VS Code + Cline |
| JSON |
Claude Desktop |
| JSON |
Codex CLI |
| TOML |
Fügen Sie diesen Block zur entsprechenden Konfigurationsdatei hinzu:
{
"mcpServers": {
"iletimerkezi": {
"command": "npx",
"args": ["-y", "@iletimerkezi/mcp-server"],
"env": {
"ILETIMERKEZI_API_KEY": "your-api-key",
"ILETIMERKEZI_API_HASH": "your-api-hash"
}
}
}
}Beenden Sie den Client vollständig und starten Sie ihn neu. Die 11 Tools erscheinen unter dem iletimerkezi-Server.
Benutzerebene (verfügbar für alle Projekte):
claude mcp add iletimerkezi -s user \
-e ILETIMERKEZI_API_KEY=your-api-key \
-e ILETIMERKEZI_API_HASH=your-api-hash \
-- npx -y @iletimerkezi/mcp-serverSchließen Sie die aktuelle Claude Code-Sitzung und starten Sie eine neue. Die Tools erscheinen als mcp__iletimerkezi__*. Entfernen mit claude mcp remove iletimerkezi -s user.
Über die CLI:
codex mcp add iletimerkezi \
--env ILETIMERKEZI_API_KEY=your-api-key \
--env ILETIMERKEZI_API_HASH=your-api-hash \
-- npx -y @iletimerkezi/mcp-serverOder bearbeiten Sie ~/.codex/config.toml direkt:
[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"Versuchen Sie bei der ersten Verwendung get_balance und get_sender — beide sind schreibgeschützt und verbrauchen kein Guthaben.
Diese Clients erfordern Remote-MCP (HTTPS-Endpunkte) und starten keine lokalen npx-Befehle. Dieser Server wird derzeit nur im stdio-Modus (lokal) ausgeliefert. Unterstützung für gehostete Umgebungen steht auf der Roadmap.
Beide Werte stammen aus panel.iletimerkezi.com → Settings → Security → API Access. Kopieren Sie diese unverändert — hashen Sie sie nicht selbst; das Panel stellt einen vorberechneten Hash bereit.
Sie müssen außerdem Allow API access unter Settings → Security → Access Permissions aktivieren, andernfalls gibt jeder Aufruf 401 zurück. Dies ist der häufigste Fehler bei der Einrichtung; die 401-Fehlermeldung des Servers weist auf diesen Schalter hin.
Den vollständigen Authentifizierungsvertrag finden Sie unter https://www.iletimerkezi.com/docs/api/authentication.
Beim Start versucht der Server in dieser Reihenfolge:
Lokaler Cache unter ~/.cache/iletimerkezi-mcp/manifest.json, gültig für 24 Stunden.
Live-Abruf von https://www.iletimerkezi.com/api/manifest.json (5s Timeout). Bei Erfolg wird der Cache atomar aktualisiert.
Build-Zeit-Fallback (dist/manifest.fallback.json), das mit dem npm-Paket ausgeliefert wird — der Manifest-Snapshot zum Zeitpunkt von npm publish.
Das bedeutet, dass neue Endpunkte oder Schema-Änderungen, die im Manifest veröffentlicht werden, innerhalb von 24 Stunden an laufende Clients weitergegeben werden, ohne dass ein npm update erforderlich ist. Es gibt kein manuell geschriebenes Tool-Schema in diesem Repository — die API-Dokumentation ist die einzige Quelle der Wahrheit.
Sie können die Manifest-URL mit ILETIMERKEZI_MANIFEST_URL für Staging-/Vorschau-Umgebungen überschreiben.
npm install
npm run build
npm testTesten Sie den Server gegen die Live-API mit Anmeldedaten in Ihrer Shell:
ILETIMERKEZI_API_KEY=... ILETIMERKEZI_API_HASH=... node dist/index.jsDies kommuniziert via MCP über stdio. Verwenden Sie einen MCP-Client zur Interaktion oder leiten Sie einen JSON-RPC-Handshake manuell für das Debugging weiter.
MCP-Einrichtungsanleitung: https://www.iletimerkezi.com/docs/mcp (TR) · /en/docs/mcp (EN)
Authentifizierung: https://www.iletimerkezi.com/docs/api/authentication
Fehlercodes: https://www.iletimerkezi.com/docs/api/error-codes
Manifest (maschinenlesbar): https://www.iletimerkezi.com/api/manifest.json
Versionshinweise: CHANGELOG.md
MIT — siehe 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.
v1.0.0add_blacklistcancel_orderdelete_blacklistget_balanceget_blacklistget_reportget_reportsget_senderiys_checkiys_registersend_smsScored across 11 tools
Each 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.
Read Messente balance, prices, delivery status and statistics; send SMS to up to 10 numbers.
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.
Polish SMS & voice gateway: send SMS/TTS, contacts, blacklist, tracked links, replies, reports.
