Оценка имущества ВАЛПРО (Москва): расчёт цены, услуги, документы, FAQ, заявка без ПД.
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 4/5 across 7 of 7 tools scored.
Each tool has a clearly distinct purpose: FAQ lookup, AI assistant, price calculation, lead generation, service catalog, document lists, and verified fact search. No overlapping functionality.
Names follow lowercase snake_case mostly with verb_noun pattern (answer_faq, calculate_price, create_lead, list_services, search_knowledge), but 'required_documents' is adjective_noun, a slight inconsistency.
7 tools is well-scoped for a property valuation service, covering key interactions without being excessive or insufficient.
Covers core operations: pricing, lead capture, catalog, documents, FAQs, and knowledge. Minor gaps like order status or payment handling, but the surface is largely complete for the stated purpose.
answer_faqОтвет из базы частых вопросовAInspectДетерминированный поиск ответа по базе частых вопросов об оценке (стоимость, документы, сроки, приём в банках, удалённая оценка). Без ИИ-генерации.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Вопрос клиента | |
| top_k | No | Сколько ответов вернуть |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the deterministic nature and topic scope, but lacks details about behavior on no match, error handling, or authentication requirements.
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 efficiently conveys the core purpose and distinguishing feature (no AI generation). No redundancy, but could benefit from slight structural separation.
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 that there is no output schema, the description should explain what the tool returns (e.g., answer format, behavior when no answer found). It fails to provide this, leaving the agent uncertain about the response.
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 additional meaning beyond the schema's parameter 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 specifies the verb ('детерминированный поиск' - deterministic search), the resource ('база частых вопросов об оценке'), and distinguishes from siblings by stating 'без ИИ-генерации', which sets it apart from ask_assistant and search_knowledge.
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 for retrieval of predefined answers on specific appraisal topics and explicitly contrasts with AI generation, but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings like search_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask_assistantСпросить ИИ-ассистента ВАЛПРОAInspectСвободная справка по оценке имущества от ИИ-ассистента ВАЛПРО (запрос бесплатный). КРАЙНИЙ резерв: для точной цены и сроков берите calculate_price, для перечня документов — required_documents, для каталога — list_services, для выверенных фактов — search_knowledge (они дают ТОЧНЫЕ значения; ассистент — лишь предварительное пояснение, числа из его текста не считайте окончательными). Без оформления заявок. Ответ проходит контроль достоверности; точные условия подтверждает оператор. Может быть отключён.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Вопрос ИИ-ассистенту ВАЛПРО |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully handles transparency. It reveals that responses are preliminary, numbers are not final, answers undergo reliability checks, exact conditions are confirmed by operator, and the assistant may be turned off.
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 appropriately sized, front-loading purpose and alternatives. It is clear and efficient, though slightly verbose with the list of alternatives.
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 tool with one parameter, no output schema, and no annotations, the description provides sufficient behavioral context, limitations, and sibling differentiation.
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 single parameter at 100%. The description adds context that the question should be about property valuation, enhancing the schema's minimal 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 the tool is for asking an AI assistant about property valuation ('Свободная справка по оценке имущества от ИИ-ассистента ВАЛПРО'). It distinguishes from siblings by listing alternative tools for specific purposes.
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 says when to use this tool (free reference) and when not to, listing alternatives for exact values: calculate_price, required_documents, list_services, search_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_priceРасчёт стоимости оценкиAInspectСчитает предварительную стоимость отчёта об оценке, точно как калькулятор на сайте: берёт базовую цену по типу объекта, добавляет выезд, дополнительные экземпляры и доставку, затем вычитает скидку постоянного клиента 10%. Для ущерба от залива или пожара выезд уже включён. Электронная подпись включена. Финальную цену подтверждает оператор.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Единиц повреждённого имущества (только ущерб) | |
| loyal | No | Постоянный клиент (−10%) | |
| rooms | No | Помещений (только ущерб от залива/пожара) | |
| visit | No | Выезд оценщика; для ущерба игнорируется (включён) | |
| purpose | No | Цель оценки (на цену не влияет, влияет на документы) | |
| delivery | No | Доставка курьером в пределах МКАД (+700) | |
| service_id | Yes | ID услуги из list_services | |
| print_count | No | Доп. печатные экземпляры сверх включённого |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the calculation is preliminary, final price is confirmed by operator, electronic signature is included, and visit is ignored for damage. This adds substantial behavioral context 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 concise and front-loaded: first sentence states purpose. All information is relevant and no redundant words. Every sentence 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?
The description covers the core algorithm and key rules but lacks details about the return value (e.g., what the output looks like, whether it returns a price or a quote). With no output schema, this is a gap. Also, it does not mention required prior steps like selecting a service.
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 business logic meaning: explains calculation algorithm (base price by type, discount, inclusions). For example, it clarifies that 'visit' is ignored for damage cases, which the parameter description does not say.
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 calculates preliminary cost of an appraisal report, exactly like the website calculator. It names specific components (base price, visit, copies, delivery, discount) and distinguishes from sibling tools like list_services or create_lead.
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 context (requires service_id, conditional behavior for damage) but does not explicitly state when to use this tool versus alternatives, nor when not to use it. No direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_leadЗафиксировать заявку (мягкая передача, без персональных данных)AInspectФиксирует предварительную заявку БЕЗ персональных данных и возвращает ссылки для оформления: прямую ссылку в бот МАКС и заранее заполненную веб-форму. Контакт клиент оставляет сам по безопасному пути. Персональные данные через этот инструмент НЕ передаются.
| Name | Required | Description | Default |
|---|---|---|---|
| items | No | Единиц повреждённого имущества (только ущерб) | |
| loyal | No | Постоянный клиент (−10%) | |
| rooms | No | Помещений (только ущерб от залива/пожара) | |
| visit | No | Выезд оценщика; для ущерба игнорируется (включён) | |
| purpose | No | Цель оценки (на цену не влияет, влияет на документы) | |
| delivery | No | Доставка курьером в пределах МКАД (+700) | |
| source_id | No | Машинный идентификатор интеграции/кампании (НЕ ПД): [A-Za-z0-9._:-], до 64 | |
| service_id | Yes | ID услуги из list_services | |
| print_count | No | Доп. печатные экземпляры сверх включённого |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key safety info (no personal data) and outcome (returns links), but lacks details on error behavior, idempotency, or return value structure. Additional context about soft transfer is helpful but incomplete.
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 sentences, front-loaded with purpose and outcome. Every sentence adds value with 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 tool with no output schema, description explains return value as links but lacks detail on structure or number of elements. Parameter descriptions are complete. Overall adequate for agent understanding, but return format could be clearer.
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 parameter descriptions. The tool description adds value by emphasizing absence of contact fields and free text, reinforcing that personal data is not transmitted. This goes beyond schema-level info.
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 creates a preliminary lead without personal data and returns links for completion. The verb 'Фиксирует' and resource 'предварительную заявку' are specific, and the tool is well-differentiated from siblings like 'calculate_price' or 'list_services'.
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 implies usage for soft lead capture without personal data, but does not explicitly state when to use this tool vs alternatives. No exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_servicesСписок услуг, цен и сроковAInspectВозвращает каталог услуг оценки с ценами, сроками и допустимыми целями. Можно отфильтровать по категории объекта.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Фильтр по категории объекта |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it returns a catalog with specific attributes and filter capability, which suggests a read-only operation. However, it lacks explicit statements about side effects, idempotency, or safety, leaving some ambiguity.
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, front-loading the primary purpose and then the filter option. No superfluous words or 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 simple list tool with one optional parameter and no output schema, the description is adequate. It could optionally mention the response format (e.g., array of service objects), but is otherwise 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?
The schema covers 100% of parameters with descriptions. The tool description merely restates the filter by category, adding no new meaning beyond the schema. Baseline 3 is appropriate as no additional 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 specifies the tool returns a catalog of valuation services with prices, deadlines, and acceptable purposes. This distinguishes it from siblings like calculate_price (for calculation) and search_knowledge (for knowledge base).
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 need a list of services with pricing and deadlines, and mentions filtering by category. However, it does not provide explicit guidance on when to use this tool versus alternatives like calculate_price or required_documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
required_documentsКакие документы нужныAInspectВозвращает список документов для конкретной услуги и цели оценки (например, квартира для суда).
| Name | Required | Description | Default |
|---|---|---|---|
| purpose | Yes | Цель оценки | |
| service_id | Yes | ID услуги из list_services |
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 states the tool returns a list of documents, which is transparent about the basic behavior, but does not disclose pagination, ordering, or error cases.
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 that efficiently conveys the tool's purpose with no extraneous 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?
While the tool's purpose is clear, the description omits details about the output format or structure, which is significant given no output schema. It does not mention what each document entry contains or potential error conditions.
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 the description adds limited value beyond the schema. The example ('apartment for court') provides slight contextual enrichment, but doesn't explain parameter details further.
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 list of documents for a specific service and assessment purpose, with an example. It uses a specific verb and resource, and distinguishes from siblings which cover FAQs, assistant, pricing, 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?
The description implies usage for retrieving required documents by service and purpose but offers no explicit guidance on when to use this tool versus alternatives like ask_assistant or search_knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_knowledgeПоиск по базе знаний компанииAInspectВозвращает выверенные фактические фрагменты о компании, услугах, документах, методологии, ценах, процессе и юр-основаниях — ДОСЛОВНО, без ИИ-генерации. Предпочитайте этот инструмент перед ask_assistant, когда нужен проверяемый факт. Сформулируйте ответ клиенту своей моделью на основе этих проверенных фактов ВАЛПРО.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Запрос по базе знаний компании | |
| top_k | No | Сколько фрагментов вернуть |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that results are verbatim fragments, without AI generation, and that the model should base answers on them. However, it does not mention potential missing results, pagination, or performance traits. Still, key behavioral aspects are covered.
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 sentences, front-loaded with purpose and key constraint ('no AI generation'), followed by usage guidance. Every sentence is essential and 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?
No output schema, but description sufficiently explains return value (verified fragments) and usage pattern. Given complexity of a search tool, it covers the necessary context for proper 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 coverage is 100%, so baseline is 3. Description adds no new information about parameters beyond what the schema already provides (query and top_k with their descriptions). Does not 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?
Description clearly states that the tool returns verified factual fragments from the company's knowledge base, distinguishing it from ask_assistant. It specifies the resource and verb explicitly.
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 advises to prefer this tool over ask_assistant when a verifiable fact is needed, and instructs the model to formulate its response using these facts. Provides clear when-to-use guidance.
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!