value-pro-mcp

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

With no annotations, the description reveals the tool is deterministic and non-AI, which is important. But it omits details on side effects (likely none), read-only nature, and behavior when no answer is found.

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, dense sentence with no waste. All information is front-loaded and 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?

Tool is simple, but without an output schema, the description should indicate return format (e.g., text, confidence score). It only says 'answer' generically, leaving uncertainty about what the agent receives.

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 already has descriptions for both parameters (query and top_k). The description adds topic context but does not significantly enhance parameter understanding beyond what the schema 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?

Description clearly states 'deterministic search for an answer from FAQ database' with specific topics (cost, documents, deadlines, etc.) and explicitly contrasts with AI generation, distinguishing it from sibling tools like ask_assistant.

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 for FAQ retrieval without AI, providing clear context. However, it does not explicitly state when not to use it or name alternative tools, leaving some ambiguity.

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 carries the full burden. It discloses that answers undergo a reliability check, exact conditions are confirmed by an operator, and the assistant may be disabled. It also states that numbers should not be considered final. This covers key behavioral aspects for a query tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is slightly long but packs essential information: purpose, limitations, and alternatives. It is front-loaded with the main use case. Every sentence contributes value, though it could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, no output schema, and no annotations, the description covers purpose, limitations, and sibling differentiation. It provides enough context for an AI agent to decide when to use this tool. Some details like output format are omitted but not critical.

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 one parameter already described in the input schema. The description reiterates that the question is about property valuation but does not add new semantics beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a free AI assistant for property valuation questions. It differentiates itself from siblings by naming alternatives like calculate_price and search_knowledge for precise values. However, the verb 'ask' is generic, and the resource is broadly defined as 'property valuation information.'

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 tells when to use alternative tools: for exact price/terms use calculate_price, for documents use required_documents, for catalog use list_services, for verified facts use search_knowledge. It also warns that numbers from the assistant are not final, providing 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.

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

With no annotations, the description bears the full burden and delivers: it explains that the calculation is preliminary, includes discounts, and notes the final price is confirmed by an operator. It also clarifies that purpose does not affect price and visit is ignored for damage types.

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 short paragraph that front-loads the main purpose and then details special cases. It is efficient without unnecessary repetition, though it could be slightly more 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?

The description covers the calculation logic and special cases well, but lacks any mention of the output format or return value. Since there is no output schema, this is a gap. It also does not explicitly state if the tool is read-only.

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?

Even with 100% schema coverage, the description adds value by explaining that 'visit' is ignored for damage types, 'purpose' only affects documents, and 'print_count' means extra copies beyond what is included. This goes beyond the schema's parameter-level 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 calculates the preliminary cost of an appraisal report, specifying components like base price, visit, copies, delivery, and discount. It distinguishes itself from siblings like 'list_services' by focusing on 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 provides context for when to use (price estimation) and includes a special case for damage types where visit is ignored. However, it does not explicitly mention when not to use or suggest alternatives, though the sibling list makes this less critical.

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. It discloses that no personal data is transmitted and that the client leaves contact via a safe path, which is useful behavioral context. However, it does not mention idempotency, duplicate handling, authentication needs, or rate limits. The description adds some value beyond the structured fields but is not 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?

The description is extremely concise, consisting of two sentences. The first sentence immediately conveys the primary action and output, and the second adds essential behavioral context. Every sentence is purposeful, with no redundancy or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 9 parameters and no output schema, the description provides a good high-level understanding. It explains the purpose, output (links), and privacy constraint. It could be more complete by mentioning the prerequisite of service_id from list_services or how the returned links are used, but these are either implied or covered in the schema. Overall, it is fairly complete for a lead creation 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 does not add significant meaning beyond the schema; it focuses on overall behavior. The parameter descriptions in the schema are already detailed, and the tool description reiterates the no-personal-data aspect, which provides some context but 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?

The description clearly states the tool's action ('фиксирует предварительную заявку') and resource ('заявку БЕЗ персональных данных'), and specifies the output (links for order processing). It distinguishes itself from siblings by emphasizing the absence of personal data, which is a unique trait not present in other tools 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?

The description does not explicitly state when to use this tool versus alternatives. It provides no guidance on prerequisites (e.g., needing service_id from list_services) or when not to use it. The context of 'без персональных данных' implies a constraint, but no direct comparison to sibling tools is given.

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 burden for behavioral disclosure. It only says 'returns' but does not mention read-only nature, authentication needs, rate limits, 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?

Two sentences, front-loaded with the main purpose, no unnecessary 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?

Adequate for a simple list tool, but missing return structure, pagination, or any limitations. Without an output schema, the agent lacks details on what fields are returned.

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 has 100% description coverage for the single parameter category. The description merely restates its purpose ('filter by category'), adding no new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns a catalog of valuation services with prices, deadlines, and allowable purposes, and mentions filtering by category. This distinguishes it from siblings like calculate_price or required_documents.

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

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

The description implies usage when a list of services is needed, but does not explicitly state when not to use or provide alternatives among siblings. However, the context is clear enough.

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 full weight for behavioral disclosure. It only states the return of a document list, without mentioning safety, side effects (it appears read-only), error handling, or other behavioral traits that could affect agent decision-making.

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, well-structured sentence that immediately states the tool's purpose. It includes a useful example without extraneous information, making it concise and easy to parse.

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 two well-defined parameters and no output schema, the description is adequate but incomplete. It does not hint at the output format (e.g., list of names or objects), which would help an agent anticipate the result structure.

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 minimal extra meaning by giving an example ('apartment for court') that contextualizes the purpose parameter, but does not elaborate on enum values or parameter relationships 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 action ('Returns a list of documents') and the resource ('for a specific service and assessment purpose') with an example ('apartment for court'). It distinguishes this tool from siblings like list_services (which lists services) by specifying it provides documents for a given service and purpose.

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 offers no guidance on when to use this tool versus alternatives like ask_assistant or search_knowledge. It does not mention any prerequisites, limitations, or appropriate contexts beyond the basic functionality.

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 clearly states that results are returned verbatim without AI generation, which is a key behavioral trait. However, it does not mention any potential limitations (e.g., query specificity) or whether results are ranked. Still, it is largely transparent for a read-only search tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is two sentences, both front-loaded with key information. No extraneous details. Efficiently communicates purpose, behavior, and usage guidance.

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 search tool with 2 params and no output schema, the description covers purpose, behavior, and usage guidelines. It is nearly complete, but lacks information about the format or structure of the returned fragments (though this may be implied by 'fragments'). Still, it is sufficient for an agent to use 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%, so baseline is 3. The description does not add additional meaning beyond the schema's param descriptions ('query' and 'top_k'). It mentions returning fragments but does not provide extra parameter guidance. Thus, it meets the baseline without exceeding it.

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 returns 'factual fragments' about the company, services, etc., verbatim without AI generation. It specifies the resource (knowledge base) and action (search). Distinguishes itself from sibling ask_assistant by emphasizing verifiable facts.

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. Provides context that the response should be formulated based on these facts. This guidance helps the agent decide which tool to use.

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