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., "@io.github.olzhas-raiganiyev/goszakup-mcp check whether BIN 990140000123 is a valid Kazakh identifier"
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.
MCP server for Kazakhstan public procurement data (goszakup.gov.kz), with an open evaluation of how well LLMs use it.
Status: pre-alpha. Only offline tools work today. Procurement tools arrive with access to the official open-data API.
mcp-name: io.github.olzhas-raiganiyev/goszakup-mcp
Tool | What it does |
| Validates a 12-digit BIN/IIN: format and check digit. Offline. |
| Shows the version and whether the server uses mock or live data. |
All tools are read-only and return structured output with a JSON schema. The server speaks MCP revision 2026-07-28 and still serves older clients.
Related MCP server: GET4AGENT MARKET
uv sync
uv run goszakup-mcp # stdio
uv run goszakup-mcp --transport streamable-httpClaude Desktop (claude_desktop_config.json), from a local checkout:
{
"mcpServers": {
"goszakup": {
"command": "uv",
"args": ["--directory", "/path/to/goszakup-mcp", "run", "goszakup-mcp"]
}
}
}Variable | Default | Meaning |
|
|
|
| — | Token for the official API, issued by the Ministry of Finance of Kazakhstan. Required when |
Never commit a token. .env is git-ignored and CI scans every push with gitleaks.
uv sync
uv run pytest --cov # unit + end-to-end over both protocol modes
uv run ruff check . && uv run ruff format --check . && uv run mypy
uv run pre-commit installTool schemas are snapshot-tested. After an intended change: UPDATE_SNAPSHOTS=1 uv run pytest -k snapshot.
Design decisions live in docs/adr/.
MIT
Check that a Kazakhstan BIN or IIN has 12 digits and a correct check digit.
Works offline. Use it before looking up a company or person by identifier.
Inputs: value (required). Returns: Result of validating a BIN or IIN.
Report the server version and whether it serves mock or live procurement data.
Inputs: no named parameters. Returns: What this server instance is connected to.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 2 tools
check_bin validates an identifier while server_status reports runtime metadata; the two purposes have zero overlap. An agent can pick the right tool without any description ambiguity.
Both names are snake_case and readable, but check_bin follows a verb_noun pattern while server_status is a noun phrase. Minor stylistic deviation rather than a real inconsistency.
Two tools is far too thin for a Kazakhstan procurement server, especially since one slot is consumed by a generic status/health tool. The surface feels like a stub rather than a scoped feature set.
There are no procurement operations at all: no company lookup, no lot/tender search, no contract or award retrieval. check_bin's own description tells the agent to use it 'before looking up a company or person by identifier', but no such lookup tool exists, creating an explicit dead end.
Validation suite: EU VAT (VIES), IBAN mod-97, email (MX+disposable), geo place lookup, VIN decode.
Offline IBAN/BIC/EU VAT/card/ISBN/GTIN validators + live USD stablecoin peg-health verdict.
IBAN, ISIN, VAT/tax ID, GTIN validation; timezone, geo, text, chain utilities. Pay per call
Checksum validation of Turkish IBANs, tax numbers (VKN) and national IDs (TCKN). Nothing stored.
