Search hpt.su — Russian/EAEU vehicle compliance documents: type approvals, certificates, VIN lookup.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.4/5 across 21 of 21 tools scored. Lowest: 2.4/5.
Most tools target distinct document kinds or entities, but the 10 search_* tools (e.g., search_otts vs search_otch) could be confused if descriptions are not read carefully. Descriptions provide clarity, so overall high disambiguation.
All tool names follow a consistent verb_noun pattern in snake_case (search_<kind>, list_<entity>, get_document, download_document_file). No mixing of conventions.
21 tools is slightly above the ideal range but justified by the need to cover multiple document types and supporting entities. The count feels well-scoped for the domain.
Covers essential read operations: search by kind, VIN, document number; list brands, models, bodies, labs; download files. Minor gaps exist (e.g., no date-range search) but core workflows are supported.
download_document_fileAInspectGet links for a document file: page URL for everyone, direct download URL when the plan allows it.
Always returns `document_page_url` — the document's page on hpt.su
where the user can download the file manually under their account.
Share this link with the user.
When the plan includes direct downloads, the response also contains
`download_url` — a personal link to the PDF (works only when signed
in to hpt.su under the same account that owns the API key; the
download quota is charged at actual download time). Otherwise
`download_url` is null and `download_note` explains why.
| Name | Required | Description | Default |
|---|---|---|---|
| file_uid | Yes | DocumentFile UID (from list_document_files). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses critical behaviors: the download URL is personal, works only when signed in with the same account, quota is charged at download time, and the page URL always works.
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 well-structured, front-loads the core purpose, and uses clear separation of behaviors (always-returned vs. conditional) without unnecessary words.
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?
Given the single parameter, existence of an output schema, and the description covering both input and output behavior comprehensively, the description is complete.
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 description coverage is 100% with a clear description of the single parameter 'file_uid'. The description adds no further parameter-level information, so baseline 3 is appropriate.
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 clearly states the tool returns two types of links (page URL and optional download URL) for a document file, distinguishing it from sibling tools that are mostly search/list functions.
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?
The description explains when to use the tool (to get document file links) and mentions plan-dependent behavior, but does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fulltext_searchAInspectFull-text search inside type-approval document bodies (PDF text).
Covers ОТТС / ОТШ / ЗОТТС / ЗОТШ. Other document kinds (СБКТС / ЗОЕТС /
СУТ / cert / decl) are not covered by full-text search.
**Premium feature** — requires a plan that includes full-text search
(see https://hpt.su/pricing/) with a subscription covering at least
one type-approval kind.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by registry kind. One of: otts, otch, zotts, zotch. Default: search across all 4 type-approval kinds. | |
| page | No | 1-based page index. | |
| query | Yes | Free-text query (Russian, tsquery-syntax allowed). | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the premium requirement, which is a behavioral constraint. It does not mention rate limits or performance, but given the nature of the tool, this is acceptable. No contradictions.
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 concise with two well-structured paragraphs. The first sentence states the main purpose, followed by specifics and usage notes. No redundant information.
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?
Given the 4 parameters with full schema descriptions, and the output schema existing (though not shown), the description provides sufficient context for an agent to use the tool. It covers scope, limitations, and premium status.
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 description coverage is 100%, so each parameter already has a description. The tool description adds context about query being free-text with tsquery-syntax and kind filtering, but does not significantly enhance beyond the schema. Baseline 3 is appropriate.
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 clearly states it performs full-text search inside type-approval document bodies (PDF text), and specifies the covered document kinds (ОТТС, ОТШ, ЗОТТС, ЗОТШ) while excluding others. This distinguishes it from siblings like search_otts and search_zotts which likely search metadata.
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?
The description explicitly notes when to use (full-text search within covered document kinds) and when not (other document kinds not covered). It also mentions it's a premium feature with a pricing link, providing context for usage. It lacks explicit alternatives but the sibling tools imply metadata searches for other kinds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentAInspectFetch a single Document by slug+kind.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | One of: otts, otch, zotts, zotch, sbkts, zoets, sout, cert, decl. Slug isn't globally unique between kinds, so kind is required. | |
| slug | Yes | Document slug — URL-form of the number (the same as in site URL). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation ('Fetch'), but no annotations are provided. It does not disclose behavioral traits like auth needs, rate limits, or error handling for missing documents. The presence of an output schema partially compensates.
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 a single front-loaded sentence with no wasted words. Every part is necessary.
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 fetch tool with full schema coverage and output schema, the description is nearly complete. It lacks usage guidelines, but overall is sufficient for an agent to understand the tool's purpose.
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 description coverage is 100%, so the schema already documents both parameters. The description adds 'slug+kind' but no new meaning beyond what the schema provides. Baseline 3 is appropriate.
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 clearly states the tool fetches a single Document using slug and kind. The verb 'Fetch' and resource 'Document' are explicit, and it distinguishes from sibling search tools that return multiple results.
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?
The description implies usage when you have a specific slug and kind but lacks explicit guidance on when to use this tool versus alternatives like search_documents. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brandsAInspectResolve a vehicle brand name to its canonical record (used to filter type approvals).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Brand name substring (e.g. 'KAMAZ'). | |
| page | No | 1-based page index. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does not state that the tool performs a read-only list operation, returns multiple results with pagination, or uses substring matching. The schema covers parameter behavior, but the description lacks transparency about read-only nature, output format, and side effects.
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 a single sentence that immediately conveys the core purpose. It is concise with no unnecessary words, efficiently front-loading the verb and resource.
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 list tool with full schema coverage and an output schema, the description is somewhat complete. However, it could be improved by explicitly stating that it returns a list of matching brands and how the result can be used for filtering type approvals. The current phrasing 'resolve to its canonical record' is ambiguous about multiple 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 description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only repeats the context of 'brand name' already captured in parameter descriptions. Therefore, no extra value is provided.
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 clearly states the tool resolves a vehicle brand name to its canonical record and specifies its use case (filtering type approvals). The verb 'resolve' and resource 'canonical record' are specific, and it distinguishes from sibling tools which focus on documents and certificates.
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?
The description mentions the tool is used to filter type approvals, providing context. However, it does not explicitly state when to use or not use it, nor list alternatives. Since no sibling brand-resolving tool exists, the lack of exclusions is acceptable, but the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_certification_bodiesAInspectLookup accredited certification bodies (issuers of сертификатов/деклараций).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Body name substring. | |
| page | No | 1-based page index. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description reveals the tool is a read operation ('lookup') but adds no behavioral details beyond the basic function, such as pagination behavior or that it is safe.
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 a single, efficient sentence with no wasted words, placed at the start.
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?
Given the tool's simplicity (list with optional filters and pagination) and the presence of an output schema, the description is sufficient for an agent to understand and invoke the tool correctly.
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 description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema; it only repeats the param name context.
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 clearly states what the tool does: 'Lookup accredited certification bodies' with a specific resource and purpose, distinguishing it from siblings that list other entities like brands or registry kinds.
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?
The description does not specify when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_document_filesAInspectList the files attached to a document.
Returns `[{file_uid, file_name, kind, pages_count, published_at}]` —
each entry's `file_uid` can be passed to `download_document_file`.
A document often has several PDFs (e.g. cleaned + original); use this
tool to enumerate them and pick the right one before download.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | One of: otts, otch, zotts, zotch, sbkts, zoets, sout, cert, decl. Slug isn't globally unique between kinds, so kind is required. | |
| document_slug | Yes | Document slug (from search.slug field). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the return format and how the output connects to another tool. It does not mention pagination, rate limits, or authorization, but for a read-only list operation, the provided information is sufficient and transparent.
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 very concise: two sentences and a list format. It is front-loaded with the purpose and all sentences are useful. No wasted words.
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?
The description includes the purpose, usage hints, and a sample return structure. With an output schema present, it does not need to detail all fields. It covers the essential information for a list tool.
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?
The input schema has 100% coverage with descriptions for both parameters. The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.
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 clearly states 'List the files attached to a document' with a specific verb and resource. It distinguishes itself from the sibling 'download_document_file' by indicating that this tool is for enumeration before download.
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?
The description provides context for when to use the tool: 'use this tool to enumerate them and pick the right one before download.' It implies use before download, but does not explicitly mention when not to use or contrast with other siblings. Still, it offers clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_registry_kindsBInspectReturn the catalogue of registry kinds exposed by the hpt.su public API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behaviors. It only states the return value, but does not mention that it is a read-only safe operation, any rate limits, or data freshness. The agent must infer behavior from the tool name and default assumptions.
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 a single concise sentence (12 words) that includes the key information: what it returns and from which API. It is appropriately front-loaded and efficient.
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?
Given the tool has no parameters and an output schema exists, the description is largely complete. It identifies the resource and source. Additional details about when to use it would be beneficial, but the simplicity keeps this from being a significant gap.
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?
The tool has zero parameters, so schema coverage is 100%. The description adds the context that the API is public, but parameter semantics are not applicable. Baseline score of 4 is appropriate.
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 clearly states the tool returns a catalogue of registry kinds from the hpt.su public API. The verb 'Return' is adequate and the resource is specific, differentiating it from sibling list_* tools that return different entities. However, it does not explicitly distinguish from siblings.
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?
The description provides no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are mentioned. For a parameterless tool, this is a minor gap but still a lack of guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_test_labsCInspectLookup accredited testing laboratories (issuers of СБКТС/ЗОЕТС).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Lab name, full or partial. | |
| page | No | 1-based page index. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention pagination behavior (page, page_size), data freshness, filtering scope, or any access restrictions. The input schema's pagination parameters are not referenced.
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 a single, concise sentence with no filler. It is appropriately front-loaded but could be expanded slightly without losing conciseness.
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?
Given the tool has an output schema and only three parameters with full schema coverage, the description provides basic context. However, it lacks details on what the returned list contains, pagination behavior, and how the name filter works. The output schema may compensate, but the description is minimal.
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 description coverage is 100%, so all three parameters have descriptions in the schema. The tool description adds the context that 'name' is for full or partial lab name, but otherwise adds no extra meaning beyond 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?
The description clearly states the tool lists accredited testing laboratories that issue specific certificates (СБКТС/ЗОЕТС). The verb 'Lookup' is appropriate and the resource is well-defined, distinguishing it from sibling tools focused on documents or certificates.
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?
No guidance is provided on when to use this tool versus alternatives like search_sbkts or search_zoets. The description lacks context about differences in filtering capabilities or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tnved_codesAInspectTN VED EAEU classifier lookup.
Note: TN VED codes are linked **only** to certificates and declarations —
not to vehicle type approvals or safety reports.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. | |
| query | No | Free-text description search. | |
| prefix | No | TN VED code prefix (e.g. '8704'). | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It adds useful context about the scope of linked documents but does not explicitly state that the tool is read-only, idempotent, or describe any side effects. Pagination behavior is implied by schema parameters but not stated. The description adds moderate value beyond the 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?
The description is extremely concise: two sentences with no redundant information. The first sentence states the purpose, and the second adds a critical usage note. Every sentence earns its place.
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?
Given the tool has an output schema (present but not shown), the description does not need to explain return values. It covers the essential scope limitation. However, it could mention that it returns a paginated list or offer a brief example, but for a simple lookup tool, this is nearly complete.
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 description coverage is 100%, with all four parameters (page, query, prefix, page_size) described in the schema. The tool description does not add any additional parameter-specific context or examples, so the description does not enhance meaning beyond what the schema already provides. Baseline score of 3 is appropriate.
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 clearly states 'TN VED EAEU classifier lookup,' specifying the verb (lookup) and resource (TN VED EAEU classifier). It further distinguishes the tool from siblings by noting that TN VED codes are linked only to certificates and declarations, not to vehicle type approvals or safety reports, which are likely covered by other 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?
The description includes a clear scope limitation (only for certificates/declarations, not for vehicle type approvals/safety reports), which guides when to use this tool. However, it does not explicitly name alternative sibling tools for excluded use cases, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vehicle_modelsCInspectResolve a vehicle model name (within a brand) to canonical record.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Model name substring. | |
| page | No | 1-based page index. | |
| brand | No | Brand name (auto-resolved to id) or numeric brand id. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose that the tool returns a list (supporting pagination) rather than a single canonical record. Behavior like fuzzy matching or error handling is not mentioned.
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?
Single sentence, concise but lacks structure. Could be improved with clearer separation of purpose and 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?
Given 4 parameters and an output schema, the description is somewhat complete but misses key behavioral aspects like listing/pagination. It does not fully align with the tool's name and 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?
Schema description coverage is 100%. The description adds high-level intent but does not clarify parameter specifics beyond what the schema already provides, such as how the name substring works or the role of page.
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 'Resolve a vehicle model name (within a brand) to canonical record' suggests a single-record resolution, but the tool name 'list_vehicle_models' and input schema with pagination indicate it returns multiple records. This ambiguity reduces clarity.
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?
No guidance on when to use this tool versus alternatives like list_brands or search tools. No mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_vinAInspectAggregated search by VIN across all car-kinds (ОТТС/ОТШ/ЗОТТС/ЗОТШ/ СБКТС/ЗОЕТС). Open for any active API key — no subscription required.
Returns documents whose VIN field contains the given fragment, newest
first. For exact full-VIN search within a single registry use the
per-kind tool (search_otts/search_sbkts/…) with its `vin` parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | VIN substring or full code (5-17 chars). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses fragment matching, newest-first ordering, and open access. Lacks mention of pagination or rate limits, but output schema likely covers return structure.
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 concise paragraphs, front-loaded with primary purpose, zero wasted words.
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?
Given a single parameter, output schema, and no annotations, the description covers aggregated scope, fragment matching, ordering, authentication, and sibling differentiation—fully sufficient for an AI agent.
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 covers the vin parameter with description and constraints. Description adds context that it's a fragment search and notes the alternative exact search, adding meaning beyond 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?
The description clearly states this tool performs aggregated search by VIN across all car-kinds, distinguishing it from per-kind sibling tools like search_otts and search_sbkts.
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 tells when to use this (aggregated, VIN fragment search) and when to use per-kind tools for exact full-VIN search. Also notes no subscription required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_certificatesBInspectSearch conformity certificates (ТР ТС / ТР ЕАЭС).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. | |
| number | No | Certificate number, full or partial. | |
| scheme | No | Certification scheme — '1с'…'9с'. | |
| status | No | Certificate status code. | |
| product | No | Product full name, full or partial. | |
| applicant | No | Applicant name, full or partial. | |
| page_size | No | Rows per page (max 50). | |
| regulations | No | Technical regulation code (e.g. 'ТР ТС 018/2011'). | |
| manufacturer | No | Manufacturer name, full or partial. | |
| applicant_inn | No | Applicant INN (exact match). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Search'. It does not disclose pagination behavior, result format, rate limits, or other operational traits beyond what the schema provides.
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 a single, front-loaded sentence with no waste. However, it is so brief that it may sacrifice completeness for conciseness.
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?
Given the tool has 10 parameters and an output schema exists, the description should provide more context (e.g., scope of search, typical use cases). It is currently too sparse to fully inform an agent.
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% with clear parameter descriptions, so the baseline is 3. The description adds no extra semantic value; it merely restates the tool's search function.
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 clearly states it searches 'conformity certificates' and specifies the regulatory types (TP TC / TP EAEU), making the tool's purpose distinct from sibling tools like search_declarations or search_documents.
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?
No guidance on when to use this tool vs alternatives; no explicit when/when-not conditions, leaving the agent to infer 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.
search_declarationsCInspectSearch declarations of conformity (ТР ТС / ТР ЕАЭС).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. | |
| number | No | Declaration number, full or partial. | |
| scheme | No | Declaration scheme — '1д'…'6д'. | |
| status | No | Declaration status code. | |
| product | No | Product full name, full or partial. | |
| applicant | No | Applicant name, full or partial. | |
| page_size | No | Rows per page (max 50). | |
| regulations | No | Technical regulation code (e.g. 'ТР ТС 018/2011'). | |
| manufacturer | No | Manufacturer name, full or partial. | |
| applicant_inn | No | Applicant INN (exact match). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only states the action and regulatory context, omitting important details such as read-only nature, pagination behavior, result structure, or any prerequisites. This is insufficient for an agent.
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 a single front-loaded sentence that is efficient and to the point. While very short, it earns its place, though it could be slightly expanded without losing conciseness.
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?
Given the tool has 10 parameters, no annotations, and many siblings, the description is incomplete. It lacks context about what declarations are, how results are structured, and how to effectively use the parameters. The presence of an output schema does not compensate for this lack of guidance.
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 description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema; it mentions the regulatory scope but does not clarify parameter usage, relationships, or typical patterns.
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 clearly states it searches declarations of conformity and specifies the regulatory frameworks (ТР ТС / ТР ЕАЭС), providing a specific verb and resource. However, it does not distinguish from sibling tools like search_certificates or search_documents, leaving potential ambiguity.
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?
No guidance is provided on when to use this tool over alternatives. With many sibling search tools, the description should clarify scenarios for using search_declarations versus others, but it does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_documentsBInspectCross-registry search by document number across all hpt.su kinds.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. | |
| number | No | Document number, full or partial. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It does not mention that results are paginated, nor does it describe any limits, side effects, or authentication requirements. The description only states what the tool does, not how it behaves.
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 a single, concise sentence that fully conveys the tool's core purpose without any extraneous information. Every word adds value.
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?
Given the complexity (pagination parameters) and the presence of an output schema, the description is adequate but incomplete. It does not explain that the search is only by document number or that results are paginated, though the schema covers parameter details.
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 description coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, meeting the baseline of 3.
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 clearly states the verb ('search') and the resource ('documents across all hpt.su kinds'), and the phrase 'cross-registry' distinguishes this tool from sibling search tools that are registry-specific, making the purpose unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives like fulltext_search or registry-specific searches. It does not mention that the search is limited to document number, nor does it exclude use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_otchCInspectSearch ОТШ (chassis type approvals).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN substring (5-17 chars). | |
| page | No | 1-based page index. | |
| type | No | Type / model. | |
| brand | No | Brand. | |
| issuer | No | Certification body name — auto-resolved to id (or pass numeric id). | |
| number | No | ОТШ number, full or partial. | |
| category | No | Vehicle category. | |
| comm_name | No | Commercial name. | |
| eco_class | No | Ecological class — '5' or name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 the search action, omitting details about pagination, result format, or that it is likely read-only. The agent gets no behavioral insight beyond the operation name.
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 very concise at one sentence with no fluff. However, it could be more informative without becoming verbose, such as mentioning the scope of the search or result details.
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?
Given the complexity of 12 parameters and the existence of an output schema, the description is too minimal. It does not explain the search's purpose, result structure, or constraints like auto-resolution behavior, leaving significant gaps.
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 description coverage is 100%, so each parameter is documented in the schema. The tool description adds no extra meaning beyond the schema, meeting the baseline of 3.
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?
Description clearly states 'Search ОТШ (chassis type approvals)', specifying verb and resource. However, it does not differentiate from sibling search tools like search_otts or search_sbkts, which have similar names.
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?
No guidance on when to use this tool versus alternatives. The description lacks context about prerequisites or scenarios for chassis type approval search, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ottsBInspectSearch ОТТС (vehicle type approvals, ТР ТС 018/2011).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN, full or partial (5-17 characters). | |
| mods | No | Modifications, full or partial. | |
| page | No | 1-based page index. | |
| type | No | Vehicle type / model, full or partial. | |
| brand | No | Vehicle brand (e.g. 'Toyota'). | |
| issuer | No | Certification body name — auto-resolved to id (or pass numeric id). See list_certification_bodies. | |
| number | No | ОТТС number, full or partial. | |
| chassis | No | Chassis identifier, full or partial. | |
| category | No | Vehicle category (M1, N2, L3, …). | |
| comm_name | No | Commercial name, full or partial. | |
| eco_class | No | Ecological class — pass '5' or the name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It does not disclose whether the tool is read-only, requires special permissions, or describes any side effects. The pagination parameters exist but their behavior is not summarized.
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 very short (one sentence), which is concise but lacks necessary detail. It is not wasteful, but also not fully helpful.
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 14 parameters and an output schema, the description should explain return values or behavior. It does not. The input schema is well covered, but contextual completeness is low due to missing output/behavioral context.
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% with detailed parameter descriptions, so the description adds little beyond the schema. Baseline is appropriate at 3.
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?
Description clearly states it searches for OTTS (vehicle type approvals under TR TS 018/2011). The verb 'Search' and resource 'OTTS' are specific, and the regulation reference distinguishes it from other search tools like search_certificates or search_declarations.
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?
No guidance on when to use this tool versus siblings or any prerequisites. The description is a single sentence with no context about alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_sbktsCInspectSearch СБКТС (vehicle safety certificate).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN (10-17 chars; substring/exact). | |
| fuel | No | Engine fuel type, one of: 'бензин', 'дизель', 'газ', 'электро', 'водород'. | |
| page | No | 1-based page index. | |
| type | No | Type. | |
| year | No | Manufacture year (YYYY). | |
| brand | No | Brand. | |
| motor | No | Electric motor model, full or partial. | |
| engine | No | ICE engine model, full or partial. | |
| issuer | No | Testing lab name — auto-resolved to id (or pass numeric id). See list_test_labs. | |
| number | No | СБКТС number. | |
| date_to | No | Issue date to (YYYY-MM-DD). | |
| category | No | Vehicle category. | |
| comm_name | No | Commercial name. | |
| date_from | No | Issue date from (YYYY-MM-DD). | |
| eco_class | No | Ecological class — '5' or name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| powertrain | No | Powertrain type: 'ice' (combustion), 'hybrid', 'electric'. | |
| motor_power | No | Motor power (kW). | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as pagination behavior, result format, or any side effects. Even with an output schema, the agent needs clues about how the search operates (e.g., concurrency, rate limits, data freshness).
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?
Single, clear sentence that states the tool's purpose. Highly concise and front-loaded, though could benefit from a brief note on common use cases or return value summary.
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 20 parameters, an output schema, and no required fields, the description is minimally adequate. However, it lacks examples, parameter interaction guidance (e.g., AND vs OR logic), and any mention of how to handle large result sets beyond pagination parameters.
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% with detailed descriptions for each parameter, including auto-resolution behavior for some fields (e.g., issuer, eco_class, axis_count). The tool description itself adds no extra parameter context beyond the schema, which is acceptable given full coverage.
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?
Description clearly states the tool searches for vehicle safety certificates (СБКТС), which is a specific document type. This distinguishes it from sibling tools like search_certificates or search_declarations, though it could be more explicit about the search scope.
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?
No guidance on when to use this tool versus alternatives (e.g., search_certificates, search_declarations). No mention of prerequisites, parameter combination logic, or when not to use it. Agents lack context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_soutBInspectSearch СУТ (vehicle type notification — small dataset, only basic fields).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based page index. | |
| type | No | Type. | |
| brand | No | Brand. | |
| number | No | СУТ number. | |
| page_size | No | Rows per page (max 50). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 adds that the dataset is small and contains only basic fields, which sets expectations about result size and detail. However, it does not mention pagination behavior, rate limits, or any implications of the search (e.g., partial vs. exact matching).
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?
A single sentence that is front-loaded with the core purpose and includes a useful qualifier. Every word earns its place with no repetition or fluff.
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?
Given 5 parameters (none required) and an output schema, the description is minimal but sets expectations about data size and field richness. However, it lacks details on search behavior, exact fields available, and how this tool differs from similarly named siblings (e.g., search_ots, search_otch). More context would be beneficial.
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 description coverage is 100%, so baseline is 3. The tool description does not add any additional meaning to the parameters beyond what is already in the schema. It only says 'basic fields' generically.
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?
Clearly states the verb 'Search' and the resource 'СУТ (vehicle type notification)'. The qualifier 'small dataset, only basic fields' differentiates it from potentially more comprehensive sibling tools like search_otts, making its scope immediately clear.
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?
The description only hints at usage context ('small dataset, only basic fields') but provides no explicit guidance on when to use this tool versus any of the 20 sibling search tools. No alternatives are named, and no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zoetsCInspectSearch ЗОЕТС (vehicle technical expertise conclusion).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN (10-17 chars). | |
| fuel | No | Engine fuel type, one of: 'бензин', 'дизель', 'газ', 'электро', 'водород'. | |
| page | No | 1-based page index. | |
| type | No | Type. | |
| year | No | Manufacture year. | |
| brand | No | Brand. | |
| motor | No | Electric motor model. | |
| engine | No | ICE engine model. | |
| issuer | No | Testing lab name — auto-resolved to id (or pass numeric id). | |
| number | No | ЗОЕТС number. | |
| date_to | No | Issue date to (YYYY-MM-DD). | |
| category | No | Vehicle category. | |
| comm_name | No | Commercial name. | |
| date_from | No | Issue date from (YYYY-MM-DD). | |
| eco_class | No | Ecological class — '5' or name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| powertrain | No | Powertrain type: 'ice' (combustion), 'hybrid', 'electric'. | |
| motor_power | No | Motor power (kW). | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 merely says 'Search', implying a read operation, but offers no details about pagination, filtering behavior, or potential side effects. Given the 20 parameters, the description lacks essential behavioral context.
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 a single sentence with no wasted words. It conveys the core action and resource. While very brief, it is efficiently structured, though it could benefit from slight expansion.
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?
Despite an output schema existing, the description for a 20-parameter search tool is incomplete. It does not explain typical search strategies (e.g., when to use VIN vs. other filters) or how results are aggregated. The minimal description leaves significant gaps for effective tool invocation.
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 description coverage is 100%, so the input schema fully documents all 20 parameters. The description adds no extra meaning beyond 'Search'. Baseline 3 is appropriate since the schema already handles param semantics.
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 'Search ЗОЕТС (vehicle technical expertise conclusion)', which identifies the resource as a vehicle technical expertise conclusion. However, the abbreviation 'ЗОЕТС' is not widely recognized, and the description does not differentiate it clearly from sibling tools like search_otts or search_certificates. The purpose is vague for an unfamiliar agent.
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?
No guidance is provided on when to use this tool versus the many sibling search tools. There is no mention of typical use cases, contexts, or alternatives. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zotchCInspectSearch ЗОТШ (chassis conformity assessment conclusion).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN substring. | |
| page | No | 1-based page index. | |
| type | No | Type. | |
| brand | No | Brand. | |
| issuer | No | Certification body name — auto-resolved to id (or pass numeric id). | |
| number | No | ЗОТШ number. | |
| category | No | Vehicle category. | |
| eco_class | No | Ecological class — '5' or name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It fails to mention pagination, result format, destructive potential, or any constraints beyond the schema, leaving the agent uninformed.
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 a single sentence, front-loaded with purpose. It is concise but overly minimal, lacking structure that could convey usage context—acceptable but not optimal.
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?
Given the tool's 11 parameters and 19 siblings, the description is fundamentally incomplete. It omits guidance on result structure, pagination, and how this search differs from others, making it insufficient for effective agent decision-making.
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%, minimizing the need for additional parameter detail. The tool description itself adds no value, but the baseline is met by the schema, resulting in an adequate score.
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 'Search ЗОТШ (chassis conformity assessment conclusion)', identifying the verb and resource. However, it does not differentiate this search from sibling tools like search_certificates or search_declarations, making it somewhat vague for an agent with many options.
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?
No guidance is provided on when to use this tool versus alternatives, nor any exclusion criteria. The agent receives no hints about prerequisite filters or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zottsCInspectSearch ЗОТТС (vehicle conformity assessment conclusion).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN substring. | |
| page | No | 1-based page index. | |
| type | No | Type. | |
| brand | No | Brand. | |
| issuer | No | Certification body name — auto-resolved to id (or pass numeric id). | |
| number | No | ЗОТТС number. | |
| category | No | Vehicle category. | |
| eco_class | No | Ecological class — '5' or name; auto-resolved to reference id. | |
| page_size | No | Rows per page (max 50). | |
| axis_count | No | Axle count (e.g. '2') or exact 'axes / wheels' (e.g. '2 / 4') — auto-resolved to reference id. A bare axle count may match several wheel configs; then candidates are returned to pick from. | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden for behavioral disclosure. The description provides zero behavioral details—no mention of pagination, result structure, authentication, or side effects. This is a severe gap for a search tool.
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 a single, concise sentence that wastes no words. It is appropriately sized for the amount of information it conveys, though it could be moderately expanded without sacrificing conciseness.
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?
Despite having an output schema, the description is far from complete. It fails to explain the tool's scope, typical use cases, or how it differs from similar search tools (e.g., by entity type or constraints). Given the tool's complexity (11 parameters, many siblings), more context is necessary for effective selection.
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 description coverage is 100%, so the schema already documents all 11 parameters. The tool description adds no parameter-specific information beyond what is in the schema. Baseline 3 is appropriate as the description does not degrade or enhance parameter understanding.
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 clearly states the verb 'Search' and the resource 'ЗОТТС (vehicle conformity assessment conclusion)', making the tool's function obvious. However, it does not distinguish this tool from many sibling search tools targeting similar entities (e.g., search_otts, search_zoets), which share the same verb and pattern.
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?
No guidance is provided on when to choose this tool over alternatives (e.g., search_otts, search_zoets). There are no descriptions of when to use, when not to use, or references to other tools for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.