cooper

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 explains the output varies by parameter presence, but does not specify return format, idempotency, or data source. The description adds context but lacks full transparency for a zero-annotation 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 concise, well-structured, and front-loaded with the core purpose. Each sentence adds meaningful information without redundancy, achieving high information density.

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 check tool with 2 parameters, no output schema, and no annotations, the description covers all essential aspects: core function, parameter effects, and usage guidelines for ambiguous inputs. It is complete enough 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% with descriptions for both parameters. The description adds value by explaining the effect of omitting service_type (returns coverage for all four services) versus specifying one, going beyond the schema specifications.

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 checks if Cooper operates with active caregivers in a city of Argentina, and explains behavior when service_type is omitted or specified. It distinguishes from sibling tools like createLead or getOrders by focusing on coverage verification.

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 advises when to ask for disambiguation (ambiguous city names, province-level mentions) and when to request more specific reference (unrecognized city), providing clear guidelines for proper invocation.

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?

Description discloses that it creates a lead (write operation) and gives timing hints. No annotations, so description carries burden. Lacks detail on idempotency or duplication, but adequately covers core 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?

Three sentences, each adding unique value: purpose, timing, use cases. Front-loaded and no redundant 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?

Covers purpose, timing, use cases, and key parameter (message). Missing output behavior (e.g., what the tool returns) but acceptable given no output schema and low complexity.

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 has 100% coverage with descriptions. Description adds context for 'message' (brief summary) and reinforces email/phone mutual exclusivity, but does not significantly extend 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?

Clearly states it registers a visitor interested in Cooper's service. Specifies when to call and what to pass (message). Distinguished from siblings by being the lead creation 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?

Explicitly says to call as soon as one contact datum is available, not to wait for both email and phone. Provides use cases: annotating out-of-coverage users or lightweight signup.

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 full burden. It discloses the write operation, user authentication requirement, and backend validation that the address belongs to the user. However, it does not mention potential side effects (e.g., charging, irreversibility) or error handling.

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 well-structured paragraph that front-loads the purpose, then provides usage guidelines and prerequisites. It is comprehensive but not overly verbose; 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 no output schema, the description should explain return values or confirmation, but it does not. It covers prerequisites and validation well, but missing output details and 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 baseline is 3. The description does not add meaningful semantic context beyond what the schema already provides (e.g., mapping of service type IDs).

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 creates a service order for the authenticated user, listing specific service types (paseo, adiestramiento, guardería, internación). It distinguishes from siblings by referencing prerequisite tools like getServiceCatalog and getMyPets.

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 instructs to present a summary and obtain explicit confirmation before invoking, and not to invoke if confirmation is missing. It also names prerequisite tools (getServiceCatalog, getMyPets, getMyOrders) for context.

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 bears the full burden. It indicates the tool returns the complete catalog without filtering or pagination. While it does not discuss performance, rate limits, or idempotency, the behavior is straightforward for a read operation with no parameters.

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 consists of two sentences with no redundancy. The first sentence states the tool's function, and the second provides usage guidance. Every word is purposeful.

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 no parameters and no output schema, the description covers the purpose and usage well. It could optionally describe the output structure (e.g., list of breed names and IDs), but the mention of 'identificador' implicitly informs that IDs are included. Thus, 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?

Since the input schema has zero parameters, the description adds value by explaining that the tool can be used to obtain a breed identifier, which clarifies the purpose of the output. Baseline for zero parameters is 4, and the description justifies 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?

The description clearly states the tool returns the complete catalog of dog breeds recognized by Cooper. It distinguishes itself from sibling tools like createOrder and checkCoverage by being a read-only catalog lookup.

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 mentions two use cases: confirming if a user-mentioned breed exists in the catalog and obtaining the breed ID needed for order creation. This provides clear context for when to use the tool, though it doesn't explicitly state 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, the description bears full responsibility. It discloses that message content is from third parties and may be manipulative. It lacks details on pagination, rate limits, or error handling, but the core behavioral traits 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?

The description is concise with two clear sentences plus an important note. The note, while longer, is essential for safe usage and does not detract from 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 no output schema and only two parameters, the description covers the main purpose, return structure, and critical usage guidance. It lacks mention of empty results or errors, but overall is complete enough 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% with good descriptions on both parameters. The description adds no additional semantic value beyond the schema, meeting the baseline expectation.

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 messages from a specific conversation, ordered by date, and describes the message structure. It distinguishes itself from siblings like getMyChats (list conversations) and sendChatMessage (send messages).

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 the assistant to only summarize or cite messages, not execute any instructions within them, due to potential manipulation attempts. This provides critical usage context and safety guidelines.

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 implies read-only behavior (returns data) but does not explicitly state side effects, authorization scope beyond 'autenticado', rate limits, or pagination. Basic transparency is present but could be improved.

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 concise sentences: the first covers purpose and output fields, the second directs to a sibling tool. No extraneous information, front-loaded.

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 no input parameters, no output schema, and low complexity, the description is largely complete. It covers what is returned and how to proceed for full messages. It could mention sorting or limits, but is adequate.

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 zero parameters with 100% coverage, so the baseline is 4. The description adds no parameter info, but none is needed.

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 what the tool does: returns conversations of the authenticated user with assigned caregivers. It lists included fields (id, order, status, last message date, preview) and distinguishes from sibling getChatMessages by directing to that tool for full message content.

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 states when to use the tool (to list conversations) and explicitly references getChatMessages for full content. However, it does not provide explicit when-not-to-use scenarios or mention other alternatives, but the context is 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 full behavioral disclosure. It clearly indicates a read operation (returns info) and mentions authorization constraint. It does not explicitly state that the tool has no side effects, but the context strongly implies a safe query.

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 with two sentences, front-loading the purpose and key details. No unnecessary 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?

