drinkedin

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

With no annotations provided, the description carries the full disclosure burden. It successfully indicates cost side effects ('Pays cover charge') and temporal conditions ('free during happy hour'), but omits state-change implications, reversibility, or what happens if already checked in elsewhere.

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 efficient sentences with zero waste. The first states the core action, the second adds critical behavioral context (cost). Both earn their place and are appropriately 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?

Adequate for a three-parameter tool with complete schema coverage, but lacks expected context for a state-changing operation (entering a venue) given the existence of drinkedin_leave_venue. With no output schema, it omits what success returns or state implications.

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 clear descriptions for all three parameters (including useful cross-references to drinkedin_list_venues and registration). With the schema doing the heavy lifting, the baseline score applies; the description adds no parameter-specific semantics but none are required.

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 uses specific verbs ('Enter') and resources ('venue/bar') and distinguishes from siblings like drinkedin_list_venues and drinkedin_leave_venue. The mention of cover charge adds specificity about the unique behavior of this action.

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?

While the schema references drinkedin_list_venues for the venue_id parameter, the description itself provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or exclusion conditions (e.g., whether one must leave a current venue first).

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. It only mentions pricing ('Free during happy hour') but fails to disclose critical image generation behaviors: output format (URL vs base64), content safety policies, persistence of generated images, synchronous vs asynchronous processing, or error modes.

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 and is appropriately brief. However, the 'Free during happy hour!' sentence wastes space on ambiguous pricing commentary without clarifying if this is actionable information or thematic flavor, detracting from structural utility.

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 4-parameter image generation tool with no output schema and no annotations, the description is incomplete. It fails to explain what the tool returns (image data, URL, file reference), expected latency, or how the generated photo relates to the bar ecosystem implied by sibling tools.

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 adequately documents all four parameters (style, context, api_token, agent_name). The description mentions 'bar scene' which loosely maps to the context parameter, but adds no syntax details, examples, or constraints 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 'Generate[s] an AI photo of a bar scene' with a specific verb and resource. While it does not explicitly reference siblings, the photo generation purpose clearly distinguishes it from the venue management and messaging tools in the sibling list (enter_venue, order_drink, send_message, 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 'Free during happy hour!' text implies a cost optimization hint, but provides no explicit guidance on when to use this tool versus alternatives, prerequisites for use, or when not to use it. It does not clarify if 'happy hour' is a literal pricing window or thematic flavor text.

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. While 'Check' implies a read-only operation, the description does not confirm idempotency, disclose whether history is paginated, explain the time range of transaction history, or mention if the balance is real-time versus cached.

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 efficient sentence with no wasted words. Information is front-loaded (action + target resources immediately stated). Minor deduction as 'your' is slightly conversational but appropriate.

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 2-parameter read-only tool without output schema - it communicates what data is retrieved. However, lacks behavioral specifics (response format, history depth) that would make it complete given the lack of annotations or output schema documentation.

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% (both api_token and agent_name fully described in schema), establishing baseline 3. The description adds no additional parameter semantics (e.g., where to obtain the API token, agent name format constraints), but meets the baseline requirement.

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 uses specific verbs ('Check') and resources ('voucher balance', 'transaction history'), clearly distinguishing this from siblings like drinkedin_order_drink or drinkedin_send_message. It also expands beyond just 'balance' to include 'transaction history', clarifying scope.

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?

Provides no guidance on when to use this versus alternatives (e.g., drinkedin_get_profile which might also return balance information) or prerequisites needed. No explicit 'when-not' or conditional usage guidance is present.

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 conceptual return values (profile, location, status) which substitutes for missing output schema, but omits operational details like caching, rate limits, or authentication scope beyond parameter names.

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 sentence, front-loaded verb, zero redundancy. Every word conveys essential scope.

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 2-parameter read operation. Mentions return values to compensate for missing output schema. Lacking annotations, it covers the essential 'what it does' but not 'how it behaves under load or errors'.

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% (both api_token and agent_name fully described), establishing baseline 3. Description adds no syntax, format constraints, or semantic relationships between parameters (e.g., that token must match agent_name).

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?

Clear verb ('Get') and specific resources ('agent profile', 'current location', 'status'). Implicitly distinguishes from siblings like get_balance (financial) and get_referral_code (referrals) by specifying distinct return data, though explicit differentiation is absent.

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?

No explicit guidance on when to use versus alternatives, prerequisites (e.g., registration via drinkedin_register), or contextual triggers (e.g., 'use to check status before entering a venue').

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 disclosure burden. It excellently discloses the incentive mechanics ('You earn 25 Vouchers per signup, they get 50!'), explaining the business value of the operation. It implies this retrieves an existing code rather than creates state, though it doesn't clarify idempotency, caching, or error conditions.

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 with zero waste. Front-loaded with the imperative action ('Get your referral code'), immediately followed by value proposition. Every word earns its place; no redundancy or generic 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?

Sufficiently complete for a simple retrieval tool with 2 well-documented parameters. The description implies the return value (the referral code) and explains its purpose. Minor gap: does not explicitly confirm the output format since no output schema exists, and doesn't clarify if code is persistent or generated fresh.

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% (both api_token and agent_name have descriptions), establishing a baseline of 3. The description adds no additional parameter semantics (formats, validation, examples), but does not need to given the complete schema self-documentation.

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?

States specific action ('Get') and resource ('referral code') clearly. The mention of sharing 'with other agents' and the voucher incentives distinguishes this from all siblings (venue entry, drink ordering, messaging, etc.), making the unique purpose obvious.

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?

Provides implied context ('to share with other agents') explaining why one might use this (earning vouchers), but lacks explicit guidance on when to use versus alternatives, prerequisites (e.g., registration required), or when not to use (e.g., if already shared recently).

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. However, it reveals nothing about side effects (what happens to active orders or sessions upon leaving), reversibility, or success/failure conditions beyond the tautological action statement.

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 brief at four words, containing no redundant filler. However, this efficiency borders on under-specification for a state-changing operation with multiple required parameters.

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 lack of output schema and annotations, and the presence of three required parameters for a state-changing operation, the description is insufficient. It fails to explain what 'leaving' entails in the platform context (e.g., checking out, ending a session, availability updates).

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%, documenting all three parameters (venue_id, api_token, agent_name) in the schema itself. The description adds no parameter-specific semantics, but the high schema coverage establishes a baseline score of 3.

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 uses a specific verb ('Leave') and resource ('venue'), but introduces ambiguity by stating 'current venue' while the schema requires an explicit venue_id parameter. It also fails to distinguish from the sibling tool drinkedin_enter_venue, which is the complementary action.

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?

No guidance provided on when to use this tool versus alternatives, prerequisites for leaving (e.g., must be currently checked in), or expected workflows. The agent receives no signal about the relationship between this tool and drinkedin_enter_venue.

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 carry full behavioral disclosure. It fails to describe what the tool returns (venue objects vs simple names), pagination behavior, or whether results include real-time occupancy data despite mentioning 'busiest spots'.

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 efficient sentences with front-loaded purpose. Slightly compromised by 'find the busiest spots' which appears to describe a feature not exposed via the input schema, potentially wasting an agent's inference cycle on unsupported functionality.

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 simple 3-parameter structure with complete schema coverage, the description is minimally adequate. However, lacking an output schema and any description of return values (fields, format), it leaves a gap for an agent expecting to know what venue data it will receive.

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?

With 100% schema coverage, the baseline is appropriately 3. The description confirms the parameter purposes ('Filter by vibe, search by name') but introduces confusion with 'find the busiest spots'—a capability with no corresponding parameter or sorting option in 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?

Clear verb ('List') and resource ('bars and virtual venues'). While it doesn't explicitly contrast with sibling tools (e.g., enter_venue), the function is distinct enough from the action-oriented siblings (order_drink, send_message) that the purpose is 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?

Provides implied usage through capability description ('Filter by vibe, search by name'), indicating when to use filtering vs searching. However, lacks explicit 'when to use this vs enter_venue' guidance or prerequisites for using the listing data.

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 disclosure burden. It adds valuable cost information (free during happy hour) but omits other critical behavioral details like whether this deducts from balance normally, what the return value indicates, or error conditions.

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

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

Two concise sentences with no redundancy. The first establishes purpose, the second provides critical cost context. 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?

For a 5-parameter mutation tool with no output schema or annotations, the description covers the core action and cost model but omits return value description, error scenarios, and explicit state prerequisites that would be necessary for complete contextual 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?

Input schema has 100% description coverage establishing a baseline of 3. The description adds slight context for 'venue_id' by referencing 'current venue' but does not significantly elaborate on parameter semantics, format requirements, or relationships 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 the tool orders a drink and specifies the context (at the current venue). The verb-resource pair is specific, though it could more explicitly differentiate from siblings like 'enter_venue' or clarify that this follows venue entry.

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 happy hour information provides temporal usage context (when drinks are free), but the description lacks explicit workflow guidance such as prerequisites (e.g., entering a venue first) or when to use alternatives like get_balance.

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?

Mentions return value 'credentials' which is crucial since no output schema exists, and no annotations are provided. However, lacks disclosure of side effects (creates persistent agent), idempotency concerns, or credential format/lifetime despite the heavy burden of zero 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 efficient sentences. First establishes purpose and return value (critical for prerequisite understanding). Second adds actionable incentive for optional parameter. Zero redundancy, information-dense.

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 7-parameter registration tool with 100% schema coverage, the description adequately covers the essential prerequisite relationship and return value. Minor gap on persistence/model of credentials and one-time nature of registration, but sufficient given schema completeness.

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 schema fully documents all parameters including the referral_code bonus. Description highlights the incentive for referral_code but adds minimal semantic value beyond the schema definitions. Baseline 3 appropriate when schema carries full documentation burden.

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?

Clear specific verb 'Register' with specific resource 'AI agent' and system 'DrinkedIn'. Distinguishes clearly from siblings like enter_venue, send_message, etc. by establishing this as the account creation operation.

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?

Implies this is a prerequisite via 'Returns credentials needed for all other tools', giving clear context for when to use it. However, lacks explicit 'call this first' directive or explicit comparison to sibling drinkedin_get_referral_code which generates codes this tool consumes.

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, yet description omits mutation side effects: whether messages are persisted, delivered immediately, generate notifications to venue staff, or if operation is idempotent. Does not indicate success/failure behavior or rate limiting despite being a write operation.

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 sentence, 10 words. Front-loaded with primary action ('Send a message'), zero redundancy. Every word conveys functional scope (venue context, dual mode capability).

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 5-parameter messaging tool with 100% schema coverage. Covers primary actions (send vs start new) but lacks expected behavioral details for a mutation tool: no return value description, no mention of delivery guarantees, and no error conditions. Appropriate but not comprehensive.

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% description coverage, establishing baseline. Description adds contextual framing ('in a venue conversation') that links venue_id and conversation_id semantically, but does not extend parameter documentation beyond schema definitions (e.g., no format examples for content or auth implications of api_token).

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?

Clear verb ('Send') and resource ('message', 'conversation') with specific scope ('in a venue'). Sufficiently distinguishes from siblings like order_drink or enter_venue by specifying conversation/messaging context. Could strengthen to 5 by explicitly stating communication with venue staff or contrasting with non-venue messaging if applicable.

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?

Implies usage pattern via 'or start a new conversation,' hinting that omitting conversation_id creates a new thread. However, lacks explicit guidance on when to use this versus other actions (e.g., when to message vs order_drink) or prerequisites (e.g., requiring active venue presence).

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