Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rrk-mcp What are the newest laws published in the Official Gazette?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
rrk-mcp is an unofficial, read-only MCP server for the laws and regulations database of the Official Gazette of Iran (rrk.ir). Its 5 tools list the newest laws, search them by title, full text, group, approver, special issue number or gazette date, read the full text of a law, court ruling or regulation, and list the licensed exchange offices. No API key or account is needed.
For AI agents · Quick start · Tools · Limits · فارسی
What: unofficial MCP server for rrk.ir, the Official Gazette: laws (قوانین), regulations (آیین‌نامه، مصوبات), Court of Administrative Justice rulings (آرای دیوان عدالت اداری) and other texts published in the gazette since 1285 (2026 = 1405).
Install: uvx rrk-mcp or claude mcp add rrk -- uvx rrk-mcp. Transport: stdio. Needs uv (Python 3.10+).
Auth: none. Optional RRK_MCP_PROXY (HTTP proxy URL); system proxy settings are ignored.
Access: read-only; no confirmation is needed before calling any tool.
Tools: 5, all prefixed rk_. Typical sequence: rk_law_filters (optional) -> rk_search_laws -> rk_law_text.
Use when: the user asks what the gazette published lately, wants a law or ruling by topic or date, or needs the text of one.
Do not use when: the user wants company registration notices (founding, capital change, board change, liquidation). rrk.ir does not offer those in an open search, so this server cannot look companies up.
Output: compact JSON, Persian text. Dates are Jalali (1405/08/09).
Related MCP server: qavanin-mcp
claude mcp add rrk -- uvx rrk-mcpAny other client: run uvx rrk-mcp as a stdio MCP server ({"command": "uvx", "args": ["rrk-mcp"]}).
Tool | What it does |
| List the newest laws, rulings and regulations in the Official Gazette, newest first |
| Search laws by title words, full-text words, law group, approver, special issue number or Jalali gazette date range |
| List the law groups (categories) and approving authorities to filter by |
| Read one law's approver, gazette number and date, and full text (long texts in parts) |
| List the licensed currency exchange offices (location, phone, address; a field the portal leaves empty is null) by province and city |
All 5 tools are annotated readOnlyHint: true.
Laws only. Company notices (آگهی‌های ثبتی) sit behind rrk.ir's paid data service and login, so they are left out.
The portal is slow (a full-text search can take 10 seconds) and shares one session; the server keeps one session and reuses it.
rk_law_text works with any code, but a code the session has not listed is located by paging the list (10-60 s, and codes below about 10,000 may not be found). Majlis debates (group 64) have a title only; the debate text is a PDF behind login.
Gazette PDFs and the shop need login or payment, and are left out.
Persian ی and ک are converted to the Arabic ي and ك the portal stores; you can type either.
uv sync
uv run ruff check . && uv run ruff format --check .
uv run python -m pytest -q
uv run python -m pytest -m live -qrrk-mcp یک سرور MCP غیررسمی و فقط‌خواندنی برای پایگاه قوانین و مقررات روزنامه رسمی (rrk.ir) است: فهرست جدیدترین قوانین، جستجو بر اساس عنوان، متن، شماره ویژه‌نامه و تاریخ روزنامه، فیلتر بر اساس گروه قوانین و مرجع تصویب، خواندن متن کامل قانون یا رأی، و فهرست صرافی‌های مجاز بانک مرکزی. جستجوی آگهی‌های ثبتی شرکت‌ها در سایت به‌صورت باز وجود ندارد و پشتیبانی نمی‌شود.
Made by Sepehr Radmard (سپهر رادمرد) · github.com/sepehr071 · linkedin.com/in/sepehr-radmard
List the licensed currency exchange offices (صرافی مجاز) the Central Bank published in the Official Gazette (rrk.ir).
Use to see where licensed exchange offices are or to find one's address and phone. Filter by province and
city (Persian names; an unknown province is an error that lists the valid ones). Returns total, more
and up to 50 offices with province, city, district, phone, postal_code and address. Office names are not
published, only the location.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name as on the site, e.g. 'قم', 'سلفچگان'. Empty = whole province. | |
| page | No | Page number, 50 offices per page. | |
| province | No | Province name as on the site, e.g. 'تهران', 'قم'. Empty = all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing the page cap (up to 50 offices), the `total`/`more` pagination signals, the exact returned fields, the error behavior for an unknown province, and the data limitation that office names are not published. That last point in particular prevents a wrong expectation about the result set.
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 tight paragraphs: what it is, when to use it plus filtering behavior, then the return shape. Every sentence carries information an agent needs, and the identification of the resource is front-loaded.
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?
With no output schema, the description compensates by enumerating return fields and pagination semantics, and it flags the notable absence of office names. Nothing needed to call or interpret this tool correctly is missing.
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 coverage is 100%, so the baseline is 3; the description adds real meaning on top by specifying that province/city values must be Persian names and that an invalid province raises an error enumerating valid values. It does not explain the `page` parameter's 200-page ceiling, which the schema covers anyway.
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?
States a specific verb and resource ('List the licensed currency exchange offices') plus the authoritative source (Central Bank, Official Gazette, rrk.ir). This is unmistakably distinct from the sibling law-retrieval tools.
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?
Gives explicit usage context: 'Use to see where licensed exchange offices are or to find one's address and phone.' It does not name when-not-to-use or an alternative, but the sibling set (law search tools) is unrelated enough that no routing conflict exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the newest laws, rulings and regulations published in the Official Gazette (rrk.ir), newest gazette first.
Use for "what was published in the gazette lately". Each law has a code; pass it to rk_law_text for the
full text. To narrow by topic or date use rk_search_laws.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 20 laws per page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior. The description adds useful context beyond that: newest gazette first ordering and the `code` handoff to rk_law_text, though it does not describe pagination or other return fields beyond `code`.
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 compact and front-loaded: purpose first, then usage context, then chaining and alternatives. Every sentence earns its place with no redundant wording.
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 one-parameter list tool with annotations and no output schema, the description supplies enough to call it correctly, understand ordering, and chain results via `code`. Pagination details are already covered by the input schema.
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?
There is only one optional `page` parameter and schema description coverage is 100%, with the schema documenting page number, bounds, and 20 laws per page. The description adds no additional parameter meaning, so the baseline 3 applies.
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?
States a specific verb ('List') and resource ('newest laws, rulings and regulations') published in the Official Gazette, including ordering. It explicitly distinguishes itself from rk_search_laws and rk_law_text by naming when each sibling applies.
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?
Gives a direct use case ('what was published in the gazette lately'), names rk_search_laws for narrowing by topic or date, and tells the agent to pass a law's `code` to rk_law_text for full text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the law groups (categories) and approving authorities that rk_search_laws can filter by.
Use first when the user asks for one kind of document (court rulings, cabinet decrees, regulations, Majlis
debates) or one issuing body. Pass a group id or an approver code (or their name words) to
rk_search_laws as group or approver. Groups are two levels deep: parent is set on sub-groups.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Name words to narrow the lists, e.g. 'دیوان' or 'مالیات'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so safety is covered. The description adds useful structural context (groups are two levels deep, `parent` marks sub-groups) but says nothing about list size, pagination, or whether both lists are always returned. With annotations carrying the safety profile, a 3 is appropriate.
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?
It is front-loaded with the purpose, then the usage rule, then the handoff instruction, with no filler sentences. The parenthetical lists are dense but each one earns its place by giving concrete trigger examples; slightly tighter phrasing would earn a 5.
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 single-parameter, read-only lookup tool with full schema coverage and no output schema, the description covers purpose, trigger conditions, the id/code handoff, and the parent/sub-group hierarchy. An agent has everything needed to call it correctly and use its results.
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 coverage is 100%, so the single `query` parameter is already documented with examples. The description goes slightly beyond the schema by explaining what the output values are for: the returned `id`/`code` (or name words) are meant to be passed to rk_search_laws as `group` or `approver`, which clarifies the semantics of the results.
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 states a specific verb and resource: it lists law groups (categories) and approving authorities. It also names the sibling it feeds into (rk_search_laws) and clarifies the two-level parent/sub-group structure, so the agent can distinguish it from rk_search_laws and rk_latest_laws.
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?
It gives explicit when-to-use guidance ('Use first when the user asks for one kind of document... or one issuing body') and names concrete triggers (court rulings, cabinet decrees, regulations, Majlis debates). It also states the downstream action: pass a group id or approver code to rk_search_laws as `group` or `approver`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full text of one law or ruling from the Official Gazette (rrk.ir): approver, gazette number and date, body.
Use after rk_search_laws or rk_latest_laws with a law's code. A code that this session has not listed yet
is located by paging through the newest-first list (slow: 10-60 s, older laws may not be found). Long texts
are cut at max_chars; call again with offset = the returned next_offset to continue.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Law code (number) from rk_search_laws or rk_latest_laws. | |
| offset | No | Character to start from, to read long texts in parts. | |
| max_chars | No | Most characters to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and open-world safety, and the description adds the behavioral details they cannot: a 10-60 s paging cost with a possible not-found outcome for older laws, truncation at `max_chars`, and the resumption protocol via `offset`/`next_offset`. These are the exact performance and failure traits an agent needs before committing to the call.
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 sentences, front-loaded with the purpose before the prerequisite and the cost caveat. Every clause carries information: source, fields, prerequisite, slow-path warning, pagination protocol.
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?
There is no output schema, so the description must explain return values, and it does: approver, gazette number and date, body, plus the `next_offset` field used for pagination. Combined with the slow-path caveat, an agent has everything needed to call this correctly and handle partial results.
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 coverage is 100%, so baseline is 3, but the description adds real meaning: it explains that `offset` should be set to the returned `next_offset` to continue reading, and that `max_chars` causes truncation. That continuation contract is not stated in 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?
States a specific verb and resource (read the full text of one law/ruling) plus the source (Official Gazette, rrk.ir) and enumerates the returned fields: approver, gazette number and date, body. It is clearly distinct from rk_search_laws and rk_latest_laws, which only list laws.
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 says to use it after rk_search_laws or rk_latest_laws and to supply a law's `code`, naming the alternatives that produce that code. It also covers the edge case where a code was never listed, warning that lookup pages through the newest-first list, is slow (10-60 s), and may fail for older laws.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Official Gazette's laws and regulations database (rrk.ir) by title, full text, group, approver, special number or gazette date.
Use to find a law, regulation, Court of Administrative Justice ruling or Majlis approval. All filters are
optional and combined; with none it lists the newest. Gazette dates are Jalali (1405 = 2026). group and
approver take an id or name words (see rk_law_filters). Returns total, more and up to 20 laws with
code; pass a code to rk_law_text to read the text. This covers laws only: company registration notices
(founding, capital, board, liquidation) are not openly searchable on rrk.ir.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 20 laws per page, newest gazette first. | |
| text | No | Words inside the law's full text (slower than title search). | |
| group | No | Law group (category) id or name words from rk_law_filters, e.g. 'آرای هیات عمومی دیوان عدالت اداری' or '3'. A top-level group includes its sub-groups; id 64 is the Majlis debates. | |
| title | No | Words in the law's title, Persian (e.g. 'ماليات', 'ديوان عدالت اداري'). | |
| to_date | No | Gazette date to, Jalali YYYY/MM/DD, inclusive. | |
| approver | No | Approving authority (مرجع تصویب) code or name words from rk_law_filters, e.g. 'دبیر هیات دولت'. | |
| from_date | No | Gazette date from, Jalali YYYY/MM/DD, e.g. '1405/08/01'. | |
| special_no | No | The special issue number (شماره ویژه), e.g. '2301'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, yet the description still adds real behavior: no-filter default (newest first), 20 results per page, a performance caveat that full-text search is slower than title search, and Jalali date semantics (1405 = 2026). It also discloses the return shape ('total', 'more', up to 20 'laws' with 'code') despite there being no output schema.
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 short blocks, front-loaded with the resource and searchable facets, followed by usage, then result/next-step guidance. Every sentence carries information — the exclusion note, the Jalali hint, and the code-to-rk_law_text handoff all change agent behavior.
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 an 8-parameter, no-required-parameter search tool with no output schema, the description supplies the missing pieces: default behavior with zero filters, page size, return fields, and the follow-up call for full text. Nothing essential to correct invocation is absent.
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 coverage is 100%, so baseline is 3; the description earns above that by clarifying that group and approver accept either an id or name words, that all filters are optional and ANDed, and that gazette dates are Jalali with a year-mapping example. It adds little on special_no or page beyond what the schema already says.
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?
Opens with a specific verb+resource ('Search the Official Gazette's laws and regulations database (rrk.ir)') and enumerates the searchable facets (title, full text, group, approver, special number, gazette date). It also draws a hard boundary: 'This covers laws only: company registration notices ... are not openly searchable,' which lets an agent rule the tool out for a whole class of queries.
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?
Gives a clear when-to-use list ('find a law, regulation, Court of Administrative Justice ruling or Majlis approval') and routes to siblings for two follow-on needs: rk_law_filters for group/approver ids and rk_law_text to read a law's text. It does not address rk_latest_laws, even though it states that with no filters the tool 'lists the newest' — the exact overlap an agent would need resolved.
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.
v0.1.2rk_exchange_officesrk_latest_lawsrk_law_filtersrk_law_textrk_search_lawsScored across 5 tools
rk_search_laws, rk_law_filters, rk_law_text and rk_exchange_offices each target a clearly different operation (query, taxonomy lookup, full-text read, unrelated office directory). The only overlap is rk_latest_laws, which is effectively rk_search_laws with no filters and newest-first sorting, though the descriptions do flag that relationship so an agent can recover.
All tools share an 'rk_' prefix and snake_case, giving a predictable namespace. Minor deviation: some names are verb-first (rk_search_laws, rk_latest_laws) and others noun-first (rk_law_text, rk_law_filters, rk_exchange_offices), but the resource is still obvious in each.
Five tightly scoped tools for a single read-only domain (Iranian Official Gazette) is lean and each has a defensible role. The only near-redundant one is rk_latest_laws, which could arguably be folded into rk_search_laws.
Reading laws, discovering filter values, listing latest and browsing exchange offices covers the core browse workflow, and the descriptions honestly disclaim excluded content (company registration notices). However there is no direct fetch-by-code or explicit pagination parameter, and the stated fallback for unlisted codes (paging the newest-first list, 10-60 s, older laws may be unfindable) is a real dead end.
Web scraping and Iranian-web data tools for AI agents: JS rendering, proxies, Markdown output.
Persian and Iranian utilities for agents: Jalali dates, national ID, IBAN, holidays. Paid via x402.
95,000+ articles of Iranian law, a legal glossary and 8 Iranian legal calculators. Free.
Persian and Iranian utilities for agents plus text tooling. Paid via x402 or MPP.