A
licenseNot graded
qualityD
maintenanceValidates Indian GSTIN numbers with structural checks, embedded PAN extraction, state-code lookup, and mod-36 check character validation, all via local compute.
MIT
china-usci-mcp
by zbl1998-sdjn
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., "@china-usci-mcpValidate this Unified Social Credit Identifier: 91330100799655058B"
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.
china-usci-mcp
MCP server for checking the Unified Social Credit Identifier (USCI) — the 18-character code printed on a mainland China business licence.
Offline. Zero network calls. It tells the model what a passing code establishes, and, on every response including failures, what it does not.
Why this exists
Ask an assistant "is this Chinese supplier real?" and, without a tool, it will reason from the shape of the string and sound confident. That is the worst possible failure mode for this particular question, because the person asking is usually about to send money.
There is exactly one thing that can be established about a USCI without contacting anyone: whether the code is internally consistent. The final character is a check character over the first 17, defined by GB 32100-2015, computed mod 31 over a 31-character alphabet that deliberately excludes I, O, Z, S and V. A mistyped digit, a transposed pair, or a fabricated code will usually fail that check.
This server exposes that one fact, and refuses to let it grow into anything larger.
Related MCP server: veridigit
Install
npm install -g china-usci-mcpOr run it without installing:
npx china-usci-mcpClient configuration
{
"mcpServers": {
"china-usci": {
"command": "npx",
"args": ["-y", "china-usci-mcp"]
}
}
}Tools
validate_usci
Input: code — the identifier as printed. Whitespace, full-width spaces, hyphens and lower case are tolerated.
Returns whether the code is well formed, decodes its segments (registering authority, entity category, administrative division, subject identifier, check character), and states the boundary.
VALID FORMAT: 91330100799655058B
Segments:
Registration authority code: 9 — Market regulation (工商)
Entity category code: 1 — Enterprise (企业)
Administrative division code: 330100 — Registered in Zhejiang.
Subject identifier (organization code): 799655058
Check character: B
What this establishes:
- The 18 characters are internally consistent, so the code was transcribed correctly.
- The code is formatted as GB 32100-2015 requires.
What this does NOT establish, in any outcome:
- That the company exists. A correctly formed code can be invented.
- That the company is still active rather than revoked or deregistered.
- That its registered business scope covers what you are buying.
- That it may legally export to you. Export eligibility turns on the registered
scope and customs registration, neither of which is encoded here.
- That the company on this code is the same one issuing your invoice or
receiving your payment.A wrong check character reports the expected and actual characters, so a transcription error can be found rather than merely flagged.
usci_check_character
Input: first17. Computes the character the 18th position should hold. Use it when checking a code copied off a photographed licence.
What this cannot do
It queries no registry. It cannot tell you that a company exists, is currently registered, is in good standing, does what it claims, or is safe to pay. A well-formed code that belongs to nobody is still a well-formed code.
For the record itself you need the official source — and getting there from outside mainland China is its own problem. We measured eight official Chinese verification portals from public vantage points abroad: the national enterprise credit system (GSXT) answered none of the overseas nodes tested. Methodology and per-node data: currawongweb.com/verify/china-official-source-availability/, with the underlying datasets on Harvard Dataverse under DOIs and a mirror on Hugging Face.
Related
china-usci— the underlying library and CLI, which this server wrapsBrowser version of the same check — no install, no account
Licence
MIT. Built by Currawong, which also sells supplier verification reports — stated plainly, since you are being asked to run our code.
Available Tools
2 toolsusci_check_characterA
Compute the expected check character for the first 17 characters of a Unified Social Credit Identifier. Use when verifying a transcription: compute what the 18th character should be and compare it with what is printed. Offline; queries nothing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| first17 | Yes | The first 17 characters of the identifier. |
TDQS
A3.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does state 'Offline; queries nothing,' which clarifies that no network calls are made, and implies it is a pure computation. However, it does not describe edge cases, error handling, or output format, leaving some ambiguity for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and includes a practical use-case hint. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pure-function tool with no output schema, the description implies the return value (the expected check character) without explicitly stating its type. It covers the offline behavior and intended usage, which is largely sufficient. Missing details like return type or error conditions are minor for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter first17, so the baseline is 3. The description adds a slight clarification by mentioning 'first 17 characters' and 'Unified Social Credit Identifier,' which aligns with the schema. No additional syntax or constraints are added beyond what the schema already states.
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 description clearly states the tool computes the expected check character for the first 17 characters of a USCI. It is specific about the verb and resource, and the purpose is unambiguous. However, it does not explicitly differentiate itself from the sibling tool validate_usci, though the use-case hint ('verifying a transcription') indirectly suggests its distinct role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use scenario: 'Use when verifying a transcription: compute what the 18th character should be and compare it with what is printed.' It does not mention when not to use it or alternatives, but the context is sufficient for an agent to select this tool over the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_usciA
Check whether an 18-character Unified Social Credit Identifier (USCI/USCC) from a mainland China business licence is well formed, and decode its segments. Offline arithmetic check per GB 32100-2015: verifies the character set and the mod-31 check character, and reports the registering authority, entity category and administrative division encoded in the code. Returns explicitly what a passing code does and does not establish. Does NOT query any registry and does NOT prove the company exists, is active, or is trustworthy.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | The identifier as printed on the licence. Whitespace, full-width spaces, hyphens and lower case are tolerated. |
TDQS
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states that the check is offline, arithmetic, and does not query registries, and it clarifies what a passing code does and does not establish. This is transparent and goes beyond mere schema information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and each sentence contributes meaningfully. It avoids redundancy and clearly organizes the check logic, decoded segments, and limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, full schema coverage, and no output schema, the description explains what the tool returns conceptually (registering authority, entity category, administrative division) and what it establishes. However, it does not specify the exact return structure or field names, which could be helpful for an agent consuming the result. This is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the code parameter well (tolerances for whitespace, full-width spaces, hyphens, lower case). The tool description adds the '18-character' length constraint and the context of a mainland China business licence, providing value beyond the schema. Baseline 3 is raised to 4 due to this added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool's function: checking well-formedness of an 18-character USCI and decoding its segments, citing the standard (GB 32100-2015). It clearly differentiates itself from the sibling (usci_check_character) by covering full validation and decode, not just the check character. The 'does NOT query any registry' clause further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it (offline arithmetic validation) and explicit exclusions (does not prove existence, activity, or trustworthiness). However, it does not explicitly name the sibling tool as an alternative, though the sibling's name implies it. The guidance is sufficient but not maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
usci_check_character - First observed
validate_usci
TDQS
A4.1/5.0
Scored across 2 tools
Disambiguation5/5
validate_usci performs full validation and decoding of an entire USCI, while usci_check_character computes only the check character for a partial code. Their purposes are clearly separated, with no practical confusion between validating a complete code and verifying a single digit.
Naming Consistency3/5
The names follow different structural patterns: validate_usci is verb-noun, while usci_check_character is noun-noun (or noun-verb-noun) and reads more like an object than an action. Although both consistently use lowercase 'usci', the lack of a uniform verb-first convention prevents a higher score.
Tool Count4/5
With only two tools, the server is slightly below the typical 3-15 range, but it targets a very narrow domain (offline USCI validation). Each tool has a distinct and necessary role, so the count feels reasonable even if minimal.
Completeness5/5
The server covers the core operations needed for offline USCI processing: full validation/decode and check-character computation. It explicitly declares it does not query registries, so the lack of a lookup tool is an intentional boundary rather than a gap, making the surface complete for its stated purpose.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Validates Luhn, IBAN, ISBN, EAN/UPC, SWIFT/BIC, and EU VAT checksums and formats.
Checksum validation for AI agents: IBAN, ISBN, EAN/GTIN, UUID, ULID. Deterministic, no auth.
Verify Japanese companies, invoice-issuer registrations and addresses against government open data.
Verify a company on GLEIF LEI and SEC EDGAR, screen sanctions. No key; quota-free data.
Related MCP Servers
- AlicenseAqualityDmaintenanceVerified validation of structured identifiers — IBAN, payment cards, ISBN-13 and VIN — for AI agents. Runs the real checksum algorithms (mod-97, Luhn, mod-10, ISO 3779) instead of letting the model guess, and returns structured results with clear errors.425 npmApache 2.0
- AlicenseNot gradedqualityBmaintenanceProvides a Luhn check-digit validation tool for numeric strings such as credit cards, IMEI, and national IDs.7 npmMIT
- AlicenseNot gradedqualityBmaintenanceValidates VAT number formats for EU, UK, Switzerland, and Norway.6 npmMIT