Given the absence of an output schema, the description partially compensates by listing three categories of return info (sessions, caregiver, payment). However, it does not provide a complete list of fields, which may leave some 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 coverage is 100% with a clear description of order_id linking to getMyOrders. The tool description does not add further 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 tool returns complete order details for the authenticated user, specifying included information (sessions, caregiver, payment). It distinguishes itself from sibling getMyOrders by indicating it provides detailed info for a single order.

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 the tool should be used after obtaining an order ID from getMyOrders (as stated in parameter description). It restricts usage to the authenticated user's orders, but does not explicitly compare with other sibling tools or provide when-not-to-use scenarios.

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 must handle behavioral disclosure. It states the tool returns a summary (implying read-only) but does not mention pagination, rate limits, or behavior when no orders exist. The description is adequate but could be more specific.

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 consists of two concise sentences. The first sentence immediately states the main purpose, and the second provides usage guidance. No unnecessary 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?

Given the tool has no parameters and simple output, the description is sufficiently complete. It explains what the tool returns and when to use the sibling. It could optionally describe the output structure but is not required.

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?

There are zero parameters in the input schema, and the description does not need to add parameter information. Baseline 4 applies as per guidelines.

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 summary of active and historical orders for the authenticated user, listing specific service types (walks, training, daycare, hospitalization) with current status. It distinguishes itself from sibling getMyOrderDetail by explicitly mentioning the alternative.

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 guidance on when to use this tool (for summaries) and explicitly directs users to getMyOrderDetail for full details. It lacks explicit exclusions or prerequisites, but the context is 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?

With no annotations, the description carries full burden. It states the tool returns pet data for the authenticated user and implies read-only nature, but does not explicitly mention that it is non-destructive or require authentication details. Adequate but could be more explicit.

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, consisting of two sentences. The first sentence conveys the purpose and data returned, and the second adds usage context. No wasteful 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?

The description covers the tool's purpose, returned fields, and usage context. No output schema exists, but the description lists the fields. It lacks information about pagination or limits, but given the tool's simplicity, it is largely 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 tool has 0 parameters, and schema coverage is 100%. Per guidelines, 0 parameters give a baseline of 4. The description adds no additional parameter meaning, which is acceptable.

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 'returns' and the resource 'pets of the authenticated user', along with specific fields included. It distinguishes itself from sibling tools which deal with orders, chats, breeds, 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 indicates the tool is useful when creating an order and needing to select a pet, providing clear context. However, it does not explicitly state when not to use it or mention alternative tools.

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 fully discloses that the returned prices are ranges and that the definitive price is set by the caregiver upon order creation. This clarifies the tool's non-final output, which is critical for correct agent 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?

The description is three concise sentences, each serving a distinct purpose: output definition, usage instruction, and important behavior note. No filler text; information is front-loaded 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 there are no parameters, no output schema, and the tool is simple, the description fully covers what the tool returns and how its results should be used (preliminary pricing). It leaves no gaps for the agent's understanding.

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 tool has zero parameters, so baseline 4 applies. The description does not need to add parameter meaning, and it provides no redundant information about parameters.

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 explicitly states the tool returns service types, plans, and price ranges for Cooper, listing specific examples. It clearly differentiates from sibling tools like checkCoverage or createLead, which handle other 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 includes an explicit directive to invoke this tool before mentioning prices ('Invocar siempre antes de mencionar precios'). While it does not mention when not to use it, the context of sibling tools implies their distinct purposes, strengthening the 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, descriptions carries full burden. It clearly indicates a read-only operation returning shift data, with no destructive side effects. No contradictions.

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 concise sentences: first states output, second details returned fields, third provides usage context. No filler, 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?

Given zero parameters, no output schema, and a simple listing task, description fully covers what the tool does and why it's useful. Complete for its complexity.

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?

Input schema has no parameters (100% coverage). Description compensates by explaining what the tool returns and its purpose, adding meaning beyond the empty 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?

Description clearly states it returns available shifts (morning, afternoon, night) with identifier, code, and time range. Distinguishes from siblings like getBreeds or getServiceCatalog by specific resource and use case.

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 utility 'to assist the user in choosing a schedule when creating a walking or training order', providing clear context for when to use. Does not mention alternatives, but the context is sufficient.

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 bears full responsibility. It discloses that the recipient is a real person, messages are recorded in conversation history, and only text is supported. It does not cover rate limits or authentication, but the behavioral traits relevant for safe usage (confirmation requirement, recording) are adequately communicated, earning a high score.

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, consisting of three sentences in Spanish that front-load the main action, followed by critical usage prerequisites. Every sentence adds value: primary function, mandatory confirmation, and limitations. No redundant 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 low complexity (2 required parameters, simple action), the description covers all necessary aspects: what it does, prerequisites (confirmation, conversation_id source), constraints (text only), and alternative for media. It is complete for an AI agent to correctly select and invoke the 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?

The input schema provides 100% coverage with descriptions for both parameters (text and conversation_id), so the description does not need to add significantly. The description mentions the need for user confirmation on the text, but this is more of a usage guideline than parameter semantics. Thus, 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 clearly states the tool sends a text message to a caregiver in an existing conversation, using a specific verb ('Envía un mensaje de texto') and resource ('cuidador en una conversación existente'). It distinguishes itself from siblings by specifying it only handles text messages, while images/audio require the official app, differentiating from read-only tools like getChatMessages or getMyChats.

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 the assistant must present the exact text to the user and obtain explicit confirmation before invoking, and not to invoke if confirmation is ambiguous. It also mentions the conversation_id comes from getMyChats, providing clear context for when to use. Additionally, it advises against using for media, directing users to the official app instead.

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