IranTools (paid)

jalali_to_gregorian

Origin URL: https://irantools.johnaio281.workers.dev Origin hostname: irantools.johnaio281.workers.dev Origin brand: IranTools - paid MCP server for AI agents Provider aliases: Jalali to Gregorian, Persian to Western date Family key: irantools.johnaio281.workers.dev::persian Endpoint: POST /api/iran/jalali_to_gregorian Summary: Convert a Jalali (Solar Hijri) date to the Gregorian calendar. Keyword: jalali to gregorian Keyword: shamsi to gregorian Keyword: persian date to western date Keyword: solar hijri conversion Use case: convert a Persian date such as 1404-12-29 to a Gregorian date Use case: find what March date a Persian date falls on Use case: convert a Jalali lease expiry to a standard date Source description: Convert a Jalali (Solar Hijri) date to the Gregorian calendar. Auth mode: paid

Price: $0.003 per call (USDC on Base via x402, or USDC on Tempo via MPP).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>",
      "month": "<month>",
      "day": "<day>"
    },
    "name": "jalali_to_gregorian"
  }
}

Input Schema

Name	Required	Description	Default
`day`	Yes
`year`	Yes
`month`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does disclose genuinely important behavior: 'Auth mode: paid' with a per-call price and payment rails (x402/USDC, MPP), which an agent must know before invoking. However, it says nothing about error handling for invalid dates, output format, or rate limits, so the behavioral picture is only partially covered.

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

Conciseness2/5

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

The body is dominated by machine-generated boilerplate — Origin URL, Origin hostname, Origin brand, Provider aliases, Family key, Endpoint — that has no bearing on tool selection, plus four repeated Keyword lines that restate the summary. The one useful sentence (Summary) is buried mid-block rather than front-loaded.

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?

For a simple three-parameter conversion with no output schema, the description covers purpose, examples, and billing. It omits parameter bounds and, because there is no output schema, never states what the return value looks like (e.g. an ISO Gregorian date), which is the main remaining gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for three required numeric parameters (year, month, day). The example '1404-12-29' implicitly maps to year=1404, month=12, day=29, which is modest help, but no ranges, bounds, validation rules, or note on whether year is a full Jalali year are given. The description does not compensate for the total schema-coverage gap.

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 Summary line states a specific verb and resource: 'Convert a Jalali (Solar Hijri) date to the Gregorian calendar.' The direction is unambiguous even without an explicit contrast to the sibling gregorian_to_jalali, so the agent can distinguish them by the stated direction. It is clear but not actively differentiated from siblings.

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?

Three use cases are given ('convert a Persian date such as 1404-12-29', 'find what March date a Persian date falls on', 'convert a Jalali lease expiry'), which implies when to reach for this tool. There is no statement of when NOT to use it, no mention of the inverse sibling, and no input-validation guidance (e.g. valid Jalali month range), so usage is only implied.

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

All IranTools (paid) tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?