hptsu-mcp
Server Details
Search hpt.su — Russian/EAEU vehicle compliance documents: type approvals, certificates, VIN lookup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
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.
Available Tools
21 toolsdownload_document_fileAInspect
Issue a signed URL to download the document PDF from hpt.su.
Returns `{download_url, file_name, kind, document_id}`. The URL is
encrypted with the user_id behind the API key — opening it works only
if the user is signed in to hpt.su under the same account. The
`dl_counter` is decremented on the website at actual download time, not
here.
Requires an active subscription covering the document's kind or a
stand-alone DOC_PURCHASE. On the free tier returns 403 with an
upgrade prompt to https://hpt.su/pricing/.
| Name | Required | Description | Default |
|---|---|---|---|
| file_uid | Yes | DocumentFile UID (from list_document_files). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully covers behavioral traits: signed URL, encryption with user_id, dl_counter decrement on website, subscription requirements, and return structure. This is thorough and reveals important details for correct invocation.
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, uses 3 sentences, front-loads the purpose, and includes essential behavioral details. No 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?
For a single-parameter tool with output schema, the description explains return shape, authentication behavior, and error conditions. It is fully self-contained and 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 coverage is 100%, so baseline is 3. The description mentions 'from list_document_files' implicitly connecting the parameter to a related tool, but adds minimal semantic value beyond the schema description.
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 issues a signed URL to download a PDF. The verb 'issue' and resource 'document PDF' are specific. It differentiates from sibling tools which are mainly search/list 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 specifies requirements (active subscription, DOC_PURCHASE) and consequences (403 on free tier). While it doesn't explicitly say when not to use, the context is clear. Missing explicit alternatives, but given no sibling download tools, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fulltext_searchAInspect
Full-text search inside type-approval document bodies (PDF text).
Covers ОТТС / ОТШ / ЗОТТС / ЗОТШ — kinds where `Document.fulltext` index
is populated. СБКТС / ЗОЕТС / СУТ / cert / decl don't have fulltext
index and are not searchable here.
**Premium feature** — requires a paid MCP key with `use_fulltext` +
subscription on 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates read-only behavior by describing search. It provides transparency about indexing scope and premium feature requirement. However, it does not discuss potential rate limits or response structure (though output schema exists, so return values are documented elsewhere). Slight gap but still good.
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 (3 sentences), front-loaded with the main purpose, and each sentence adds unique value. No redundancy or fluff. Excellent structure.
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 presence of an output schema, the description does not need to explain return values. It covers purpose, scope, limitations (which kinds are searchable), and access requirements (premium feature). This is fully adequate for a search tool with good schema coverage.
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%, so baseline is 3. The description adds value by explaining that kind can filter by registry kind (default: all 4) and that query supports free-text with tsquery syntax. This goes beyond schema descriptions, improving agent 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 tool does full-text search inside type-approval document bodies (PDF text). It specifies which document kinds are covered (ОТТС, ОТШ, ЗОТТС, ЗОТШ) and which are not (СБКТС, ЗОЕТС, СУТ, cert, decl), distinguishing it from sibling tools like search_documents, search_otts, etc.
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 states when to use (full-text search in document bodies of specific kinds) and when not to use (kinds without fulltext index). Also mentions premium feature requirement (paid MCP key with use_fulltext + subscription), providing clear prerequisites and access constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_documentBInspect
Fetch 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only says 'Fetch', implying a read operation, but does not disclose behavior such as error handling (e.g., what if document not found), rate limits, authentication needs, or any 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?
Description is a single, front-loaded sentence with no wasted words. It is concise, but could arguably be expanded slightly for completeness without losing clarity.
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 two parameters and an output schema, the description is adequate but minimal. It does not mention the return format or any constraints, though the output schema exists. Could be more helpful.
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 descriptions for both parameters. The description adds no extra meaning beyond the schema, which already explains slug and kind. Baseline 3 for high 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?
The description 'Fetch a single Document by slug+kind' clearly states the verb (Fetch), resource (Document), and the method (by slug+kind). It distinguishes 'get_document' from sibling search and list tools, which are for multiple documents or different resources.
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 does not mention prerequisites, typical use cases, or when to avoid it. Siblings include many search tools, but no comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_brandsAInspect
Resolve 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool resolves names to canonical records, but doesn't clarify if the result is a list or single record, or that it uses substring matching. Pagination is implied by the schema but not mentioned in the description.
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 12 words, front-loaded with the core purpose. Every word earns its place; no redundancy.
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 3-parameter tool with an output schema, the description is minimal. It does not explain that the tool likely returns a list of brands (pagination implies multiple records) or the behavior when name is null. The output schema covers return values, so the gap is moderate.
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 context about filtering type approvals, but does not add new meaning beyond the schema's parameter descriptions (e.g., 'Brand name substring').
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 uses a specific verb ('resolve') and resource ('vehicle brand name to its canonical record'), and mentions the usage context ('used to filter type approvals'), clearly distinguishing this tool from sibling list/search 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 implies when to use the tool (normalize brand names for filtering), but does not explicitly state when not to use it or mention alternatives. Still, the context is clear given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_certification_bodiesBInspect
Lookup 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral disclosure burden. It only states 'lookup', implying a read operation, but does not mention pagination behavior, filtering limitations, or any other behavioral traits beyond the verb. The pagination parameters exist in the schema but are not highlighted in the description.
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 conveys the core purpose. It includes clarifying information about certification bodies in parentheses. While it lacks some detail (e.g., pagination), it is well-structured and front-loaded with the key action 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?
The tool is a simple list operation with pagination and an output schema. The description is adequate but does not explicitly describe the return format (e.g., paginated list) or mention ordering or total count. For a straightforward lookup tool, this is minimally acceptable but could be more informative.
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 schema already provides full descriptions for all three parameters (name, page, page_size) with 100% coverage. The description does not add any additional meaning or context for these parameters beyond what the schema already states, 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 specifies the verb 'lookup' and the resource 'accredited certification bodies', and clarifies their role as issuers of certificates/declarations. This distinguishes the tool from sibling list tools like list_brands or list_registry_kinds, which target different entities.
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 that the tool should be used when looking up certification bodies, but it does not provide explicit guidance on when to use it versus alternatives (e.g., search functions) or when not to use it. No exclusions or criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_document_filesAInspect
List 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return structure and the fact that documents often have multiple files. However, no details on error behavior, authentication, or rate limits. With no annotations, it carries the full burden and could be more comprehensive.
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?
Five sentences, each serving a purpose: purpose, return format, cross-reference to download, context, guidance. No wasted words, well-structured.
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, the description covers all essentials: purpose, parameters rationale, return format, and next steps. Output schema is implied. No missing context 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds value by explaining why both parameters are required (slug not globally unique across kinds) and ties file_uid to download. This provides context beyond schema descriptions.
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 files attached to a document, specifies the verb 'List' and resource. It differentiates from sibling tools like download_document_file and various search tools by focusing on enumerating files for a given document.
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 guides when to use: before download to pick the right file among multiple PDFs. It implies the workflow of enumerating then downloading. Could mention when not to use, but the positive guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_registry_kindsAInspect
Return the catalogue of registry kinds exposed by the hpt.su public API.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read-only operation but doesn't disclose caching, rate limits, or pagination. For a simple list with no parameters, the transparency is adequate but minimal.
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 of 11 words, front-loading the main purpose. No waste; every word contributes.
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 (zero parameters) and presence of an output schema, the description sufficiently covers the basic purpose. It identifies the API source, which adds context. Minor gap: does not clarify if the list is static or dynamic.
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?
No parameters exist, so schema coverage is trivially 100%. The description adds no parameter info, but none is needed. Baseline 4 applies.
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 returns the catalogue of registry kinds from the hpt.su public API, using specific verb and resource. While it distinguishes from sibling list tools by naming a specific catalogue, it doesn't elaborate on what registry kinds are, slightly reducing specificity.
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?
Description provides no guidance on when to use this tool versus alternatives like list_brands or search tools. It lacks context such as that this tool likely serves as a prerequisite for filtering other searches by registry kind.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_test_labsBInspect
Lookup accredited testing laboratories (issuers of СБКТС/ЗОЕТС).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Lab name substring. | |
| page | No | 1-based page index. | |
| short_id | No | Lab short identifier. | |
| page_size | No | Rows per page (max 50). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'lookup', implying a read operation, but does not confirm no side effects, auth requirements, or any constraints beyond the input 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 a single sentence that conveys the essential purpose without any wasted words. It is 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 presence of an output schema and the simplicity of a list operation, the description is minimally adequate. However, it lacks usage context and behavioral details that would fully inform the agent, especially among many sibling tools.
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 descriptive parameter names and descriptions (e.g., 'Lab name substring'). The tool description adds no additional semantics, so baseline score of 3 applies.
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 looks up accredited testing laboratories, specifying the certificate types (СБКТС/ЗОЕТС). This verb+resource combination effectively distinguishes it from sibling tools like list_certification_bodies or list_brands.
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. The description does not mention exclusions, prerequisites, or context, 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.
list_tnved_codesAInspect
TN 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 discloses no behavioral traits like pagination behavior, rate limits, or side effects. The tool is read-only by nature, but this is not explicitly stated.
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 two sentences with no wasted words. The main purpose is front-loaded, and the additional note is concise and relevant.
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/lookup with pagination), the description is largely sufficient. It includes a helpful contextual note. The presence of an output schema reduces the need to describe return values. However, pagination behavior (e.g., total count, next page) is not mentioned.
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 no additional meaning beyond the schema's parameter descriptions. The note about linking is not parameter-specific.
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' — a specific verb and resource. It also distinguishes from sibling tools by noting that TN VED codes are linked only to certificates/declarations, not vehicle type approvals.
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 note about linking to certificates/declarations provides context for when to use this tool. It implicitly excludes use for vehicle type approvals, but does not explicitly state alternatives or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_vehicle_modelsCInspect
Resolve 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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as pagination, auto-resolution of brand names, or whether it returns multiple models. The term 'resolve' could be misleading.
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 (one sentence) with no wasted words. However, it lacks front-loading of key details like the fact that it returns a list of models.
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 4 parameters and an output schema, the description is too sparse. It does not explain how to use the tool effectively, and no context is provided about the canonical record or brand resolution.
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 documents all parameters. The description adds no additional meaning beyond the schema; it does not clarify matching behavior (e.g., substring) or pagination defaults.
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 the verb 'resolve' and the resource 'vehicle model (within a brand)', and implies linking to a canonical record. It distinguishes from sibling tools like list_brands or search_by_vin, though it could be more specific about the listing nature.
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 sibling tools like list_brands, search_by_vin, or search_otch. The description does not mention conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_vinAInspect
Aggregated search by VIN across all car-kinds (ОТТС/ОТШ/ЗОТТС/ЗОТШ/ СБКТС/ЗОЕТС). Open for any active API key — no subscription required.
Returns substring matches via UNION across kind-tables sorted by
`issue_date DESC`. For exact full-VIN match within a single kind,
use the per-kind tool (search_otts/search_sbkts/…) — they autoroute
substring↔DAWG by VIN validity.
| Name | Required | Description | Default |
|---|---|---|---|
| vin | Yes | VIN substring or full code (5-17 chars). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses substring matching via UNION across kind-tables sorted by issue_date DESC, and open access. Lacks info on pagination or rate limits, but is generally 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?
Three sentences: purpose, access, behavior. Front-loaded with main purpose. 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?
Output schema exists, so return values are covered. Description covers purpose, usage, alternatives, and search behavior. Lacks pagination info but is complete for a search 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?
Only one parameter 'vin' with description in schema. Description adds context about substring vs full match and directs to per-kind tools for exact match, adding value beyond 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 it's an aggregated search by VIN across all car-kinds, listing the specific kinds and distinguishing from per-kind tools. The verb 'search' and resource 'VIN' are explicit.
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 says when to use this tool (aggregated search) and when to use per-kind tools for exact full-VIN match. Mentions that per-kind tools autoroute substring↔DAWG, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_certificatesCInspect
Search 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 (icontains). | |
| applicant | No | Applicant name (icontains). | |
| page_size | No | Rows per page (max 50). | |
| regulations | No | Technical regulation code (e.g. 'ТР ТС 018/2011'). | |
| manufacturer | No | Manufacturer name (icontains). | |
| applicant_inn | No | Applicant INN (exact match). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits but only states the tool's purpose. It does not disclose pagination behavior, read-only nature, rate limits, or what happens with empty results. Essential context for a search operation is missing.
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 short sentence, achieving conciseness but lacking structure. It front-loads the purpose but does not include any additional bullet points or sections that would aid comprehension. It is minimally acceptable.
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, many sibling search tools, and an output schema, the description is insufficient. It does not explain output format, result interpretation, or how to combine parameters effectively. The agent lacks context for correct 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?
The input schema already provides descriptions for all 10 parameters, so the baseline is 3. The tool description adds no additional semantic information beyond what the schema offers, such as typical use cases or parameter interactions.
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 searches for conformity certificates under specific regulations (ТР ТС / ТР ЕАЭС), distinguishing it from sibling tools like search_declarations or search_documents. However, it could be more precise about the exact scope of certificates included.
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 other similar search tools, such as search_declarations or search_otts. The description does not specify prerequisites, exclusions, or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_declarationsCInspect
Search 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 (icontains). | |
| applicant | No | Applicant name (icontains). | |
| page_size | No | Rows per page (max 50). | |
| regulations | No | Technical regulation code (e.g. 'ТР ТС 018/2011'). | |
| manufacturer | No | Manufacturer name (icontains). | |
| applicant_inn | No | Applicant INN (exact match). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the search action and regulation scope, omitting any behavioral traits like authentication needs, rate limits, pagination behavior beyond schema, or side effects. Schema descriptions cover parameters but not runtime behavior.
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, front-loaded with key information. No wasteful text. Could be expanded slightly without losing conciseness, but currently it is appropriately short.
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 tool with 10 parameters and no annotations, the description is too brief. It does not explain return value structure (despite an output schema existing) or pagination behavior. Context such as result format or common use cases is missing.
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 extra meaning beyond what the parameter descriptions already provide. It does not explain parameter usage or relationships.
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 searches 'declarations of conformity' and specifies the regulation types (ТР ТС / ТР ЕАЭС). This is a specific verb+resource. However, it does not differentiate from sibling tools like search_certificates or search_documents, which also search different registries, but lacks explicit distinction.
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 implies use for declarations of conformity, but with many similar search tools, the agent gets no help on selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_documentsBInspect
Cross-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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the search action and does not disclose that the tool is read-only, what happens with empty results, or any limitations. The minimal description leaves many behavioral aspects unspecified.
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 of 8 words, clearly front-loaded with the key action and scope. No unnecessary words, 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 presence of an output schema and full parameter descriptions, the description adequately covers the tool's purpose and scope. It could mention pagination or output format, but those are handled by schema. For a straightforward search tool, it is sufficiently 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 coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only mentions 'by document number' which corresponds to the 'number' parameter, but does not clarify format or matching behavior beyond what the schema already states (full or partial).
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 it searches documents by number across all 'hpt.su kinds', clearly identifying the resource and action. It distinguishes from sibling tools that search specific registries (e.g., search_certificates). However, it could be more explicit about the scope and verb.
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 use when searching across all registry kinds, but does not explicitly state when to prefer this over alternatives like search_certificates or search_declarations. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_otchCInspect
Search ОТШ (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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits (e.g., pagination, result limits, authentication requirements). With no annotations provided, the description carries full burden, yet it offers no information beyond the basic purpose.
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 (one sentence), which is acceptable for front-loading, but it sacrifices substance. For a tool with 12 parameters, a bit more detail would improve usability 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 12 parameters, no required fields, and an output schema (not visible), the description is far from complete. It does not mention what the search results contain, typical use cases, or any constraints, leaving the agent with insufficient 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?
The input schema has 100% description coverage, so the schema already documents all 12 parameters thoroughly. The tool description itself adds no parameter information beyond what the schema provides, resulting in a baseline score 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 tool searches for ОТШ (chassis type approvals), which distinguishes it from sibling tools like search_certificates or search_declarations by specifying the resource. However, it does not elaborate on the search scope or capabilities.
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 such as search_otts or search_sbkts. The description lacks any context or usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ottsCInspect
Search ОТТС (vehicle type approvals, ТР ТС 018/2011).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN substring (5-17 chars) — backend autoroute substring/DAWG. | |
| mods | No | Modifications (icontains). | |
| page | No | 1-based page index. | |
| type | No | Vehicle type / model (icontains). | |
| 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 (icontains). | |
| category | No | Vehicle category (M1, N2, L3, …). | |
| comm_name | No | Commercial name (icontains). | |
| 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 fails to disclose that results are paginated, that some parameters are auto-resolved with candidate selection, or that the tool returns a list. The input schema hints at these but the description should summarize behavior.
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?
Extremely concise at one sentence, front-loading the core purpose. However, it sacrifices behavioral context that could be included in another sentence without becoming verbose.
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 complexity (14 parameters, pagination, auto-resolution features, output schema), the description is far too minimal. It does not explain what the tool returns, typical query patterns, or how search result candidates work, leaving ambiguity for the 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 description coverage is 100%, thus baseline is 3. The tool description adds no extra parameter meaning, but the schema's parameter descriptions are detailed (e.g., auto-resolution, format hints). The description does not need to repeat them.
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 searches for ОТТС with a parenthetical explaining it refers to vehicle type approvals under TR TS 018/2011. This distinguishes it from sibling search tools for certificates, declarations, etc., though it could explicitly note it searches a specific registry.
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 search_zoets or search_certificates. The description does not mention prerequisites, scope, or exclusion criteria, 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_sbktsCInspect
Search СБКТС (vehicle safety certificate).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN (10-17 chars; substring/exact). | |
| page | No | 1-based page index. | |
| type | No | Type. | |
| year | No | Manufacture year (YYYY). | |
| brand | No | Brand. | |
| motor | No | Electric motor model (icontains). | |
| engine | No | ICE engine model (icontains). | |
| 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. | |
| motor_power | No | Motor power (kW). | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'Search'. It does not mention return behavior, pagination, rate limits, or 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 concise sentence, but it is overly brief given the tool's complexity.
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 high schema coverage and an output schema, the description is insufficient for a tool with 18 search parameters and many siblings. It lacks an overview of search capabilities.
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%, so baseline is 3. The description adds no parameter-level info beyond the schema descriptions.
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 for СБКТС (vehicle safety certificate), a specific verb+resource. However, among many sibling search tools (e.g., search_certificates, search_declarations), it does not differentiate itself.
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 (e.g., when to prefer search_certificates). The description lacks context about prerequisites or comparison with other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_soutAInspect
Search СУТ (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). |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 mentions the dataset size and field richness, but does not describe pagination behavior, sorting, or any side effects. The minimal disclosure leaves significant gaps in transparency.
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, front-loaded sentence with zero waste. No redundancy, no filler. Every word 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?
With an output schema present, return values are covered. The description covers purpose and dataset scope. For a simple search tool with 5 optional parameters and no required fields, it is sufficiently complete, though it could briefly mention pagination behavior.
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 parameter-specific meaning beyond the note about basic fields, which is tangential. Baseline 3 is appropriate as the schema does the heavy lifting.
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 type notification)', and adds context that it is a small dataset with only basic fields. This effectively distinguishes it from sibling tools that search other types like certificates or 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?
The description implies when to use this tool (for СУТ notifications) and notes its limited scope (small dataset, basic fields), hinting that it is not suitable for other document types or detailed data. However, it does not explicitly state alternatives or provide clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zoetsCInspect
Search ЗОЕТС (vehicle technical expertise conclusion).
| Name | Required | Description | Default |
|---|---|---|---|
| vin | No | VIN (10-17 chars). | |
| 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. | |
| motor_power | No | Motor power (kW). | |
| wheel_formula | No | Wheel formula (e.g. '4x2'); auto-resolved to reference id. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Search', offering no behavioral details like read-only nature, authentication needs, or rate limits.
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?
Very concise and front-loaded with purpose, but no additional structure or elaboration.
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 18 parameters and no annotations, the description is too sparse; does not cover behaviors like pagination or auto-resolution hints that appear in the 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 coverage is 100%, so baseline is 3; the description adds no parameter semantics beyond what the schema already provides.
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 technical expertise conclusion)', but does not differentiate from sibling tools like search_zotch or search_zotts beyond the acronym.
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; the description is too minimal to provide usage context, especially given many sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zotchCInspect
Search ЗОТШ (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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination behavior, auto-resolution of parameters (e.g., 'issuer', 'eco_class'), or that queries may return multiple candidates. The description is minimal and relies entirely on parameter descriptions.
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 defines the tool's purpose efficiently. It is concise and front-loaded, but could be more structured to include usage hints. It earns its place by decoding the acronym, but lacks additional useful context.
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 complexity (11 parameters, auto-resolution logic, pagination) and the absence of annotations or output schema explanation, the description is insufficient. It does not address return format, pagination limits, or the behavior of auto-resolved fields, making it incomplete for a complex search 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?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional meaning beyond the schema's parameter descriptions. The schema itself already explains auto-resolution and format, so the description provides no extra value.
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 for 'ЗОТШ (chassis conformity assessment conclusion)', defining the acronym and specifying the resource type. It differentiates from siblings like 'search_otch' or 'search_zotts' by the specific document type, but could be more explicit about what the tool returns.
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 (e.g., search_certificates, search_declarations). The agent must infer based solely on the acronym definition, with no context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_zottsBInspect
Search ЗОТТС (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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'Search...' and omits details like pagination limits (though schema says max 50), mutation safety, or whether it is read-only. No behavioral context is added.
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 communicates the core action. It is concise but could benefit from additional context without becoming verbose.
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 11-parameter tool requiring no required params, the description is minimal. It clarifies the resource type but lacks usage context like typical workflows or data scope. Output schema exists, so return details are not needed, but completeness is moderate.
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?
All 11 parameters have descriptive schema entries (100% coverage). The description adds no extra meaning beyond the schema, 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 searches ЗОТТС (vehicle conformity assessment conclusion), distinguishing it from other search tools like search_certificates or search_declarations. The verb 'Search' and specific resource are well-defined.
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 its siblings (e.g., search_otts, search_zotch). The description does not mention prerequisites, exclusions, or alternative tools.
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.
Discussions
No comments yet. Be the first to start the discussion!