Skip to main content
Glama

Validate a Turkish tax number (VKN) or national ID (TCKN)

dogrula_vergi_no
Read-onlyIdempotent

Validates by length: 10 digits = company tax number (VKN), 11 digits = personal ID number (TCKN) used by sole traders; returns the type and whether the check digits are correct. Algorithmic only: it does not query any registry or say whether the taxpayer is active.

Endpoint: GET /v1/dogrula/vergi-no. Available on all plans, including free. Costs 1 request unit per call. Read-only; JSON in Turkish with source and guncelleme (updated at) fields.

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": {
      "no": "<no>"
    },
    "name": "dogrula_vergi_no"
  }
}

Input Schema

NameRequiredDescriptionDefault
noYes10-digit VKN or 11-digit TCKN, digits only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: length-based type detection, that only check digits are verified, that no registry is consulted, the response language and 'guncelleme' field, plan availability, and a per-call cost of 1 request unit. That is exactly the operational context an agent needs before calling.

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

Conciseness4/5

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

The core rule and the algorithmic-only caveat are front-loaded and waste no words. The trailing endpoint/plan/cost block is useful but reads as boilerplate and slightly dilutes the strongest opening sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 carries the full burden of describing returns, and it does: type plus check-digit validity, JSON in Turkish with source and update timestamp. For a one-parameter tool of this complexity, nothing an agent needs is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning the schema lacks: it explains what VKN and TCKN actually are ('company tax number', 'personal ID number used by sole traders') and ties each length to an identifier type. The only gap is that the returned 'type' values are not spelled out.

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 opens with a specific verb and resource: 'Validates by length: 10 digits = company tax number (VKN), 11 digits = personal ID number (TCKN)'. It also disambiguates from the sibling validators (iban_dogrula, telefon_bilgi) by naming exactly which identifier types it handles and what it returns.

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?

Usage context is clear: call it to check VKN/TCKN check digits, and the explicit exclusion 'does not query any registry or say whether the taxpayer is active' tells the agent when this tool is the wrong choice. It stops short of naming a specific alternative sibling for registry lookups, so it is clear but not fully routed.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources