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

With no annotations, the description carries full burden. It discloses how matching works via four criteria (CRM associations, participant domains, affiliations, title mentions). This goes beyond a simple 'find calls' statement, though it doesn't mention pagination or return format.

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, front-loaded with the core purpose, efficiently lists matching methods, and contains no fluff or redundancy.

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

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

The description covers the tool's purpose, matching behavior, and when to use it. It lacks output format details, but with no output schema and a straightforward search tool, the provided information is sufficient for an agent to understand its functionality.

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?

All five parameters have schema descriptions covering 100%, so the baseline is 3. The description adds context about matching logic but doesn't provide additional parameter-specific details beyond what the schema already offers.

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 finds all Gong calls for a specific company/account, lists specific matching methods, and claims it is the best tool for this use case. This distinguishes it from general search-calls and other siblings.

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

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

The description explicitly says 'This is the best tool for finding all calls with a specific customer,' giving clear context for when to use it. However, it does not mention when not to use it or alternative tools for other 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 carries the behavioral disclosure burden. It does disclose the types of data returned (attendees, topics, highlights, next steps, key points, call outcome), which gives some insight into behavior. However, it does not mention potential errors, authentication requirements, rate limits, or the response format, leaving gaps in transparency for a no-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 a single, front-loaded sentence that efficiently states the action and resource, then lists the relevant detail categories. No unnecessary words or repetition are present, making it highly concise and well-structured.

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

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

For a simple one-parameter read tool with no output schema, the description lists the key return fields (attendees, topics, highlights, next steps, key points, call outcome), providing a reasonable understanding of what the tool returns. However, it does not mention error behavior or response structure, and with no output schema it could have been more explicit about the format, but overall it is sufficiently complete for its simplicity.

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 one parameter (callIds) with a complete description ('Array of Gong call IDs to retrieve details for'), achieving 100% schema coverage. The tool description does not add further parameter semantics beyond referencing 'specific calls' and the types of details, but since schema coverage is high, the baseline 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 uses a clear verb 'Get' with a specific resource ('detailed information about specific Gong calls') and enumerates the content (attendees, topics, highlights, etc.). It does not explicitly distinguish from sibling tools like get-call-transcript or search-calls, but the listed fields imply a distinct purpose of retrieving comprehensive call metadata rather than transcripts or search results.

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 is used when you have specific call IDs and need detailed call information, but it does not explicitly state when to use it versus alternatives. There is no mention of prerequisites (e.g., first find call IDs via search-calls) or exclusions (e.g., use get-call-transcript for transcripts). The usage context is only implied by the phrasing 'for specific Gong calls'.

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 meaningfully specifies that the output includes speaker attribution and timestamps, going beyond a minimal statement. It does not disclose edge cases or error behavior, but for a simple read operation this is reasonably 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 two sentences with no redundancy or filler. It front-loads the primary action and immediately states the key return characteristics, making it highly efficient.

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

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

For a tool with one parameter and no output schema, the description adequately covers what the tool does and what the response contains. It could elaborate on response structure or limitations, but given the tool's simplicity, the information is sufficient for most use cases.

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 input schema already fully documents the single 'callIds' parameter as an array of Gong call IDs. The description adds no further parameter-specific meaning, matching the baseline for high schema coverage.

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 retrieves full transcripts for Gong calls, with a specific verb ('Get') and resource ('transcript'). It differentiates from sibling tools like get-call-details by specifying transcript-specific output (speaker-attributed text with timestamps).

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 when a caller needs a call transcript, but it provides no explicit guidance on when not to use it or how it compares to alternatives like get-call-details or search-calls. Usage context is inferred rather than explicitly stated.

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 disclose behavioral traits. It only states 'Get details,' which implies a read operation but does not clarify what happens if the user is not found, whether any sensitive fields are omitted, or if any special permissions are required. This lack of detail is a significant gap for a tool carrying the full transparency burden.

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, front-loaded sentence that immediately states the verb, resource, and key parameter. It contains no fluff or redundant phrasing, and every word contributes to understanding the tool's purpose.

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 read tool, the description adequately conveys the core functionality and input. However, with no output schema, the vague term 'details' leaves the return structure undefined, and there is no mention of error behavior or output fields. It is minimally complete but could be more informative.

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 already provides full documentation for the only parameter (userId) with 'The Gong user ID', and the description's 'by their user ID' adds no new semantic nuance. Per the rubric, with 100% schema coverage, the baseline is 3, and the description does not elevate beyond that.

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 tool's action ('Get details') and resource ('a specific Gong user'), and specifies the input criterion ('by their user ID'). This distinguishes it from sibling tools like list-users, which would return multiple users.

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 when to use the tool: when you have a specific user ID and need its details. However, it does not explicitly contrast with alternatives like list-users or mention when not to use it, leaving the usage guidance implicit rather than explicit.

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?

There are no annotations, so the description must carry the behavioral disclosure burden. It states the output includes title, date, duration, and participants, but doesn't mention optional workspace filtering, maxRecords default, pagination, or whether it is strictly read-only. This is a basic disclosure but lacks depth.

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

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

The description is two sentences, front-loaded with the purpose, and includes a concise return-value note. 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 simple list tool without annotations or output schema, the description minimally explains the return fields and date range, but omits optional parameters and any pagination/limit behavior. It is adequate but has clear gaps.

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 descriptions cover 100% of parameters, documenting ISO formats, default for maxRecords, and workspaceId filter. The description adds no independent parameter semantics beyond mentioning the date range, so 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 states the tool lists Gong call recordings within a date range, using the verb 'List' and a specific resource. It differentiates from get-call-details/transcript by focusing on metadata, but doesn't mention alternatives like search-calls.

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 a clear usage context (date range) but provides no guidance on when to use this tool instead of search-calls or find-calls-by-company. No exclusions or alternatives are mentioned.

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 relies on the verb 'list' to imply read-only behavior. It adds purpose but does not disclose potential complexities like authentication, rate limits, or whether all user fields are returned. This is a moderate gap for a simple list 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 two sentences long, front-loaded with the primary action, and the second sentence adds relevant use-case context. No unnecessary details.

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

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

For a tool with no parameters and no output schema, the description is adequately complete. It conveys the purpose and the typical output (user IDs, names, emails), making the tool understandable and sufficient for an agent to select and invoke it.

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, so the baseline is 4. The description adds value by explaining the output is useful for mapping user IDs to names and emails, which provides context 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?

The description clearly states the tool lists all Gong users in the account, using a specific verb and resource. It distinguishes itself from siblings like list-calls and get-user by focusing on users and the 'all' 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?

It provides a clear use case ('mapping user IDs to names and emails') which implies when to use this tool. However, it does not explicitly mention alternatives or when not to use it, such as when needing a single user's details.

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 the return payload ('full details including attendees, topics, highlights, and next steps') and does not disclose pagination, maxRecords behavior, filter combination semantics, or the read-only nature of the operation. This is a minimal disclosure for a search tool with no safety hints.

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

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

The description is two sentences: first sentence states purpose, second states output value. It is front-loaded, concise, and free of filler or tautology.

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?

With 6 parameters and no output schema, the description provides a high-level overview but omits crucial invocation context: all parameters are optional, how filters combine (AND/OR), maxRecords default, and pagination behavior. It is adequate but has clear gaps for an agent to correctly use the tool in complex scenarios.

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 each parameter already has a description. The tool description adds no extra semantics about parameter interactions, defaults, or edge cases (e.g., how callIds interacts with date filters). Baseline of 3 is appropriate since the description lists filters but does not enrich the parameter meanings 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 opens with a specific verb + resource: 'Search for Gong calls by date range, user, workspace, or call IDs.' It clearly identifies the tool's scope and differentiates from siblings like get-call-details and find-calls-by-company by enumerating distinct filter dimensions.

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 by listing supported filters (date range, user, workspace, call IDs), but it does not explicitly state when to prefer this tool over alternatives like list-calls or find-calls-by-company. There is no 'use this when' or 'instead of' guidance.

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