newdb
OfficialServer Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Most tools target distinct registries: bankruptcy, passport, FSSP, EGRUL, and FNS block checking are clearly scoped. The two complex_check tools intentionally overlap these simple checks, but their names and descriptions make the aggregation purpose obvious, so an agent should rarely select the wrong one.
Naming Consistency5/5All tools follow a consistent `newdb_<verb>_<target>` pattern, using `check_` for registry lookups and `get_` only for the plainly different balance operation. Prefixes and underscore separators are uniform, making the tool names predictable and easy to navigate.
Tool Count5/5Eight tools is a well-scoped set for a registry-checking server: enough specific checks to cover major resources without overwhelming an agent. Each tool earns its place, especially the two aggregate checks that reduce the need to invoke many simple checks manually.
Completeness4/5The set covers the core domain well: person checks, legal entity checks, debt/bankruptcy/account-block checks, and an aggregate version for each side. It is missing some standalone variants such as a direct court-case-only check or simple INN lookup, but those are bundled into the complex checks, so the main workflows are still supported.
Average 3.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to provide behavioral context. The description simply says 'check', implying read-only operation, but does not disclose what results are returned, whether it validates INN format, or any side effects. Since the description carries the full burden, this is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It efficiently conveys the core purpose and data source in under 20 words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to explain what the tool returns (e.g., a boolean, a list of records, or a count). For a check tool, this missing information could lead to incorrect assumptions about the result format, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'inn' is fully described in the JSON schema (individual: 12 digits, company: 10 digits), achieving 100% coverage. The description adds no extra meaning beyond what the schema already states, so it meets the baseline but doesn't enhance it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (check) and the resource (bankruptcy records for individuals/companies), and specifies the data source (Fedresurs/EFRSB). This distinguishes it from sibling tools that check other types of records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to prefer this tool over its siblings (e.g., newdb_check_fssp, newdb_check_egrul). The description only states what it does without indicating context or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states a 'check' is performed, but does not indicate whether the operation is read-only, if it has side effects, requires special permissions, or describes the response format. For a tool without annotations, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the purpose without redundancy. It is front-loaded and concise, with no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and lacks annotations, so the description should explain the expected return value and any prerequisites. It only says 'check validity' without clarifying what the result looks like (e.g., boolean, status message). For a tool with four required parameters and no output schema, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive parameter explanations (e.g., '4-digit passport series', 'Last name in Russian'). The description adds no parameter-specific detail beyond the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check Russian internal passport validity via official MVD registry database.' It specifies the verb 'Check' and the resource (passport validity), making it distinct from sibling tools that check other domains (bankruptcy, FSSP, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or mention alternatives. It implies usage for passport validation, but there is no discussion of exclusions or comparison to other tools. The context is clear but not explicit, falling short of strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mention 'aggregates', implying multiple backend calls and a combined result, which is useful. However, it does not communicate whether the operation is read-only, potentially slow, likely to partially fail, or whether specific permissions are required. For a tool that queries government databases, this lack of context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the tool's purpose and scope without any filler. Every word contributes to the user's understanding, making it an excellent example of concise and structured communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is under-specified. It does not cover what the user can expect in the response (e.g., raw data, summarized findings, pagination), how to interpret results from multiple sources, or whether failures are isolated. For a 'comprehensive' check, the description should set expectations about the returned data or reference an output schema, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all six parameters with 100% coverage (e.g., 'Date of birth YYYY-MM-DD (optional)'). The description adds the phrase 'by passport', which clarifies that 'seria' and 'number' refer to a Russian passport, but does not explain the role of optional fields like 'dob' or 'secondname' in the comprehensive search. The description neither enhances nor hinders understanding beyond the schema, matching the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Comprehensive background check for Russian citizen by passport' with a specific verb ('check'), a defined resource ('Russian citizen'), and a method ('by passport'). It further differentiates itself from siblings by listing aggregated sources ('FNS INN, MVD passport, FSSP debts, bankruptcy, courts, pledge'), making it distinct from single-purpose tools like newdb_check_fssp or newdb_check_bankrot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicitly stated. The word 'comprehensive' and the list of aggregated sources suggest this should be used when a multi-faceted check on a person is needed, while sibling tools handle individual checks. However, there is no explicit 'use this when' or 'use this instead of' guidance, and no mention of when not to use it (e.g., for companies, which is covered by newdb_complex_check_company).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility for disclosing behavior. It only states the purpose without mentioning that this is a read-only query, what data source is used, or any responses or side effects. This is inadequate for a tool with no structural metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the tool's purpose without any wasted words. It is appropriately sized for the simple nature of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description is minimally sufficient but leaves gaps: it does not specify what the check returns, any edge cases, or whether it requires live access. Completeness is adequate but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters (INN and BIK) with 100% coverage, so the description need not add more. However, it adds no additional context about how these parameters influence the check, keeping it at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks bank account suspension decisions by Russian Federal Tax Service (FNS BIKP), distinguishing it from sibling check tools like newdb_check_bankrot or newdb_check_egrul. The verb 'check' and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies usage for FNS block checks, but the description provides no explicit guidance on when to choose this tool over alternatives or any prerequisites. It neither names alternative tools nor states exclusions, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the check action and does not disclose return format, operational side effects (though likely read-only), rate limits, or any prerequisites. Beyond the core purpose, no behavioral details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action and resource. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters and no output schema, the description covers the domain but omits details like return format, error scenarios, or regional scope limitations. The schema covers parameter details, but the description does not fully round out the tool's usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each of the five parameters documented (e.g., DOB format, Russian names, regioncode default, optional patronymic). The description adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resource 'FSSP registry' and the content ('open enforcement proceedings, debts, and fines'). This clearly differentiates it from sibling tools like bankruptcy or passport checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to check FSSP enforcement proceedings for a person, but it provides no explicit when-to-use guidance or comparisons with sibling check tools. It lacks exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the aggregated data sources, which is helpful context, but does not mention read-only nature, limitations, error conditions, or any side effects. For a read-only check tool, this is a moderate gap but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose and aggregated sources. Every word earns its place, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of aggregating multiple data sources and the absence of an output schema, the description does not explain the response structure, how results are presented, or potential caveats (e.g., missing data). This is a significant omission for an agent needing to interpret the tool's output in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already contains a full description of the 'inn' parameter ('10-digit company INN') with 100% coverage. The description adds no further semantic details beyond what the schema states, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a comprehensive background check for legal entities using INN, explicitly listing the aggregated sources (EGRUL, FNS account blocks, arbitration courts, bankruptcy, FSSP debts). This distinguishes it from sibling tools that target individual data sources or individuals (newdb_complex_check_person).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for comprehensive company verification, but it does not explicitly mention when to prefer this over individual check tools (e.g., newdb_check_egrul) or when a simpler check would suffice. No exclusions or alternatives are named, but the scope is clear enough for basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' implies a read-only operation, but it doesn't disclose any additional behavioral details such as error handling, rate limits, or coverage limitations. It is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the core purpose and data sources without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-oriented tool with two parameters and no output schema, the description covers the essential context: what data is returned and from where. It lacks edge-case behavior, but the simplicity and schema completeness make it adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, including detailed descriptions for INN and OGRN formats. The description adds no extra parameter information, so it falls at the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('full legal entity data') with specific data points (founders, director, authorized capital, status). It also names the data sources (EGRUL and Transparent Business), distinguishing it from sibling tools focused on balance, bankruptcy, or passport checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need legal entity data from EGRUL. No explicit alternatives or exclusions are given, but the scope is unambiguous given sibling tool names that cover different checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 and does convey the read-only nature ('balance') and scope ('on NewDB API token'). However, it omits useful behavioral details such as whether the check consumes quota, what 'balance' means (daily/monthly reset), or any rate-limit implications, which would be valuable for a billing-related endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-crafted sentence with no filler or redundancy. Every word adds value, and the key information ('remaining request balance', 'NewDB API token') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description covers the essential aspects of what the tool does. While it could specify the response format or the meaning of 'balance', the low complexity means the description is nearly sufficient on its own for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, making it self-contained. The description adds the necessary context that the tool operates on the authenticated API token, effectively compensating for the lack of parameters. A score of 4 aligns with the baseline for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Check') with a clear resource ('remaining request balance on NewDB API token'), making the tool's purpose unambiguous. The focus on token quota clearly differentiates it from sibling tools like newdb_check_fssp or newdb_complex_check_person, which all involve business data lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly conveys that this tool addresses account quota inquiries, and the contrast with sibling 'check_*' tools makes the usage context evident. However, it does not explicitly state when not to use it (e.g., 'use for balance only, not for data lookups'), though the naming convention makes this largely unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/newdb-api/newdb-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server