biovet-mcp

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

With no annotations provided, the description carries the full transparency burden. It discloses that answers come from a vet-reviewed database, includes a source-article link, and explicitly limits the tool to informational purposes ('not a substitute for an examination'). This gives an agent a clear behavioral model without reciting annotations.

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, no filler. The first sentence front-loads the core function, data source, and output; the second adds a critical limitation. 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?

For a one-parameter Q&A tool with no output schema, the description is complete: it explains the input domain, the source and vetting of content, the presence of a source link in the response, and the non-diagnostic nature. An agent has everything needed to call 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 description coverage is 100%, and the schema already provides a clear Russian-language question description with examples. The tool description adds only general scope ('health and care'), which supports the parameter's intent but does not materially extend 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 states a specific verb and resource: it answers pet health/care questions from a curated database of 3,700+ Q&As. It also specifies the content source (veterinarian-reviewed BioVet network) and the output includes a source article link, which clearly differentiates it from sibling tools like book_visit, get_prices, or triage.

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: use it for pet health and care questions. It includes a useful caveat ('reference, not a substitute for examination'), but it does not explicitly state when not to use it or mention alternative sibling tools such as triage or food_check for overlapping topics.

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 burden of behavioral disclosure. It adds a meaningful side-effect: the clinic may call the client for confirmation. However, it does not disclose other behavioral traits such as whether the booking is final, how slots are locked, or what happens on failure.

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 compact: one purpose sentence and one mandatory-instruction sentence, both front-loaded with the key information. There is no fluff or irrelevant detail.

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 high schema coverage and no output schema, the description provides the essential preconditions and side-effects needed to call the tool correctly. It could be more complete by describing the expected response or post-booking behavior, but the available information is sufficient for a straightforward booking action.

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 baseline is 3. The description adds extra semantic value for the phone parameter by requiring it to be real and reachable, and it lists the fields required in the confirmation summary. These details go 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 the action and resource: 'Записать клиента на приём в клинику БиоВет' — booking a client for a visit at a specific clinic. It is distinct from sibling tools by its booking intent, though it does not explicitly contrast itself with check_slots or find_clinic.

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 gives explicit pre-call instructions: show the summary and obtain explicit confirmation before invoking the tool. It also requires a real phone number because the clinic may call. It does not explicitly mention when not to use the tool or name alternative tools, but the context and prerequisites are clear.

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 behavioral burden. It implicitly indicates a read-only lookup by returning free time, doctors, and hours, but it does not explicitly say it does not book an appointment or describe empty-result behavior. This is adequate but not richly transparent.

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

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

The description is one concise, information-dense sentence followed by a short prerequisite hint. It is front-loaded with the core purpose and contains no filler or redundant material.

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 lookup tool with three well-documented parameters, the description explains what the agent will get (doctors and available hours) and where to obtain clinic_id. Since no output schema exists, a little more detail about result shape and empty-behavior would help, but the description covers the essential context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents date, clinic_id, and specialty. The description only repeats that clinic_id comes from find_clinic, which adds no real semantic value beyond the schema. Therefore a baseline score of 3 is appropriate.

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

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

The description clearly identifies an availability-lookup tool: 'Свободное время врачей клиники БиоВет: кто принимает и в какие часы можно записаться.' It names the resource (doctor availability at BioVet) and the output content (doctors and hours), which separates it from booking or knowledge-base siblings. It is slightly indirect because it lacks an explicit verb and doesn't name the paired booking tool.

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 only explicit guidance is the prerequisite hint 'clinic_id — из find_clinic', which tells the agent where to get the required parameter. The intended use case is implied but there is no explicit statement of when to prefer check_slots over book_visit or ask_vet_kb, nor any 'do not use' conditions.

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 behavioral burden. It covers network scope (Moscow and Reutov, 20 clinics), operational status (all 24/7), and return fields (addresses, Yandex.Maps ratings, clinic_id). Minor gaps like coordinate/query precedence are not disclosed.

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?

One compact, front-loaded sentence conveys scope, search methods, and return values without unnecessary detail. Every clause adds useful 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?

