value-pro-mcp

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.

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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does well: it states the result is preliminary, the final price is confirmed by an operator, visit is included for damage claims, and electronic signature is included. The only gap is no explicit description of the return format or error behavior, but the core behavioral traits are well 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?

The description is three sentences, each earning its place: the first explains the main calculation, the second covers damage-specific visit inclusion, and the third notes e-signature and operator confirmation. It is front-loaded with the purpose, though the first sentence is fairly dense with numeric details that a more streamlined version might break out.

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 schema richly documents all parameters, and the description covers the calculation logic, inclusions, discount, and operator confirmation. With no output schema, the description could mention the return value shape, but the 'preliminary price' nature is clear enough for an agent to call it correctly. Overall, the definition is nearly complete for this complexity level.

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 an overall pricing formula (base price + visit + extra copies + delivery − loyalty discount) and inclusion rules, but these largely reinforce schema details rather than fill undocumented parameter gaps. The description does not add syntax or format details 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 opens with a specific verb+resource: 'Считает предварительную стоимость отчёта об оценке' (calculates the preliminary cost of an appraisal report), which clearly states what the tool does. It also distinguishes itself from siblings by aligning with the website calculator behavior, and none of the sibling tools (list_services, required_documents, answer_faq) perform price calculation.

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 clearly implies when to use the tool – when a user needs a preliminary appraisal price, especially one matching the website calculator. However, it does not explicitly mention alternatives or state when not to use it, such as when a user only needs a list of services or a general FAQ answer.

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

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

Since no annotations are provided, the description carries the burden of behavioral disclosure. It clearly states that personal data is NOT transmitted, which is a critical behavioral trait. It also explains what the tool returns: links to the bot and a pre-filled web form. However, it does not mention side effects like creating a record in a CRM or any irreversible actions, but given it's a lead capture, the description is reasonably transparent about its non-personal data nature.

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 three sentences, all dense with information. The first sentence states the core function; the second clarifies the client's action; the third reinforces the no-personal-data rule. No redundancy with schema, each sentence earned 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?

For a tool with 9 parameters (though most optional) and no output schema, the description does not detail return values beyond 'links', but the schema and context signals (like service_id from list_services) cover parameter specifics. The tool is relatively simple in purpose, and the description covers the workflow enough for an agent to invoke correctly. Missing explicit output structure could be a gap, but given the tool's purpose, it's sufficient.

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 description coverage is 100%, so the schema already documents each parameter thoroughly (e.g., rooms for specific damages, visit options). The tool description adds high-level context: it reiterates that no personal data fields exist, which is important semantic context beyond the schema. It also mentions that the tool returns links, tying to the purpose. Since coverage is high, a baseline of 3 is set, and the description adds meaningful extra context, warranting a 4.

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 records a preliminary lead without personal data and returns links for completion. It explicitly emphasizes the absence of personal data transfer, which differentiates it from other tools. The verb 'Фиксирует' and resource 'предварительную заявку' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use this tool: when you need to capture a lead without personal data. It also implies that for full lead capture with personal data, other tools might be needed, though it does not explicitly name alternatives like 'create_lead_with_personal_data' (which may not exist). It provides clear context that this is for soft handoff, and the mention of 'безопасному пути' for the client to leave contacts suggests when this is appropriate.

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

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.

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.

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.