mcp-daktela

by hajekd

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.1.0
Disambiguation3/5
There is meaningful overlap between generic tools (list_activities, get_activity) and channel-specific lists/gets (list_calls, get_call, list_emails, get_email, etc.). The descriptions clarify that channel-specific tools return extra fields, but agents may still be uncertain which to use. scan_calls, list_call_transcripts, and get_call_transcript also overlap in purpose.
Naming Consistency4/5
The dominant pattern is verb_noun (list_*, get_*, count_*), which is consistent and predictable. A few names deviate stylistically (scan_calls, scan_emails, get_call_transcript, list_call_transcripts, get_ticket_detail), but these are minor and don't undermine the overall pattern.
Tool Count2/5
With 45 tools, the server is heavily weighted by nearly identical channel-specific list/get pairs for activities. This feels excessive for the underlying domain, even for a contact-center platform. The count would be more reasonable if generic activity tools were removed or channel-specific tools were consolidated.
Completeness3/5
The tool set covers read-only operations for tickets, activities, contacts, accounts, CRM records, campaigns, knowledge base, users, and reference data. However, many entities have list_* but no corresponding get_* (e.g., users, groups, pauses, statuses, templates), and there are no write/update/delete tools at all, which limits the usefulness for management workflows.
Average 4.4/5 across 45 of 45 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on February 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It documents pagination semantics but does not mention whether all templates are returned regardless of status, if there is any default ordering, or potential limitations. Basic read-only behavior is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, front-loaded with the main purpose, and contains an organized args block. It repeats information already present in the schema (default values), but the duplication is minimal and the overall structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential elements: purpose and both parameters. It does not explain return values (already handled by output schema) and lacks edge-case details, but for a basic list operation it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by clearly explaining the 'skip' and 'take' parameters with their roles and default values. This adds meaning beyond the raw integer schema and gives the agent actionable details for pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all message templates' with specific channel examples, making the tool's purpose unambiguous. It naturally distinguishes itself from sibling list_* tools by naming its resource type, though it does not explicitly cite an alternative or exclusion, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you would use this when you need message templates. However, there is no explicit guidance on when to use this over alternatives, no mention of exclusions, and no reference to sibling tools that could be confused with it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It only says 'List all groups,' which implies a read operation, but it does not explicitly disclose that it is non-destructive or safe, nor does it clarify that 'all' is constrained by pagination (though skip/take are documented). The parenthetical about groups' purpose adds semantic context, not behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and effectively front-loaded with the primary action, followed by a brief purpose note and a clean args list. Every sentence earns its place, and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to detail return values. However, it omits any mention of sorting, filtering, or limits beyond the pagination defaults, and it does not provide guidance on when to use this tool relative to closely related siblings. The purpose note helps, but the description remains minimal for a tool in a large family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for skip or take (0% coverage), so the description compensates fully by explaining 'Pagination offset' and 'Number of records to return.' This adds meaningful semantics beyond the schema's type and default information, covering all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'groups,' and the parenthetical explains the purpose of groups (organizing categories, queues, users, or profiles), which helps differentiate it from sibling list tools like list_queues or list_users. This is specific and distinguishes the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource and its organizing role, but does not explicitly state when to use it instead of other list tools, nor does it mention any exclusions or prerequisites. The context is present but lacks direct alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It reveals that the operation is a read ('Get') but adds no further behavioral details such as permissions, side effects, or error conditions. The 'full details' claim is vague, though the output schema may fill some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a single action sentence plus a parameter explanation. Every part is useful and there's no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with an output schema, the description covers the essential purpose and parameter semantics. It lacks explicit channel differentiation guidance, but the tool name and sibling context help. Overall, it's nearly complete but could mention that it's specific to Viber.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'name' as a string without description (0% coverage). The description compensates by explaining the expected format ('ACT00123') and source (list_viber_chats), fully clarifying the only parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving full details of a single Viber activity by ID. It includes a concrete example ('ACT00123') and references list_viber_chats as the source for the ID, distinguishing it from sibling chat tools for other channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a Viber activity ID is available and full details are needed. However, it doesn't explicitly mention alternatives or when not to use it, such as avoiding confusion with get_activity or other channel-specific getters. Guidance is minimal but sufficient for simple cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'Get full details' which implies a read operation but does not explicitly confirm read-only behavior, side effects, error handling, or permission requirements. This lack of disclosure is a gap for a tool that could have side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and includes a well-structured 'Args' section. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and an existing output schema, the description provides adequate context. It names the resource and parameter source, and since output schema exists, return values need not be described. The only minor gap is lack of guidance on expected failure modes, but overall it is complete for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'name' as a string. The description compensates fully by explaining it is a WhatsApp activity ID, providing an example format ('ACT00123'), and pointing to the 'name' field from list_whatsapp_chats. This adds clear meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details of a single WhatsApp activity by its ID' – a specific verb (Get) + resource (WhatsApp activity) + identifier. This distinguishes it from sibling tools like get_messenger_chat or get_instagram_chat, which target different channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a WhatsApp activity ID, and suggests referencing the 'name' field from list_whatsapp_chats. However, it does not explicitly explain when to choose this over alternatives or mention any exclusions, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses pagination behavior (skip/take defaults) but does not explicitly state read-only behavior, ordering, permissions, or potential errors. The list verb implies safety, but it is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and efficient: one sentence for purpose, then a clean 'Args:' block. No fluff or repetition. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and an output schema exists, so return values are covered. However, the description lacks guidance on when to select this tool over similar list tools (e.g., list_statuses, list_templates) and does not mention any access requirements or edge cases. It is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains skip as 'Pagination offset' and take as 'Number of records to return' with defaults, adding meaningful context beyond the raw schema properties. This is sufficient for the two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all pause types available to agents, with concrete examples like wrap-up and DND. This distinguishes it from sibling list tools by focusing on a specific resource (pause types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool's purpose—if you need pause types, use this tool. However, there is no explicit mention of when to use it versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses pagination behavior via skip/take parameters, which is useful. However, it does not explicitly state that the operation is read-only or non-destructive, and the phrase 'List all' is at odds with the default take=200, implying a bounded result set. This internal inconsistency slightly undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, front-loads the main purpose, and separates the argument explanations cleanly. There is no redundant fluff; every sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (2 optional pagination params, an output schema for return structure), the description provides adequate context. It identifies the resource, mentions the reference data fields, and explains pagination. No further context is needed for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description manually explains both parameters (skip: pagination offset, take: number of records). This adds meaning beyond the bare integer types and defaults in the schema, though it could be slightly more detailed (e.g., maximum take value or interaction between skip and take).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all ticket/record statuses') and identifies the resource (statuses as reference data with name, title, color). This distinguishes it from sibling tools like list_ticket_categories, which deal with different reference data. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios, exclusions, or refer to any sibling tools that might overlap. The phrase 'reference data' implies a lookup context but stops short of explicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to clarify read-only behavior, error cases, or permissions. The description only says 'Get full details,' which implies a read but does not disclose what happens if the account is not found, what 'full details' includes, or any side effects. The description carries the full burden and under-delivers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: one purpose sentence followed by a clear args section with an example. Every sentence earns its place with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the presence of an output schema, and the single parameter, the description is mostly complete. It explains the parameter semantics and leads the user to the right listing tool. It does not discuss edge cases, but these are less critical for a straightforward get-by-ID operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by explaining that 'name' is the account internal ID, providing a concrete example, and cross-referencing list_accounts for finding the ID. This adds valuable meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: "Get full details of a single account by its internal ID." It uses a specific verb-resource combination and distinguishes itself from sibling tools like list_accounts and get_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on how to obtain the required ID via list_accounts(search='...'), which is a clear alternative for when you only know the company name. However, it does not explicitly state when not to use this tool or compare it with other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It discloses search semantics (partial match on title), account ID requirement, pagination defaults, and max take. This adds meaningful behavioral context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but every sentence earns its place. The purpose statement is clear and the Args section is well-structured with each parameter explained. No fluff, though the field enumeration could be considered slightly redundant if the output schema already includes it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still adds valuable context: search field behavior, account ID semantics, pagination limits. It covers the key aspects an agent needs to invoke this tool correctly. Missing details like sorting or error behavior, but these are not critical for a list/search operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: search targets the 'title' field, account must be an internal ID (with pointer to list_accounts), and skip/take have clear defaults and max value. This is exactly what the agent needs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search and list contacts' with a specific verb and resource, and lists the contact fields returned. It doesn't explicitly differentiate from sibling list tools (e.g., list_accounts), but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides some usage context by explaining the search behavior and the account filter (including that it's an internal ID, not a company name). However, it doesn't explicitly state when to use this tool versus alternatives like get_contact or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses that the tool returns email-specific fields (subject, address, body, timing), but it does not explicitly confirm side-effect-free behavior, error conditions, or permissions. The verb 'Get' implies read-only, but explicit disclaimers are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The parameter explanation is structured separately and is free of fluff. Every sentence earns its place, and the length is appropriate for a one-parameter read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation with an output schema, the description covers purpose, return value highlights, and parameter details. It could be more complete by explicitly stating read-only behavior or differentiation from get_activity, but these are minor gaps given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains the 'name' parameter with format examples ('ACT00123') and provenance (field from list_emails). This adds significant meaning beyond the bare string type in the schema, making the parameter self-documenting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('email activity'), and scope ('single... by its ID'). It also lists email-specific return fields, distinguishing it from generic get_activity and list-style siblings like list_emails. This is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have an email activity ID and need full details. It also provides a hint about obtaining the ID from list_emails. However, it does not explicitly state when not to use it or mention alternatives such as get_activity, so guidance is mostly implicit rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Get full details' and provides no behavioral context such as read-only nature, authentication requirements, rate limits, or error handling. The presence of an output schema covers return values, but the description adds minimal behavioral disclosure beyond what the tool name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured: a one-sentence purpose followed by a single parameter definition. It is front-loaded with the key information, contains no filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with an output schema, the description covers the essential purpose, parameter, and source relationship. It lacks explicit guidance on when not to use it or comparison to alternatives, but the reference to list_messenger_chats partially fills that gap. Overall, it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the description fully compensates. It explains that 'name' is the Messenger activity ID, provides an example format ('ACT00123'), and tells the agent how to source it from 'list_messenger_chats'. This is rich, actionable semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get full details of a single Facebook Messenger activity by its ID.' It clearly identifies the action (get), the resource (Facebook Messenger activity), and the scope (single, by ID). This distinguishes it from sibling get_*_chat tools by specifying the channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: obtain an ID from 'list_messenger_chats' and then call this tool to get full details. The example and reference to the list function provide clear contextual guidance on when to use this tool, though it does not explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses pagination behavior through the skip and take parameters, and 'List all campaign types' implies a read-only operation. However, it does not explicitly state read-only status, return format, or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. It uses two short sentences plus a parameter list, with no filler or redundant information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple reference-data listing with two optional parameters and an output schema. The description covers the core purpose and pagination semantics, and since an output schema exists, it need not explain return values. It is slightly sparse on broader context (e.g., use cases, relationship to other campaign tools), but adequate for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description fully explains both parameters: 'skip: Pagination offset (default: 0)' and 'take: Number of records to return (default: 200).' This adds clear semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all campaign types (reference data for outbound campaigns).' It uses a specific verb and resource, and the context 'reference data for outbound campaigns' distinguishes it from other list tools like list_tickets or list_campaign_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by labeling campaign types as 'reference data for outbound campaigns,' but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. No alternative or 'use when' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosure. It mentions that it 'Returns the complete activity record including all channel-specific fields,' which is a useful behavioral detail. However, it does not address error cases, permissions, or any request constraints, leaving room for added transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an args snippet. It is front-loaded with the purpose, immediately followed by usage guidance and parameter details. Every sentence earns its place with no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (not shown here), which likely describes the return structure, and the description specifies that it returns 'the complete activity record including all channel-specific fields.' For a simple single-ID getter, this sufficiently covers the main context, though it could mention not-found behavior or authorization requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description, so schema coverage is 0%, but the description's 'Args' section compensates by explaining the `name` parameter with a realistic example ('ACT00123') and a clear format rule ('Always starts with 'ACT' followed by digits'). This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('activity'), and the specific scope ('full details of a single activity by its ID'). This distinguishes it from sibling tools like list_activities, which lists activities, and get_call/get_email, which target specific channel types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage condition: 'Use this when you already know the activity ID.' This implies that you should first use a listing tool to find the ID, but it does not explicitly name the alternative, such as list_activities. Clear context with no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses behavior beyond the basic 'get' action: transcripts are chronological with timestamps, and not all calls have transcripts (missed/short/no-STT) returning 'No transcript available.' This adds useful behavioral context that is not apparent from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in one sentence, followed by return-format detail and a well-structured 'How to get the activity name' section using bullets. It is not overly verbose and each section adds value, though the parameter guidance is somewhat lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) with an output schema but no annotations. The description covers the return value (timestamps, 'No transcript available'), the parameter source, and an example. It does not discuss error handling or auth, but given the low complexity and rich parameter description, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'activity' as a string, with 0% semantic coverage. The description compensates excellently: it explains the parameter is the activity name/ID, provides an example ('activity_699351d84288a407003861'), and explicitly tells the user where to find it (the 'Activity' field in list_calls/get_call or the 'name' field from list_activities). This is far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get the full speech-to-text transcript of a specific call,' which is a specific verb+resource combination. It clearly differentiates from siblings like list_call_transcripts by focusing on a single call's transcript rather than a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need a specific call's transcript) but does not explicitly state alternatives/exclusions. It does not mention 'use list_call_transcripts to list all transcripts' or 'use get_call for call metadata.' The note about calls without transcripts gives some context, but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 usefully discloses the prefix-stripping behavior for the ticket ID. However, it does not mention error handling, permission requirements, or confirm it is read-only. For a simple read tool this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an Args block. It opens with the core purpose in the first sentence and front-loads the primary usage instruction. No redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description provides enough context: it explains what the tool does, when to use it, and fully defines the parameter. The only minor gap is the lack of distinction from get_ticket_detail, but for the tool's simplicity, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description fully compensates. It explains that the 'name' parameter is a numeric ticket ID, provides an example (787979), and details automatic prefix stripping. This goes well beyond the bare schema, which only says 'string'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details of a single ticket by its ID.' It specifies a single ticket and the lookup by ID, distinguishing it from list-oriented tools. However, the presence of a sibling named get_ticket_detail, which likely performs a very similar function, is not addressed, and the description does not differentiate from it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this when you already know the ticket ID.' This tells the agent when to invoke the tool, but it does not mention when not to use it or mention alternative tools like list_tickets or get_ticket_detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return shape (hierarchical view, article counts) and pagination parameters, but it does not explicitly state that the operation is read-only, nor does it mention behavior on empty results, sorting order, or rate limits. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose sentence, return summary, cross-tool usage note, and a clear Args list. Every line earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list tool with an output schema, the description covers the core purpose, return nature, and parameter semantics. It also includes a usage cross-reference. It does not mention potential edge cases like empty folders or ordering, but those are not critical given the output schema and simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows integer types and defaults, with 0% coverage. The description compensates by defining each parameter: 'skip: Pagination offset (default: 0)' and 'take: Number of records to return (default: 200).' This adds necessary meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific action: 'List all knowledge base article folders in a tree structure.' It identifies the resource (knowledge base article folders) and output format (tree hierarchy with article counts). This distinguishes it from siblings like list_articles, which lists articles rather than folder structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: 'Use the folder 'name' field to filter articles by folder in list_articles.' This tells the agent how to combine this tool with a sibling. However, it does not explicitly state when NOT to use this tool or contrast it with alternatives, so it misses the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry safety and behavior disclosure. The verb 'Get' implies a read-only operation, but there is no explicit statement about side effects, required permissions, or rate limits. This is acceptable for such a simple getter, though 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an inline arg doc. It is front-loaded and contains no filler; every element adds selection or invocation value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the tool doesn't need to describe return values. It covers the single parameter fully and provides a source for valid IDs. It could have mentioned channel alternatives, but the name and sibling list make the scope clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a required 'name' string with zero description, but the description fully explains it: 'The web chat activity ID (e.g. ACT00123 or the name field from list_web_chats).' This entirely compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get full details of a single web chat activity by its ID.' This clearly distinguishes it from the list tool and aligns with the get_* sibling pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: when you have a web chat activity ID (e.g., ACT00123) or a name from list_web_chats. It does not explicitly list exclusion criteria or alternatives, but the channel-specific naming and source pointer offer sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is a real-time snapshot (non-persistent) and enumerates the session state fields. However, it does not explicitly state that it is read-only, mention pagination limits or ordering, or address potential changes between calls, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a clearly formatted Args block with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema available, the description sufficiently covers purpose, returned fields, and parameter semantics. It does not need to explain return values since the output schema exists, and the tool's low complexity means no additional prerequisites or side effects need to be detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes an Args section that explains skip as pagination offset and take as number of records, adding meaning beyond the raw schema. The explanations are clear but simple, without additional constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a resource 'realtime sessions' and explains that it provides a real-time snapshot of currently active agent sessions. It also lists the displayed fields (state, extension, pause reason), which differentiates it from sibling tools like list_pauses or list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for getting a current snapshot of active sessions (real-time), distinguishing it from historical list tools. However, it does not explicitly mention alternatives or exclusions, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. 'Get' implies a read-only operation, and the ID-source hint adds a bit of context, but the description does not mention what happens if the ID is not found, whether authentication is required, or any side effects. For a simple getter, this is acceptable but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the purpose in the first sentence and a single parameter explanation in a clean 'Args' block. Every word earns its place, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with an output schema present, the description is complete. It covers the purpose, the parameter semantics, and even points to the related list tool. Error handling is not described, but the output schema already informs the return shape, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% coverage for parameter descriptions, the description fully compensates by explaining the 'name' parameter with a concrete example ('ACT00123') and specifying that it is the 'name' field from list_instagram_chats. This adds significant meaning beyond the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get'), resource ('full details of a single Instagram DM activity'), and access method ('by its ID'). It distinguishes from sibling tools by explicitly naming the channel (Instagram DM) and the action, making it stand apart from generic get_activity or other channel-specific getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining that the 'name' parameter is the Instagram activity ID and pointing to list_instagram_chats as the source for this ID. This implies when to use the tool (after listing chats) without explicitly stating exclusions. It could be improved by explicitly saying to use this instead of get_activity for Instagram DMs, but the channel specificity is already conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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. 'Get full details' implies a read operation, but it does not specify what details are included, any prerequisites, or potential side effects. It is not misleading, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, the second explains the parameter. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter and an output schema. The description covers the purpose and the parameter meaning, and the output schema handles return values. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'name' as a string, but the description explains it is the SMS activity ID, provides a concrete example ('ACT00123'), and mentions it can be obtained from list_sms_chats. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get full details of a single SMS activity by its ID' with a specific verb and resource, clearly distinguishing it from sibling getters like get_call or get_email by the SMS context. It unambiguously identifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have an SMS activity ID and need full details, and it points to list_sms_chats as a source for the ID. It does not explicitly name alternatives or exclusions, but the context is clear and the mention of list_sms_chats provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 discloses meaningful behaviors: pagination defaults and max (skip, take), sort direction default (desc), user name resolution, contact ID requirement, and date filter semantics. This goes beyond a simple 'list' description and provides operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a one-sentence purpose followed by a clear Args block. It covers all 8 parameters without unnecessary verbosity, and the most relevant operational details (filters, pagination) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 optional parameters, no annotations, output schema available), the description is complete: it clarifies the domain, parameter semantics, defaults, and limits. The output schema handles return structure, so no extra explanation is needed. The description provides all essential usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully with an Args section that explains every parameter: user (display vs login name, auto-resolution), contact (internal ID, not a name, with hint to list_contacts), date_from/date_to format, sort field examples, and pagination defaults. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List campaign records' with an explicit definition in parentheses: 'outbound campaign activity — calls made, results.' This is a specific verb+resource pair that clearly distinguishes the tool from siblings like list_calls or list_crm_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its purpose and parameter filters (e.g., user, contact, date range), but it does not explicitly state when to prefer this tool over alternatives or provide any exclusion criteria. It lacks direct comparisons like 'use instead of list_calls'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the listing behavior, pagination via skip/take, and the significance of the 'name' field. However, it does not disclose potential permissions, rate limits, or whether the list includes inactive categories, which are minor but relevant behavioral traits for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: two concise sentences front-loaded with purpose and usage, followed by a clear Args block. Every sentence adds value without unnecessary fluff or repetition of schema defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of this tool (two optional parameters, an output schema, and no annotations), the description covers purpose, usage, and parameter semantics thoroughly. It also situates the tool within the broader ticket workflow, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides complete, useful explanations for both parameters ('skip: Pagination offset', 'take: Number of records to return') including defaults, and additionally clarifies how the output's 'name' field is used elsewhere, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all ticket categories' with a specific verb and resource. It also distinguishes this tool from siblings by explaining it is the first call to find valid category names for ticket filtering, and explicitly maps the 'name' field to the 'category' parameter in list_tickets/count_tickets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Call this first to find valid category names for ticket filtering' and explains how to use the result in downstream tools. However, it does not explicitly state when not to use it or mention alternative tools, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses warnings (e.g., 'WARNING: only fields that exist on this endpoint work — do NOT use created or edited'), default values (sort_dir, skip, take), pagination limits, and automatic resolution of user names. It does not mention auth, rate limits, or return format, but since an output schema exists, that gap is acceptable. The warnings and defaults add substantial transparent context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a clear list of arguments, each with one line of explanation. It is slightly long due to 10 parameters, but every line adds value, including the warning about sort fields. The format is scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no schema documentation), the description is highly complete. It covers all parameters, defaults, and warnings. It does not mention authentication or rate limits, but these are not typically required for a list operation and are absent from most sibling descriptions. The output schema provides return-value details, so the description does not need to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly, explaining all 10 parameters with examples (e.g., queue '10333', contact ID format), constraints (direction IN/OUT, date format YYYY-MM-DD), and warnings (sort field limitations). This goes far beyond the schema, which only provides types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'List Viber activities with channel-specific fields,' which uses a specific verb ('List') and resource ('Viber activities'). This clearly distinguishes it from sibling tools like get_viber_chat (which retrieves a single chat) and other channel-specific list tools (list_messenger_chats, list_whatsapp_chats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is clear from the name and description, but it does not explicitly state when to use it over alternatives or mention exclusions (e.g., 'Use this instead of list_web_chats if you need Viber channels'). However, parameter guidance like 'Use list_queues to find names' and 'call list_contacts(search=...)' provides context on prerequisites. This is clear context but lacks explicit alternative comparisons, so a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does disclose useful behaviors such as case-sensitive stage values, partial-match search, include_merged defaulting to false, and auto-resolution of user display names. However, it does not state how multiple filters combine (AND vs OR), whether the count is capped, or explicitly confirm this is a read-only operation. These are notable gaps for a counting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose and alternative tool recommendation, followed by a structured args list. Every line adds value: no fluff, no repetition, and all parameter descriptions are succinct. It is long only because it covers 10 parameters meaningfully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be explained. The description covers all 10 parameters and provides necessary context for valid values. The only missing element is an explicit statement about filter combination semantics (AND/OR), which is important for a counting tool. Overall, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully compensates by explaining every parameter with examples and meaning. It provides valid values for stage/priority, clarifies that contact expects an ID not a name, gives date format, and describes search behavior. This goes far beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Count tickets matching filters,' which clearly states the verb+resource. It also explicitly distinguishes from list_tickets: 'Use this instead of list_tickets when you only need a number.' This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given for when to use this tool over a sibling: 'Use this instead of list_tickets when you only need a number.' Additionally, parameter-level instructions recommend calling list_ticket_categories, list_contacts, and list_statuses where needed, and clarify that user display names are resolved automatically, removing the need for list_users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description carries the transparency burden since no annotations are provided. It reveals behavior such as stripping TK prefix from ticket IDs, default/max for take, and the inclusion of activities. It doesn't discuss error cases or side effects, but 'get' implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact, front-loaded with a one-line summary, followed by a brief rationale and a clear args list. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, return values need not be described. The description covers purpose, use case, and parameter nuances. The only gap is lack of explicit error handling or alternative disambiguation, but overall it's sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides only names/defaults with no descriptions; description fully compensates by explaining name expects a numeric ID and handles prefixes, and take has a max of 100. Per rubric, low schema coverage requires compensation, which is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get a ticket with all its activities and their content in one call,' which is a specific verb+resource+scope. It clearly differentiates from sibling get_ticket by emphasizing bundled activities and being the recommended tool for analyzing a specific ticket.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'This is the recommended tool for analyzing a specific ticket' and justifies it by avoiding multiple round-trips. However, it does not explicitly mention when to use alternatives like get_ticket if only basic ticket info is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses key traits: filtering by owner, contact/account internal IDs (with a warning that they are NOT names), stage values, date range constraints, sort/pagination defaults, and the max limit of 200. This is substantial context beyond a simple 'list' operation. It does not mention rate limits or permission requirements, but for a read-only list operation, the disclosed behavior is fairly complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: one sentence for purpose, then a clean Args list. Each parameter explanation is concise yet informative, with examples and defaults. While it is somewhat long due to 10 parameters, no sentence is wasted, and the formatting improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters, no required parameters, and an output schema. The description covers all parameters, provides cross-references to related tools (list_users, list_contacts, list_accounts), and explains pagination and sorting. Since an output schema exists, the description need not elaborate on return structure. This is fully sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with concrete examples ('john.doe', 'contact_674eda46162a8403430453'), constraints (date format YYYY-MM-DD, stage OPEN/CLOSE), defaults (sort: edited, sort_dir: desc, take: 50), and warnings (contact is not a person's name). This goes far beyond what the schema's types and defaults provide, adding crucial semantic meaning for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'List CRM records (deals, opportunities, or other CRM entities).' This clearly states the tool's action and object, and the inclusion of examples ('deals, opportunities') helps distinguish it from sibling list tools like list_tickets or list_emails. Though 'other CRM entities' is vague, the core 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but it provides clear operational guidance for parameters, such as 'Use list_users to find login names' and 'call list_contacts(search=...) first to find the ID.' This tells the agent how to prepare inputs and indirectly implies the tool's role in a workflow. However, it lacks an explicit 'when not to use' or direct sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the output fields (CLID, duration, wait/ring/hold times, missed call status, disposition) and the read-only nature implied by 'Get.' However, it doesn't explicitly state safety (e.g., no side effects) or error behavior for invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two minimal sentences plus a single argument definition. Every sentence earns its place—purpose, usage condition, return fields, and parameter explanation—with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description covers purpose, when to use it, return fields, and parameter semantics. It is fully complete for an agent to select and invoke it correctly, especially with the output schema available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare string parameter 'name' with zero description coverage. The description compensates fully by explaining 'name: The call ID (the id_call field from list_calls),' adding provenance and semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair: 'Get full details of a single call by its call ID.' It clearly distinguishes from sibling tools like list_calls or scan_calls, and lists the specific fields returned, reinforcing its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this when you already know the call ID,' providing a clear condition for use. It implies a workflow with list_calls by referencing the 'id_call' field, but doesn't explicitly name alternatives or exclusions, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Get full details' implies a read-only operation, but it does not explicitly state side effects, error behavior, or auth requirements. It is adequate for a simple getter but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the purpose, followed by a clear usage guideline and a brief parameter explanation. Every sentence earns its place with no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, output schema present), the description covers purpose, usage, and parameter semantics without needing to detail return values. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining that the 'name' parameter is actually the contact ID, points to the source field from list_contacts, and provides an example format (CT00123). This adds crucial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get full details of a single contact by its ID' with a specific verb and resource. It clearly distinguishes from sibling tools like list_contacts (which lists contacts) and other get_* tools by specifying the target resource and uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this when you already know the contact ID' gives an explicit usage condition. It references list_contacts as the source of the ID, implying that list_contacts is the alternative when the ID is unknown, providing clear guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently describes the listing behavior, filtering options, defaults, and pagination limits (e.g., 'take: default 50, max 200'). It does not mention permissions or rate limits, but for a read-oriented list tool the main behaviors are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is immediately useful, front-loading the purpose before a clean, line-by-line Args section. Every sentence contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 optional parameters, no annotations, and the presence of an output schema, the description covers all necessary context: purpose, every parameter, pagination defaults, and a pointer to a related tool for user lookup. The output schema handles return-value expectations, so no further detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates exceptionally well. Every one of the 8 parameters is explained with types, examples, defaults, and constraints — e.g., 'search: partial match, e.g. Notino or Siemens' and 'take: default 50, max 200'. This adds meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List accounts (companies/organizations)', clearly identifying the verb and resource. It further distinguishes the tool's domain by noting 'Contacts belong to accounts', which helps disambiguate it from contact-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool (for listing accounts) and even references a sibling tool ('Use list_users to find login names') for a specific sub-task. However, it does not explicitly contrast with alternatives like get_account or list_contacts, so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals useful traits: automatic name resolution, partial matching, default stage behavior, and a performance warning for 'ALL' stage ('slower for large accounts'). It stops short of describing auth or rate limits, but covers key operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief summary, a clarifying note about name resolution, and a clean Args list. Despite the length from 12 parameters, each sentence earns its place and directly supports tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 params, no annotations) and that an output schema exists, the description is thorough. It explains all parameters, defaults, and caveats such as pagination max ('take: max 200'), making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by detailing every parameter: accepted formats, defaults, allowed values, and even performance implications (e.g., 'ALL' is slower). This adds far more meaning than the bare schema, which lacks descriptions for all properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List tickets for a specific account (company/organization).' This clearly distinguishes it from sibling tools like list_tickets, and it explicitly mentions the ability to pass either a company name or account ID, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (for account-specific tickets) and even states a prerequisite shortcut: 'You do NOT need to call list_accounts first.' However, it does not explicitly contrast this tool with the likely alternative list_tickets, so the differentiation is implied 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers by warning against invalid sort fields ('do NOT use created or edited') and explaining user name resolution. It also documents defaults and the max take value, adding behavioral nuance beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and usage tip, followed by an organized Args list. Every line adds information, including the sort-field warning and user resolution note, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no annotations, the description covers every parameter, usage guidance, and a critical pitfall. An output schema exists, so the absence of return-value documentation is acceptable; the description is sufficiently complete for a complex listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are entirely absent (0% coverage), so the description must compensate. It does so thoroughly, explaining each of the 11 parameters with value enums, examples, and defaults, such as type channel codes and queue lookup via list_queues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List activities (calls, emails, chats, etc.) with optional filters,' which clearly states the operation and resource scope. The enumeration of channel types in the 'type' parameter further distinguishes it from channel-specific siblings like list_calls or list_emails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides concrete usage context with 'Always specify type and/or a date range to keep results focused,' and references list_queues for finding queue names. However, it does not explicitly contrast with alternative list tools or state when-not-to-use them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the transparency burden and does so well. It discloses that `search` uses Daktela's global search across title, description, content, and tags, that folder and tag names are resolved automatically, and that pagination defaults and max values are tuned because article records are larger. These are meaningful behavioral details beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and efficient. A brief introductory sentence is followed by a structured Args list where every line earns its place. There is no fluff or repetition, and the rationale for the smaller default `take` value is a useful, compact addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no schema descriptions, and no annotations, this description covers all the necessary operational context: search semantics, folder/tag resolution, filtering, pagination, and defaults. An output schema exists, so not detailing return values is acceptable. The description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate, and it does. Every parameter (`search`, `folder`, `tag`, `published`, `skip`, `take`) receives a clear explanation, including accepted value types, auto-resolution behavior, and default/max limits. This goes well beyond the bare type definitions in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Search and list knowledge base articles', which is a specific verb+resource combination. It also clarifies the scope by mentioning filtering by keyword, folder, or tag, and the sibling tool `get_article` suggests a distinct single-article retrieval use case, so this tool is clearly positioned as the search/list counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to find relevant KB articles by keyword, folder, or tag' provides clear context for when to use the tool. It does not explicitly mention alternatives or exclusions, but the search-and-list framing distinguishes it from related tools like `get_article` and `list_article_folders`, so the usage guidance is adequate though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses important behavioral traits like the automatic resolution of user names, the requirement that contact be an internal ID (not a name), and a specific warning about invalid sort fields. This goes beyond a generic listing description, though it does not cover authorization or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for 10 parameters. It opens with a clear one-sentence purpose, then uses a consistent param-name format with concise explanations. Every line adds value, including examples and warnings, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 10 optional parameters and no schema descriptions, the description covers all parameters meaningfully, including default and max values. It also references related tools for value lookup. The existence of an output schema means the description need not explain return values, and the provided information is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does so exceptionally well, providing examples for queue and contact, clarifying the user parameter accepts display or login names, default values for sort_dir, skip, take, and explicit warnings for sort. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Instagram DM activities with channel-specific fields, distinguishing it from siblings like list_messenger_chats or list_whatsapp_chats. The verb 'List' and resource 'Instagram DM activities' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong contextual guidance for using parameters, such as instructing to call list_queues for queue names and list_contacts to resolve contact IDs. It also warns about sort field limitations. However, it does not explicitly state when to use this tool versus alternatives like get_instagram_chat, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 adds valuable context, including that 'contact' is not a person's name but an internal ID, that user names are resolved automatically, and a warning that sort fields must exist on the endpoint (avoiding 'created'/'edited'). These go beyond the schema and reveal important behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a concise one-liner followed by an Args section. Each parameter gets a clear, non-redundant line. Despite the length, every sentence serves a purpose, and the structure aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count and no annotations, the description is remarkably complete. It covers all parameters, includes practical examples, and highlights edge cases. The output schema exists, so return values do not need to be explained. The description leaves little ambiguity for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all 10 parameters with formats, examples, defaults, and warnings. For instance, it clarifies the difference between display name and login for 'user', and warns about sort field limitations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'Facebook Messenger activities with channel-specific fields', using a specific verb and resource. This distinguishes it from sibling tools like list_instagram_chats and list_whatsapp_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is appropriate (Messenger activities) and includes explicit cross-tool references, such as using list_queues to find queue names and list_contacts to find contact IDs. It does not explicitly mention alternatives to exclude, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 covers the listing behavior, queue types, and pagination semantics. It does not mention rate limits, permissions, or ordering, but for a simple read-only list tool, the disclosure is adequate and adds useful context beyond the bare 'list' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and well-organized. The first sentence states the core purpose, followed by a useful note about usage in list_activities, then a compact list of queue types and an Args section. Every element adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the existence of an output schema (which handles return structures), and the thorough coverage of purpose, parameters, and cross-tool relationships, the description is complete for an agent to select and invoke this tool correctly. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines skip and take with default values, with 0% description coverage. The description fully compensates by explicitly explaining each parameter: 'skip: Pagination offset' and 'take: Number of records to return', along with defaults. This gives the agent all necessary meaning for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all queues' with a specific verb and resource, and goes further to distinguish this tool by listing queue types (in, out, email, chat, etc.). This effectively separates it from sibling list_* tools like list_tickets or list_calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool: the 'name' field of each queue is used as the 'queue' filter in list_activities, giving a concrete cross-tool workflow. However, it does not explicitly mention when not to use it or name alternative tools, 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.
Behavior4/5
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 discloses important behavioral traits: the user parameter can accept display or login names and is resolved automatically, the contact parameter must be an internal ID (not a person's name), and the sort field has a warning against using invalid fields like 'created' or 'edited'. This goes beyond a simple 'list' statement, though it doesn't mention auth, rate limits, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence overview followed by a clear Args list. It is detailed but not verbose; every line provides necessary information for correct usage. The warning about sort fields is important and earns its place, and the parameter explanations are compact yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no annotations, and an output schema (which handles return value documentation), the description covers all parameter semantics and key behavioral nuances. It provides actionable instructions for filters, pagination, and sorting. The only minor omission is explicit mention of auth or rate limits, but for a listing tool this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does so excellently. Every one of the 10 parameters receives a clear explanation, including formats, examples, defaults, and direct guidance (e.g., direction must be 'IN' or 'OUT', date formats are YYYY-MM-DD, sort_dir default is 'desc'). The descriptions add significant meaning beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List SMS activities with SMS-specific fields', clearly specifying the action (List), the resource (SMS activities), and the distinguishing detail (SMS-specific fields). This separates it from sibling tools like list_emails or list_web_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for listing SMS activities and includes helpful parameter guidance, such as using list_queues to find queue names and list_contacts to find contact IDs. It doesn't explicitly state when not to use this tool or name alternatives, but the focus on SMS-specific fields implies when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden of behavioral disclosure. It reveals that user names are 'Resolved automatically', warns that contact is an internal ID and not a person's name, and explicitly warns against invalid sort fields like 'created' or 'edited'. These are meaningful behavioral details beyond the raw function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for a 9-parameter tool. It opens with a single purpose sentence, then uses a clean, indented Args block with one line per parameter, including examples and warnings. Every sentence adds value; there is no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and an output schema present, the description is fully sufficient. It covers all parameters, provides defaults, warns about invalid inputs, and references companion tools for ID lookup. The presence of an output schema means return values need not be described in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every one of the 9 parameters, including value formats, defaults, and cross-tool lookups. This goes well beyond the bare schema and is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List web chat activities with chat-specific fields (state, disconnection, missed)', using a specific verb and resource that clearly distinguishes it from sibling tools like get_web_chat or list_messenger_chats. The tool's scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear and contextual clues like 'Use list_queues to find names' and 'call list_contacts(search=...) first' provide cross-tool guidance. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It reveals important behavioral details such as the sort field warning ('do NOT use created or edited'), automatic resolution of user display names and login names, default values for sort_dir, skip, and take, and the maximum take of 200. It does not explicitly mention that the operation is read-only, but that is implicit in the list verb and no side effects are described. The disclosure goes beyond the schema and adds valuable operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a one-sentence summary followed by a well-organized Args list. Each parameter gets a concise, information-dense line with no filler. The warning about sort fields is relevant and embedded inline. The structure is front-loaded and every sentence earns its place, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (10 parameters, no annotations, no schema descriptions), the description is remarkably complete. It covers all parameters, defaults, max limits, and behavioral warnings. Since an output schema exists, the absence of return-value explanation is acceptable. The description fully equips an agent to select and invoke the tool correctly, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate, and it does. Every parameter is explained with examples, formats, and clarifications (e.g., contact is 'NOT a person's name' and requires list_contacts lookup, date_from/date_to specify YYYY-MM-DD, sort lists useful values and warns against invalid ones). This adds significant semantic meaning beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List WhatsApp activities with channel-specific fields,' which combines a specific verb (list) with a specific resource (WhatsApp activities) and a distinguishing qualifier (channel-specific fields). This clearly sets it apart from sibling tools like list_emails or list_web_chats, and the name itself reinforces the WhatsApp channel focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by indicating it lists WhatsApp activities with channel-specific fields, implying it is the WhatsApp-specific list variant among siblings. It also gives cross-references to list_queues and list_contacts for resolving parameter values, which guides correct usage. However, it does not explicitly state when not to use it or name alternative tools for other channels, so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that transcripts are fetched in parallel server-side, that calls without transcripts are included but marked 'No transcript available', and that the tool retrieves complete customer + operator dialogue. Pagination behavior is also explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, use cases, behavior notes, pagination guidance, and an Args list. However, there is some redundancy: the parallel transcript fetching and full-transcript inclusion are mentioned in both the main text and the Args section, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no annotations, the description is remarkably complete: it covers the core purpose, filtering options, pagination strategy, default/max values, and the behavior with missing transcripts. The presence of an output schema further reduces the need to describe return values, so no crucial context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions (0% coverage), so the detailed Args section fully compensates. It explains date format (YYYY-MM-DD), that user accepts display or login names and is 'Resolved automatically', that queue expects an internal name usable with list_queues, and that take has default 20 and max 50.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List answered calls with their full speech-to-text transcripts inline', making the purpose specific and distinct from siblings like list_calls or get_call_transcript. It also positions itself as 'the primary tool for analyzing call quality', reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: 'analyzing call quality, identifying calls requiring management attention, detecting escalations, or reviewing agent performance', and gives pagination guidance. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks the explicit when/when-not contrast required for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: it takes time, processes each call with AI, returns only one page, and requires iterating through all pages for reliable results. It also explains that the first page may not be representative, which is critical for safe and accurate use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with headings, bolded warnings, and bulleted examples. It is front-loaded with the core purpose and important caveats. There is minor redundancy between the CRITICAL warning and the Pagination section, but every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full context: what it returns, pagination behavior, parallel call requirements, and the follow-up tool. Given the tool's complexity (AI scoring, pagination, user communication), this is complete enough for an agent to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, but the description compensates with an 'Args' section covering all 7 parameters, including formats, defaults, and examples (e.g., queue: '10333', date_from: 'YYYY-MM-DD'). This adds meaning well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'AI-score answered calls in a date range. Returns one page of scored results.' This uses a specific verb and resource, and distinguishes it from sibling tools like list_calls or get_call_transcript by emphasizing AI scoring and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage guidance: it instructs the agent to warn the user about processing time, mandates scanning all pages, and names get_call_transcript as a follow-up tool for reading full dialogues. It could be clearer about when to use list_calls instead, but the guidance is otherwise explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses processing time ('this analysis takes some time because it processes each email with AI'), pagination behavior ('Returns one page', 'you MUST scan ALL pages'), the unreliability of partial analysis ('partial analysis gives unreliable results'), and mandates parallel calls for remaining pages. It even instructs the agent to warn the user, which is a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bolded warnings and paragraphs, but it is lengthy and contains some redundancy: the 'IMPORTANT' user-warning note appears both at the beginning and within the 'CRITICAL' section, and the pagination message is repeated twice. Still, most text earns its place given the genuine complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description goes beyond it by explaining the return type ('compact ranked list with scores, flags, and summaries'), full pagination rules, parameter semantics, and the intended workflow with get_email. No significant gaps remain given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section explains every parameter with formats, defaults, and examples (e.g., date_from: 'Start date (YYYY-MM-DD). Required.', take: 'Number of emails to score in this page (default: 100, max: 200)'). It also elaborates on skip/take with a pagination example, compensating fully for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'AI-score emails in a date range. Returns one page of scored results.' which clearly states the verb (AI-score), resource (emails), and scope (date range). It also distinguishes itself from siblings by mentioning 'After reviewing scored results, use get_email to read the full email content,' positioning scan_emails as a pre-filtering tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: it is for AI-scoring emails in a date range, with a 'question' parameter to specify what to flag, and recommends using get_email afterwards. However, it does not explicitly state when not to use it or compare to alternatives like list_emails or scan_calls, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: HTML content is converted to clean Markdown, including headers, links, lists, and code blocks. It also clarifies that the 'name' parameter is actually the article ID, which is a useful nuance. However, it does not mention error handling or any rate limits, but for a simple read operation, the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. Each sentence adds valuable information: purpose, output format, usage guidance, and parameter clarification. There is no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter) and the description covers purpose, parameter source, output format (Markdown conversion), and the relationship to list_articles. An output schema exists to define the return structure, so the description need not detail every field. The information provided is complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required string parameter 'name' with no description (0% coverage). The description's Args section adds critical meaning: 'name: The article ID (the 'name' field from list_articles)', explaining the source and format of the value. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'single knowledge base article by its ID', clearly distinguishing it from siblings like list_articles. It also explicitly states 'Use this to read the full content of an article found via list_articles', reinforcing its singular role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct guidance: 'Use this to read the full content of an article found via list_articles', naming the discovery tool and clearly stating when to use this tool. This effectively differentiates it from list_articles and other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description takes on the full burden of behavioral disclosure. It reveals that the user parameter is resolved automatically, warns that only call-specific fields work for sorting (explicitly banning 'created' or 'edited'), and clarifies that contact is an internal ID. These are useful behavioral insights beyond the input schema, though it doesn't cover every possible concern (e.g., permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial summary, a usage tip, and a bulleted argument list. Each parameter explanation is concise yet informative, avoiding unnecessary fluff. The content earns its place given the tool's complexity (11 parameters), and the front-loaded purpose makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 11 parameters, no annotations, but an output schema exists, so return values are covered. The description provides the purpose, when to use it, parameter semantics, and warnings about common pitfalls. It also covers pagination defaults and limits. This is complete for a list-type tool, leaving no significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With an input schema description coverage of 0%, the description fully compensates by explaining each of the 11 parameters in detail, including examples, allowed values, date formats, and default values. For instance, it notes that 'user' can be a display name or login name, 'contact' is an internal ID not a person's name, and 'sort' has a warning about invalid fields. This is essential information that the schema alone lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists phone calls with detailed call data (duration, CLID, missed calls, hold time), using a specific verb and resource. It also distinguishes itself from the sibling tool list_activities by noting it provides call-specific fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The first paragraph explicitly says to use this tool instead of list_activities(type='CALL') when call-specific fields are needed, providing a clear alternative. Additionally, it gives guidance for parameters like queue (use list_queues to find names) and contact (use list_contacts first), which effectively tells the agent when and how to use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral details: pagination ('Returns one page of results', 'skip', 'take' max 200), case-sensitivity and exact values for stage, automatic resolution of display names ('You do NOT need to call list_users first'), the need to call list_contacts for contact internal IDs, and the 'statuses MN relation' behavior. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a concise summary, then uses a structured, scannable list for parameters. Each parameter is explained in one or two lines with clear formatting. Despite the length (14 parameters), every sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 parameters and no annotations, the description covers all necessary context: filtering semantics, pagination defaults, sort options, and cross-tool dependencies. Having an output schema means return values need no explanation. The description is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. All 14 parameters are described with formats, defaults, examples, and cross-tool references. For instance, 'contact' clearly states it is an internal ID and explains how to find it via list_contacts. 'sort' lists valid values. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List tickets with optional filters. Returns one page of results.' The verb 'List' with resource 'tickets' makes it distinct from siblings like get_ticket (single ticket) and count_tickets (count). The scope is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides effective context on when to use the tool, including a direct example: 'When user says "open tickets", use stage='OPEN'.' It also cross-references related tools for parameter validation (list_ticket_categories, list_statuses, list_contacts) and clarifies when not to call list_users. However, it does not explicitly state when NOT to use this tool over alternatives like get_ticket or list_account_tickets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses partial-match search behavior, pagination defaults, and field semantics (login vs display name). It doesn't mention auth or rate limits, but for a read-only listing tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, followed by a crucial NOTE and a concise Args breakdown. Every sentence adds value without fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with optional parameters and an output schema, the description covers purpose, usage guidance, parameter semantics, and field details. No essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the Args section fully documents all three parameters: search (partial match, example), skip (pagination offset), and take (record count). This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List or search agents/users' with a specific verb and resource. It distinguishes from siblings by clarifying that this is the user directory tool and that other tools resolve names automatically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Most tools... resolve agent names automatically — you do NOT need to call list_users first.' It further states 'Use this tool only when you need to browse the user directory or look up a specific agent's details,' giving clear when-to-use directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses important behavioral traits including the sort field warning ('do NOT use created or edited'), automatic resolution of user names, and the contact ID not being a person's name. It also specifies pagination defaults and the maximum take value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise one-liner and usage guideline, followed by a well-organized parameter list. Each parameter explanation earns its place with practical details and no unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description covers all parameters, provides usage context versus alternatives, and includes warnings about sort fields and ID formats, making it comprehensively self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by explaining every parameter with examples, formats, constraints, and warnings. For instance, it clarifies that 'contact' is an internal ID and 'user' can be either display or login name, adding meaning far beyond the basic string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List email activities with email-specific fields' with a specific verb and resource. It explicitly distinguishes from list_activities by recommending this tool when email details are needed, making it distinct among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative: 'Use this instead of list_activities(type='EMAIL') when you need email details.' It also gives practical parameter guidance, such as using list_queues to find queue names and list_contacts to find contact IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-daktela MCP server](https://glama.ai/mcp/servers/hajekd/mcp-daktela/badges/card.svg)](https://glama.ai/mcp/servers/hajekd/mcp-daktela)

Score Badge

Copy to your README.md:

[![mcp-daktela MCP server](https://glama.ai/mcp/servers/hajekd/mcp-daktela/badges/score.svg)](https://glama.ai/mcp/servers/hajekd/mcp-daktela)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hajekd/mcp-daktela'

If you have feedback or need assistance with the MCP directory API, please join our Discord server