The description is sufficient for a simple lookup tool: it states what the tool finds, how to search, and what it returns. It does not explicitly instruct the agent to provide either query or coordinates, but the schema's 'instead of query' notes partially cover this.

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 covers all three parameters with descriptions and examples. The tool description adds little beyond grouping query by name versus coordinates, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: find a BioVet clinic by district/metro/street or coordinates. It clearly differentiates from siblings by focusing on location lookup and mentioning the clinic_id needed for booking.

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 gives clear search modes: by district/metro/street or by coordinates. It implies when to use the tool, though it does not explicitly mention alternatives or when not to use it.

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 behavioral burden. It does state this is a reference ('справочник БиоВет') proofread by doctors, implying a non-destructive lookup. It does not disclose what happens when the item is absent from the reference or what the response format looks like.

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

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

A single sentence that front-loads the core question, names the pet species and resource types, and ends with the source-credibility claim. Every clause earns its place 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 one-parameter lookup, an agent can select and invoke the tool correctly. However, with no annotations and no output schema, the description omits return behavior and not-found handling, which it would need to fully disclose given the low structured context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the product parameter already includes Russian examples like 'виноград', 'лилия', and 'сыр'. The description adds only marginal semantic context (the pet-species scope), so the baseline 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 conveys what the tool answers: whether a product or houseplant is safe for a cat, dog, rodent, or bird, distinguishing it from siblings like book_visit and get_prices. The action verb is implicit ('Можно ли' question form implies checking), which keeps it just short of an explicit statement.

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?

When to use the tool is implied by the domain framing: when a user asks whether a pet can eat a product or plant. No explicit context, exclusions, or routing against the closest sibling (ask_vet_kb) is provided.

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 burden of behavioral disclosure. It does reveal useful behavior: data is live, sourced from a fixed price list, uniform across clinics, and searched by Russian service name. However, it does not describe the return shape, match behavior, or what happens if no service is found, which are meaningful gaps without an output 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 very concise and front-loaded: the first phrase states the core purpose, and the parenthetical adds scope. Every clause adds useful information with no redundancy or filler.

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 one-parameter lookup tool, the description covers the key context: what data is used, its scope, and how to search. It could be more complete by mentioning the response format, but the tool name and phrase 'Живые цены' make the return value largely obvious.

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 baseline is 3, but the description adds meaning beyond the schema by specifying that the query must be a Russian-language service name. This is a semantic constraint not present in the schema's property 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 identifies the resource (veterinary service prices from the BioVet price list) and the action (get live prices), and adds useful scope details: 900+ items and uniform pricing across clinics. This makes it easy to distinguish from sibling tools like find_clinic or book_visit, which cover different tasks.

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 the tool is for looking up current prices of veterinary services by Russian service name, and the 'same in all clinics' note tells users not to expect location-specific differences. It does not explicitly name alternatives or say when not to use it, so it falls short of a 5.

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 transparency burden. It discloses the tool's purpose, its non-diagnostic nature, the urgency categories, and that the symptom table is veterinarian-confirmed. This is solid behavioral disclosure, though it does not explain what happens with unclear or missing symptoms.

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 short, information-dense sentences. The purpose and output categories are front-loaded, and the critical caveat ('not a diagnosis') is placed at the end without padding. Every sentence earns its place.

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

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

Despite having no output schema, the description explicitly names the three output categories, lists supported species, states the input format, and adds a veterinary-validated caveat. For a simple triage tool, this is complete enough for an agent to invoke it correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented in the schema. The description adds the species list and the free-text nature of symptoms, but these largely repeat the schema descriptions rather than adding new meaning. 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 states a specific action ('Проверка срочности') on a specific resource (animal symptoms) and defines the three possible outcomes: life-threatening / vet today / observe. It also distinguishes itself from diagnosis with 'Это маршрутизация, не диагноз', which separates it from sibling tools like ask_vet_kb.

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 an urgency assessment is needed based on symptoms. It also gives an explicit exclusion by stating it is routing, not diagnosis, which helps the agent avoid using it as a diagnostic tool. However, it does not name specific sibling tools or provide direct 'use X instead' guidance.

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