Vendo AI

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

With no annotations, the description carries the full burden. It discloses two meaningful behavioral traits: processing stops and the campaign is hidden from default views. However, it omits whether archiving is reversible, whether campaigns can be restored, and any permission requirements, which are relevant for a state-changing tool.

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

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

The description is a single sentence with no filler. The action is front-loaded and the two key consequences are stated compactly, with every word earning its place.

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

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

For a single-parameter tool, the immediate state change is covered, but with no annotations and no output schema, the description should also clarify reversibility and how archiving relates to pause_campaign and delete_campaign. Core details are present, but decision context is incomplete.

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

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

Schema description coverage is 0% and the description does not mention the id parameter or clarify that it identifies the campaign to archive. The parameter is simple and inferable from context, so the ambiguity is low, but the description adds no parameter-level meaning.

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

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

The description names a specific verb ('Archive') and resource ('a campaign') and states concrete resulting behavior: stops processing and is hidden from default views. This clearly differentiates it from pause_campaign and delete_campaign.

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

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

The description implies when archive is appropriate by describing its effect, but it does not explicitly compare with pause_campaign or delete_campaign, nor does it mention reversibility or prerequisites. Usage context is present but not directly stated.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It clearly warns about credit spending ('SPENDS CREDITS (2 per contact)') and describes the core side effect of purchasing and snapshotting contacts. It could mention reversibility or failure behavior, but the cost warning and prerequisite cover the most critical behavioral traits.

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

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

Two concise sentences with no filler. The most important information (credit cost) is front-loaded, followed by action and a clear prerequisite. Every phrase earns its place.

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

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

For a single-parameter purchase action with no output schema, the description covers the essential context: cost, effect, and approval condition. It does not describe the return value or behavior when the set is already purchased, but the low complexity and clear precondition make this a minor omission.

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

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

Schema describes only an 'id' string with no description. The description hints that the id identifies 'the set' being purchased, which adds some meaning, but it never explicitly states 'id is the audience set identifier.' Since schema coverage is 0%, the description must compensate more fully for parameter semantics.

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

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

The description uses a specific verb ('Purchases') and resource ('the set'), and clarifies the side effect: 'snapshots its contacts into the workspace.' It also implicitly distinguishes itself from preview_buy_audience_set by framing itself as the actual purchase action. This is unambiguous and easy to differentiate from siblings.

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

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

Provides explicit when-to-use guidance: only call after the user reviewed preview_buy_audience_set output and explicitly approved the cost. This is a strong precondition that prevents premature or unauthorized spending. It does not explicitly discuss alternatives like launch_audience_set, but the prerequisite is clear and valuable.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It usefully reveals a non-obvious trait: the tool only returns a URL and cannot complete OAuth autonomously. This is a critical behavioral boundary that prevents the agent from assuming the connection is fully established. It does not cover side effects or state changes, but for a simple OAuth-start tool this is substantial transparency.

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

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

The description is two sentences with no filler: the first states the core behavior, and the second delivers the essential user-action requirement. The critical instruction is front-loaded and every sentence adds value.

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

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

The tool is simple and the description covers the main flow and the key limitation, but it leaves the 'id' parameter entirely unexplained. There is also no output schema or return-value structure, so the description alone must define how the URL is returned; it only says a URL is returned without clarifying the response shape. This is adequate for basic use but incomplete for fully correct invocation.

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

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

The schema has one required parameter, 'id', with no description, and schema description coverage is 0%. The tool description never mentions 'id' or explains what value should be supplied (e.g., user id, meeting id, workspace id). An agent cannot correctly determine what to pass for this parameter from any available text.

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

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

The description states a specific verb and resource: 'Returns a Google OAuth URL.' The title adds 'Google Meet OAuth flow,' which clearly identifies the tool's purpose and differentiates it from the other connect_* siblings such as connect_linkedin_account and connect_telegram_bot. No ambiguity remains about what this tool does.

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

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

The description clearly instructs that the returned URL must be opened in a browser and that the MCP cannot complete OAuth on its own, giving the agent immediate next-step guidance. It does not explicitly name alternative tools or exclusion conditions, but the 'Start OAuth flow' title and unique Google Meet scope imply the appropriate context for use.

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

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

With no annotations, the description carries the full burden and does it well: it discloses that human interaction is required, that this tool cannot finish the OAuth flow alone, and that no account exists until the user completes the flow. This is essential behavioral context beyond the simple 'returns a URL' summary.

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

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

The description is two tight sentences that front-load the core behavior, then add the critical human-in-the-loop caveat. Every sentence earns its place and there is no redundant phrasing.

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

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

For a simple tool with one optional parameter and no output schema, the description covers what the tool returns, what the agent should do with it, and the key state limitation (no account until flow completion). Nothing essential is missing for correct invocation.

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

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

The schema already documents campaign_id with 100% coverage, so the description does not need to repeat it. However, the description adds no additional meaning about how the optional campaign binding behaves or what happens when it is omitted. Baseline 3 is appropriate because the schema handles parameter documentation.

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

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

The description states a specific action (returns a hosted authorization URL) and a specific resource (LinkedIn account), clearly distinguishing it from reconnect_linkedin_account and disconnect_linkedin_account. It is explicit that this tool only produces a link and does not complete the connection.

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

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

The description gives clear operational guidance: the URL must be opened by a human and the agent must give it to the user, since the tool cannot complete the connection itself. It does not explicitly name alternatives such as reconnect_linkedin_account, but the context makes the usage scenario sufficiently clear.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does disclose an important behavioral consequence: after connection, all messages to the bot are answered by the agent. However, it does not mention side effects, whether an existing connection is replaced, validation behavior, or failure modes.

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

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

The description is compact and front-loaded with the setup steps and the resulting behavior. Both sentences earn their place with no filler, though slightly more structure around prerequisites and effects would improve it.

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

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

For a simple two-parameter connect action, the description covers the main setup flow and the end-state behavior. But with no output schema and no annotations, it would be more complete if it explained what the id parameter represents, what the user should expect as a response, and any constraints such as one bot per agent.

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

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

Schema description coverage is only 50%: bot_token is documented, but id has no description. The description adds context for bot_token by referencing @BotFather, but it never explains what id refers to, even though it is a required parameter. The description does not compensate for the undocumented id.

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

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

The description states a specific action and outcome: the user passes a BotFather token and afterwards all messages to the bot are answered by the agent. This clearly identifies the tool as the establishment of a Telegram connection, distinguishing it from disconnect_telegram_bot and get_telegram_bot_info, though it does not explicitly name those alternatives.

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

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

The description implies when to use it: when the user has a bot token from @BotFather and wants the agent to handle incoming messages. However, it gives no explicit guidance about when not to use it, what to do if a bot is already connected, or how it compares to related tools like get_telegram_bot_info.

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

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

With no annotations provided, the description carries the full burden. It discloses a real side effect (costs 1 credit), the DRAFT status, and importantly that the agent does not begin contacting anyone upon creation. This is strong behavioral context; only minor gaps remain, such as return value or failure behavior.

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

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

The description is dense but not bloated, and it front-loads the core purpose and credit cost before explaining workflow steps. Every sentence adds relevant context, though the company-info sentence is slightly convoluted and could be tightened.

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

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

The description richly covers cost, draft behavior, required fields, and next steps, but it undermines itself by saying company info can be passed here when the schema does not allow it. This contradiction could cause an agent to construct an invalid call. The absence of any return-value guidance is also a minor gap since no output schema exists.

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

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

Schema description coverage is 100%, and both name and description already have clear parameter descriptions, so the baseline is 3. The description adds useful workflow context about required fields and company info, but it also says company info can be 'passed here' even though the schema has no such parameters and additionalProperties is false, which is misleading.

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

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

The description opens with 'Create a new AI sales agent,' naming a specific verb and resource. It is clearly distinct from siblings like create_campaign and set_agent_company, and the 'new' qualifier separates it from update_agent.

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

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

The description gives explicit usage context: required fields, DRAFT status, the fact that the agent won't contact anyone until attached to a campaign and launched, and the alternative of calling set_agent_company later for company info. This tells the agent exactly when and how to use the tool.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that the campaign is created in DRAFT status and that no one is contacted until launch_campaign is invoked. This is useful side-effect transparency, though it does not mention other behavioral aspects like permissions or persistence.

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

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

The description is compact: two sentences that front-load the core purpose and then add the critical non-obvious behavior (not launched, no contacts until launch_campaign). Every sentence adds value.

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

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

For a tool with 5 parameters, a nested settings object, no annotations, and no output schema, the description is incomplete. It leaves the name and settings parameters undocumented, provides no return-value information, and gives no guidance on errors or follow-up actions beyond mentioning launch_campaign.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains the audience id and agent id by name. It does not explain the required 'name' parameter or the 'settings' object, and the statement 'Needs an audience id and an agent id' contrasts with the schema where agentId is optional.

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

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

The description states the specific verb and resource: 'Create a new campaign in DRAFT status.' It also distinguishes this tool from launch_campaign by explicitly saying the campaign is not launched and nobody is contacted until launch_campaign is called.

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

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

The description provides clear context for when to use the tool: creating a campaign as a draft before launching. It references launch_campaign as the next step and names the required prerequisites (audience id and agent id), though it does not explicitly list exclusion conditions or alternatives such as update_campaign.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses that the note is internal, not visible to the lead, and supports @mentions via user ids, which are genuinely useful behavioral traits beyond the fact that it adds a comment. It does not disclose return values or whether mentions notify users, but those are minor gaps for a simple creation tool.

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

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

Two sentences with no filler; the core behavior is stated first, and the additional mention feature is added in the second sentence. Every word earns its place.

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

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

For a two-parameter mutation tool with no output schema and no annotations, the description is mostly functional, but it does not explicitly define the id parameter as the lead id or describe the expected response behavior. The internal visibility and mention support help, but the parameter ambiguity and lack of outcome information keep it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters. It implies id refers to the lead and body contains the comment text, and mentions of user ids in body are supported, but it never explicitly defines what id and body mean or their expected formats. This is a significant gap even though the parameter names are suggestive.

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

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

The description uses a specific verb-resource pair: add an internal comment on a lead. It also distinguishes this from sibling communication tools by explicitly stating the comment is not visible to the lead, so an agent can tell it apart from crm_reply_to_lead or similar external-facing tools.

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

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

The description communicates the use case clearly: an internal team note on a lead card, not visible to the lead. It does not explicitly name alternative tools or state when not to use it, but the visibility distinction provides enough context for an agent to route correctly.

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

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

With no annotations provided, the description carries the full disclosure burden and explicitly states 'Read-only, free,' telling the agent this is a safe, non-mutating call. It also reveals important behavioral scope: results include everyone contacted, not just those who replied. Pagination and rate limits are not mentioned, but these are minor for a parameterless list operation.

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

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

Three short sentences deliver the core definition, the key scope distinction from CRM leads, and the safety/cost profile with no filler. The most important information is front-loaded.

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

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

For a parameterless read-only list tool with no output schema or annotations, the description is complete enough to invoke correctly: it states what is returned, how results are organized, how it differs from an alternative, and that it is free and safe. Minor return-format details could be added but are not necessary for correct invocation.

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

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

The input schema has zero properties, so there are no parameter semantics to clarify. The description still adds value by explaining what the returned cards represent and how they are grouped, which meets the zero-parameter baseline.

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

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

The description uses a specific verb ('List') and resource ('communication cards'), then defines the exact granularity: one card per campaign and per SDR search with outbound counters. It also distinguishes itself from CRM leads by clarifying this is the full outbound stream, not just people who replied.

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

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

It gives a clear selection context: use this when you need the full outbound stream including non-responders, and it explicitly contrasts CRM leads as containing only people who answered. It does not name a sibling tool directly, but 'CRM leads' clearly maps to crm_list_leads, which is sufficient guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the operation is read-only and free, which is valuable safety/cost context. It also implies a list-style return by saying 'every outbound touch', though it does not detail pagination behavior or response shape.

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

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

The description is two compact sentences. The first sentence states the tool's function and filtering capabilities, and the second adds the prerequisite and safety/cost context. There is no wasted wording.

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

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

Given the tool's moderate complexity, the description covers the essential invocation path: scope, filters, and the required preliminary call to crm_communication_cards. It does not describe the return format or pagination defaults, and there is no output schema to fill that gap, but the description is strong enough for correct selection and basic invocation.

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

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

Schema description coverage is only 38%, so the description must compensate. It clarifies the meaning of the core filters: channel, reply status (replied), and date range (to/from), and establishes that the id refers to a campaign or SDR search. However, it does not explain limit/offset semantics, and some parameter meaning is still left to inference.

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

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

The description clearly identifies the resource: every outbound touch for one campaign or SDR search, and lists the filtering dimensions (channel, reply status, date). It distinguishes itself from related tools like crm_communication_cards and crm_communication_thread by specifying this is the outbound-history view for a single campaign/SDR-search id.

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

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

The description gives an explicit prerequisite: use crm_communication_cards first to get the id. This tells the agent the required setup before calling. It does not explicitly name alternatives or when not to use this tool, but the context is clear enough for the main use case.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose that the operation is read-only and free, which is useful. However, it does not mention output format, pagination, error behavior, or how the id/type parameters affect the result.

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

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

The description is two tight sentences with no filler. The primary purpose is front-loaded, followed by the key source and the read-only/free note. Every sentence earns its place.

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

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

For a tool with no annotations, no output schema, and three required parameters, the description leaves important gaps. It does not define what `id` and `type` mean, how they relate to the card, or when to prefer this tool over closely related CRM communication tools. The read-only/free note is helpful but not sufficient.

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

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

Schema description coverage is only 33%, and the description adds meaningful context for `key` by explaining that it comes from a crm_communication_history row and can be an email address or LinkedIn chat id. However, `id` and `type` remain effectively unexplained, leaving two required parameters ambiguous.

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

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

The description identifies the resource and scope clearly: the complete message thread with one contact inside a card. It is distinguishable from history/card-list tools because it emphasizes a full thread for one contact, though it lacks an explicit verb like 'retrieves' or 'returns' and does not name sibling tools.

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

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

The description implies usage: to get a full message thread for one contact, using a key taken from a crm_communication_history row. It does not explicitly explain when to choose this over closely related siblings like crm_get_conversation or crm_communication_history, so guidance is partial.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure and delivers: it flags that this is a write operation, that it incurs no credit cost, and most importantly, that it will not send invites and only writes to the internal calendar. These are non-obvious side-effect characteristics that an agent must know before invoking.

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

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

Three short sentences are front-loaded with the core purpose and follow with the cost and side-effect caveat; every sentence carries distinct information without redundancy. This is an efficiently sized description.

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

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

Given the moderate complexity of five parameters and the absence of both annotations and an output schema, the description covers purpose, cost, and key side-effect limitations, which is strong. It is slightly incomplete in not stating what the tool returns after creation and not specifying any required credentials or permissions, though the schema covers required parameters.

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

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

Schema coverage is only 40% (only starts_at and ends_at have 'ISO datetime' descriptions), yet the description adds no parameter-level meaning—title, notes, and all_day remain unexplained. The tool description doesn't mention any of the five parameters, so it fails to compensate for the schema's gaps.

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

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

The description opens with the specific verb-resource pairing 'Add a custom event to the CRM planner,' which clearly names the action, the object, and the destination. It also sets the tool apart from sibling update/delete/list calendar tools by framing this as a creation action, and the no-invite caveat differentiates it from meeting/connect tools.

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

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

The description gives clear context for when this tool is appropriate: creating an internal CRM calendar event, and it explicitly excludes the use case of sending invitations ('Does NOT send invites to anyone'). No alternative sibling is named, so the guidance is strong but not fully explicit.

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

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

No annotations are provided, so the description carries the full disclosure burden. It explicitly discloses the visible side effect of creating a card on the customer board and notes that all fields are optional but at least one must be non-empty. It could add return-value or duplicate-handling details, but the key mutating behavior is clearly stated.

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

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

Two tightly worded sentences: the first states the action and target stage, the second gives the input rule and the side effect. No filler or repetition; essential information is front-loaded.

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

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

For a simple creation tool with seven optional string parameters, no annotations, and no output schema, the description covers the main needs: what will be created, where it appears, and the minimum input requirement. Minor gaps such as the exact return payload or duplicate policy are acceptable for this tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds a global constraint (all fields optional, at least one non-empty), which is valuable, but it does not clarify ambiguous fields such as 'title' or acceptable formats. Parameter names like email, phone, first_name, and company_name are mostly self-explanatory.

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

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

States the specific action 'Add a lead card to the New stage' and the resource, clearly distinguishing it from sibling tools like crm_update_lead, crm_move_lead, or delete_crm_lead. The title reinforces the manual-creation intent.

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

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

Clear context: this is the tool for initially creating a lead card in the New stage, with a practical rule that at least one non-empty field is required. It does not explicitly name alternatives or when-not-to-use conditions, but the use case is evident relative to update/move/delete siblings.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses that the new stage is inserted before the terminal Won/Lost stages, which goes beyond the schema. However, it omits mutation side effects, permission requirements, idempotency, and what the tool returns.

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

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

Two short sentences with no filler. The first sentence front-loads the action and object, and the second adds placement context. Every word contributes.

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

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

For a low-complexity tool with only two scalar parameters and no output schema, the description supplies the essential context: what is created, what parameters mean, and where it will appear. It lacks return-value and caveat details, but the overall invocation intet is clear.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'name' as the kanban column label and clarifies that 'color' is an optional hex color, which adds format meaning beyond the plain string type. It does not state constraints like valid hex format details, but for two simple parameters this is adequate.

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

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

States a specific verb ('Add') and resource ('custom kanban column') with concrete details: name, optional hex color, and placement before Won/Lost. This clearly distinguishes it from siblings like crm_update_stage and delete_crm_stage.

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

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

The verb 'Add' and the description imply this is the tool for creating a new pipeline stage, and the placement note gives useful context. However, it does not explicitly compare against crm_update_stage, delete_crm_stage, or crm_list_stages, nor state when not to use it.

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

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

With no annotations, the description carries the full burden, and it discloses key behavioral traits: the operation destroys no history, needs no preview step, and cannot be undone. This is meaningful beyond the schema, though it omits details like success/error behavior or permission requirements.

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

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

Two tight sentences with no filler. The core action is front-loaded, and the second sentence adds high-value contrasts (no history, no preview, irreversible) without redundancy.

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

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

For a single-parameter delete operation, the description covers the essential behavioral context and the important warning about irreversibility. It does not specify return values or error states, but the lack of an output schema and the simplicity of the tool make the definition reasonably complete.

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

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

The schema has 0% description coverage and the description does not explain the 'id' parameter. The resource name implies id refers to the calendar event, but no explicit meaning, format, or example is provided, so the description fails to compensate for the missing schema documentation.

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

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

The description uses a specific verb ('Remove') and resource ('custom calendar event'), and immediately contrasts itself with deleting a lead or stage. This clearly differentiates crm_delete_calendar_event from the many delete/preview-delete siblings in the tool list.

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

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

The description conveys when this direct delete path is appropriate: unlike deleting a lead/stage, no preview step is needed. It does not explicitly name or contrast all alternatives (e.g., crm_update_calendar_event) but gives enough context for an agent to select this over preview-based deletion tools.

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

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

With zero annotations, the description carries the full disclosure burden and does so thoroughly: it reveals the cost side effect (one profile view from the shared daily budget), the data-quality caveat that emails are UNVERIFIED pattern guesses with email_confidence=pattern_guess, and the scope of returned data. This is rich behavioral context for an agent deciding whether to invoke the tool.

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

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

Three sentences front-load the core behavior, then layer the email caveat and cost warning, with each clause carrying operational weight. The parenthetical 'same lookup the SDR hunters use' is mild color rather than hard information, keeping this just short of zero-waste.

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

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

For a single-parameter tool with no annotations or output schema, the description covers inputs (URL format), outputs (five fields plus optional unverified email), and operational impact (budget cost). It omits the prerequisite that a LinkedIn account must be connected (a gap given siblings connect_linkedin_account/list_linkedin_accounts) and any failure behavior when the budget is exhausted or the profile is not found.

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

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

Schema description coverage is 0% and the lone linkedin_url parameter has no schema documentation, so the description must compensate — and it does by specifying the expected format (a linkedin.com/in/... URL). It stops short of stating validation/error behavior for malformed URLs, but the format constraint is the essential semantic for correct invocation.

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

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

The description states a specific verb ('Fetch') with a concrete resource (a linkedin.com/in/... URL) and enumerates the exact fields returned (name/title/current employer/avatar/location), making the tool's function unmistakable. It doesn't explicitly name a sibling to differentiate from, though the LinkedIn-URL input makes it inherently distinct from CRM and SDR siblings like sdr_get_person_detail or crm_get_lead.

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

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

Provides clear operational context and an explicit exclusion: it costs one profile view from the shared daily LinkedIn budget and 'do not loop over big lists.' However, it never names an alternative tool for cases the agent might confuse (e.g., sdr_get_person_detail or crm_get_lead), so routing guidance is left to inference.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key trait 'Read-only,' which signals a safe, non-mutating operation, and it clarifies the scope of returned data by listing the channel types. It omits edge-case behavior (e.g., missing lead, empty thread) and return format, but the central safety-relevant trait is covered.

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

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

Two short sentences totaling about twenty words, with the core function front-loaded in the first sentence and the behavioral note in the second. Every word earns its place and there is zero filler.

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

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

For a simple one-parameter getter with no output schema and no annotations, the description adequately covers what is returned, the scope, and the read-only nature. The remaining gaps are the implicit id semantics and the lack of any distinguishing guidance against the similarly named sibling crm_communication_thread, which an agent would benefit from.

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

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

The single parameter `id` has no schema description (0% coverage), so the description must compensate. The phrase 'with this lead' implies that id refers to a lead, which is a useful hint, but it never explicitly states 'id is the CRM lead ID' and leaves ambiguity between a lead identifier and a conversation identifier.

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

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

The description states a specific resource ('the full message thread with this lead on their source channel') and enumerates the channel types (LinkedIn / email / widget / telegram / phone transcript), which clearly identifies what the tool returns. The title supplies the verb 'Get.' However, it does not differentiate from sibling crm_communication_thread, which by name could plausibly return the same thing, so it falls short of full sibling distinction.

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

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

The phrase 'full message thread with this lead' implies the use case: retrieve the complete source-channel conversation for a single lead when you need full context. But there is no explicit when-to-use versus when-not-to-use guidance, and no alternatives are named despite the closely related siblings crm_communication_thread and crm_communication_history.

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

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

No annotations are provided, so the description carries the full burden and it does state 'Read-only' plus the data categories returned. This covers the most important behavioral trait for a get tool, though it does not discuss not-found behavior or response formatting.

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

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

The description is two compact sentences, front-loaded with 'Full lead card' and a concise field list. The parenthetical clarifying source as 'why is this person here' adds meaningful context without unnecessary length.

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

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

For a single-parameter read-only tool with no output schema, the description gives a useful summary of the returned lead-card sections and explicitly indicates safety. It could be more complete with error or missing-record behavior, but it is adequate for this level of complexity.

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

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

Schema description coverage is 0% and the description never explains the `id` parameter, its format, or its relationship to the CRM lead. The schema's required `id` is self-explanatory by name, but the description adds no parameter meaning to compensate for the missing schema-level descriptions.

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

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

The description states a specific verb and resource: retrieving one CRM lead with full detail, and lists the exact sections returned (identity, source, company enrichment, activities, comments, assignments). The 'Read-only' qualifier and 'full detail' wording help distinguish it from list, update, and delete siblings.

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

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

The phrase 'Full lead card' implies this is the single-lead detail getter, contrasting with list-style tools like crm_list_leads, and 'Read-only' signals it is not a mutation tool. However, there is no explicit statement of when to use it instead of alternatives or when not to use it, so the guidance remains implicit.

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

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

With no annotations provided, the description carries the behavioral burden and explicitly discloses the operation is read-only and free. This covers side effects and cost, though it does not mention authentication or rate limits—minor gaps for a zero-parameter getter.

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

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

Two concise sentences front-load the core purpose and then add the most decision-relevant details: the notify_* toggles and the free/read-only nature. There is no filler or repetition.

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

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

For a simple, zero-parameter read operation, the description provides enough context: what resource is read, what notable settings are included, and the side-effect/cost profile. It does not describe the exact return shape, but no output schema exists and the tool name makes the return obvious.

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

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

The tool has zero parameters, so the empty schema already fully documents the input surface. The description adds no parameter-specific detail, but none is required.

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

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

The description clearly states the tool reads CRM settings and even specifies the notify_* toggles as part of what is exposed. The verb 'Read' cleanly distinguishes it from the sibling crm_update_settings and other CRM getters.

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

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

The read/write distinction is clear from the description, making it obvious when to call this versus crm_update_settings. 'Read-only, free' also signals that this is the safe, no-cost option, though it does not explicitly name alternatives.

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

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

With no annotations, the description carries the burden of behavioral disclosure and does so by stating 'Read-only, free.' It also clarifies data scope: only custom CRM events, not derived SDR schedule entries. It does not describe return format or pagination, but for a simple read-only list this is solid.

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

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

Two sentences with no filler. The main action is front-loaded, and the disambiguation note about SDR windows earns its place.

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

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

For a low-complexity tool with two flat parameters and no output schema, the description covers event type, date range, read-only/free status, and the key sibling distinction. It could clarify default behavior when optional `from`/`to` are omitted, but overall it 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.

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

Schema description coverage is 100%, and both `from` and `to` already have clear ISO date descriptions. The description's 'date range' phrasing adds no new parameter-level meaning, so the baseline of 3 applies.

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

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

The description names a specific verb and resource: 'List custom calendar events (meetings, reminders) in the CRM planner for a date range.' It also distinguishes this from SDR-derived UI calendar entries, so an agent can tell it apart from related calendar tools.

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

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

It explicitly warns that SDR sending windows appear in the same UI calendar but are not the domain of this tool, directing the agent to `sdr_get_search` for those. This is a clear when-to-use and alternative mapping.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and details filter semantics, including source examples and allowable range values, which is meaningful context for a list tool. It stops short of describing ordering, pagination behavior, or response shape.

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

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

The description is compact and well-structured: the action is front-loaded, followed by a tight filter list and a practical use-case note. Every sentence carries useful information with no filler.

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

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

It covers all parameters, the read-only nature, and a concrete use case, which is strong for a first-call list tool. However, with no output schema, it omits what the response contains, default ordering, and default range, leaving minor uncertainty for an agent.

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

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

Schema description coverage is 0%, but the description fully compensates by explaining every parameter: stage as a stage id, source with concrete examples, q as name/company/email search, range with allowed values, and limit/offset for pagination. This adds substantial meaning beyond the bare schema.

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

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

The description clearly states a specific verb and resource: 'List leads in the CRM pipeline.' It is easily distinguished from sibling tools such as crm_get_lead (single lead), crm_list_stages, and other CRM operations, and the filter list reinforces its scope.

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

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

It provides a concrete use case: 'Great first call for "who replied to me?"' and emphasizes that it is read-only. However, it does not explicitly name alternatives or state when-not-to-use it, leaving some routing decisions to inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states the operation is read-only and free, and it clarifies the scope as workspace-level accounts. It does not describe auth requirements, return format, or pagination, but for a zero-parameter list operation the key behavioral traits are covered.

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

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

Three short sentences, each adding value: the action, a practical use case, and the safety/cost note. The description is front-loaded with the verb and resource and contains no filler.

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

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

For a simple zero-parameter, read-only tool with no output schema, the description adequately covers scope, use case, and behavioral traits. It does not detail the exact fields returned by the account list, but that is a minor gap given the operation's simplicity.

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

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

The tool has zero parameters, so the baseline is 4. There is no parameter documentation needed, and the description does not need to compensate for missing schema details.

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

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

The description states a specific verb and resource: list LinkedIn accounts connected to the workspace as shown in the CRM. This clearly identifies the tool's purpose. It does not explicitly differentiate from the sibling 'list_linkedin_accounts', relying on the 'crm_' prefix and 'as shown in the CRM' phrasing to imply the distinction.

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

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

The description offers a concrete use case—'useful to see which account owns a conversation'—which implies when an agent should call it. However, it provides no explicit guidance on when not to use it or how it compares to similar tools like list_linkedin_accounts, leaving the routing decision to inference.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does state 'Read-only, free,' which is useful and directly addresses side effects and cost. But it does not mention return shape, ordering, pagination, or any other runtime behavior beyond the fact that it lists notifications.

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

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

The description is exceptionally concise: one core action, useful examples in parentheses, and a two-word behavioral note. No filler, no redundant schema repetition, and the most important information is front-loaded.

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

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

For a simple list operation with two optional parameters and no output schema, the description covers the core purpose and safety profile. However, it lacks parameter explanations and sibling differentiation, so an agent still has to make assumptions about unread_only behavior and how this tool fits among notification-related siblings.

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

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

Schema description coverage is 0%, and the description does not explain 'limit' or 'unread_only'. The agent must infer their meaning entirely from names and types, so the description adds no value beyond the bare input schema.

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

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

The description states a specific verb and resource: 'List CRM notifications', and enriches it with concrete notification types ('new lead, new reply, stage change'). This distinguishes it from siblings like crm_list_leads or crm_mark_notification_read without needing to open the schema.

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

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

The phrase 'Read-only, free' gives some selection context, implying this is a safe, non-mutating retrieval. However, it does not explicitly contrast this tool with crm_mark_notification_read or crm_mark_all_notifications_read, and it does not state when to use this over other CRM list tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It states that the call is 'Read-only', that results are ordered, and enumerates the returned fields. It does not mention edge cases or pagination, but for a simple workspace-level list 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.

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

Two short sentences carry purpose, scope, output fields, ordering, read-only status, and usage guidance with no filler. The key info is front-loaded and every word earns its place.

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

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

For a zero-parameter read-only list with no output schema, the description supplies everything needed to invoke it correctly: what it returns, in what order, for which scope, and why an agent should call it before moving leads. No critical context is missing.

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

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

The tool has zero parameters and the schema confirms this with an empty properties object. Per the baseline for parameterless tools, this is a 4; the description adds no parameter semantics because none exist, and its field list refers to return values rather than inputs.

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

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

The description uses a specific verb and resource ('List pipeline stages') and clarifies it returns 'ordered kanban columns for this workspace' with the exact fields (id, name, color, is_terminal). This clearly distinguishes it from sibling tools that create, update, or delete stages.

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

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

The description gives an explicit usage directive: 'Call before moving leads.' This ties the tool directly to crm_move_lead and makes when-to-use unambiguous. It also marks the call as read-only, reinforcing the safe, preparatory role.

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

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

With no annotations provided, the description carries the safety burden and explicitly states 'Read-only, free.' This tells the agent the operation has no side effects and no credit cost. It could add more about response shape, but for a simple list operation this is solid behavioral disclosure.

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

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

Two short sentences with no wasted words. The core purpose is front-loaded, and the behavioral note 'Read-only, free' is compact and valuable.

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

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

For a zero-parameter, read-only list tool, the description provides all essential context: what is listed, the workspace scope, the CRM attribution semantic, and the side-effect/cost profile. No output schema exists, but the return value is naturally inferable as a list of agents.

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

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

The tool has zero parameters, so the baseline for parameter semantics is 4. The description adds meaningful context about what the returned agents are used for, though no parameter-level detail is needed.

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

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

The description states a specific verb and resource: 'List the AI agents in this workspace that CRM leads can be attributed to.' This clearly distinguishes it from generic sibling tools like list_agents and list_agents_with_stats by scoping it to CRM-attributable agents.

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

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

The intended use context is clear: use this tool when you need the set of workspace agents eligible for CRM lead attribution. It does not explicitly name alternatives or exclusions, but the CRM-specific scope makes the appropriate selection obvious among sibling list tools.

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

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

The description states 'Read-only, free,' which adds some behavioral context beyond the input schema (which has no annotations). However, it doesn't disclose details like what the output format is, whether it returns full member profiles or just IDs, or any rate limits. The 'free' claim is useful but not fully transparent about the returned data.

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

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

Three short sentences, each earning its place: what it lists, when to use it, and its read-only no-cost nature. Extremely efficient and front-loaded.

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

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

For a zero-parameter read-only list tool, the description is nearly complete. The main missing piece is the output shape — the agent knows it gets valid owner IDs but not whether the response includes names, emails, or other fields. Still, given the tool's simplicity, this is a minor gap.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The description's scoping phrase ('people in this workspace who can own a CRM lead') adds meaning about what the returned list contains, which compensates for the lack of any schema detail. Baseline 4 for zero-param tools is appropriate here.

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

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

The description clearly states a specific action (List) and resource (people in this workspace who can own a CRM lead), which immediately distinguishes it from the many sibling list tools like crm_list_leads or list_agents. The title is also clear and consistent with the description.

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

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

Explicitly tells the agent when to use it: 'Use before reassign_crm_lead to get valid owner ids.' This is direct usage guidance that links to a sibling tool and provides a concrete workflow context.

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

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

With no annotations provided, the description carries the transparency burden. It clearly discloses the primary behavioral effect: all notifications are marked read and the badge is cleared. It does not discuss irreversibility or response behavior, but for this simple state-change operation the stated effect is the core behavior.

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

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

One sentence with no filler. It front-loads the action ('Clear the CRM notification badge') and immediately provides the mechanism ('marking everything read'), making it efficient and scannable.

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

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

For a zero-parameter, no-output-schema operation, the description is complete: it states purpose, scope, and effect. Nothing essential is missing for an agent to decide to invoke it correctly.

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

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

The input schema has zero parameters and 100% schema description coverage, so there are no parameter details to clarify. The rubric baseline for zero-parameter tools applies, and the description introduces no misleading parameter information.

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

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

States a concrete verb and resource: 'marking everything read' to 'Clear the CRM notification badge.' The name and description emphasize 'all' vs. the sibling crm_mark_notification_read, so an agent can tell them apart without extra context.

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

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

The use case is implied by the title and description: use this when you want to clear the whole badge rather than mark a single notification read. However, there is no explicit mention of when-not-to-use or a direct pointer to crm_mark_notification_read as the alternative.

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

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

No annotations are provided, so the description carries the full burden. It explicitly discloses that this is a 'Write operation' and that there is 'no credit cost,' which are important behavioral traits. It does not detail idempotence, return values, or error behavior, but for this simple state-changing operation the disclosure is reasonably complete.

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

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

The description consists of two short sentences with no filler. The operation is stated first, and the relevant behavioral notes (write, no credit cost) follow concisely.

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

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

Given the low complexity (one required parameter, no output schema, no nested objects), the description provides enough information for an agent to invoke the tool correctly. It omits return-value details and prerequisites, but these are unlikely to be essential for a straightforward mark-as-read operation.

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

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

The schema description coverage is 0%, so the description must compensate. It does so by identifying the object as a 'CRM notification,' making it clear that the required 'id' parameter refers to a notification ID. This adds meaning beyond the bare schema definition of 'id' as a string.

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

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

The description clearly states a specific verb ('Mark') and a specific resource ('a single CRM notification'), with the end state 'as read'. The qualifier 'single' distinguishes it from the sibling crm_mark_all_notifications_read, so an agent can tell them apart.

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

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

The word 'single' implies this tool is for one notification at a time, contrasting with the sibling crm_mark_all_notifications_read, but it does not explicitly name alternatives or state when not to use this tool. The usage context is clear enough to infer, but the guidance is not explicit.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the operation is reversible and analogous to a drag-and-drop UI action, but it does not mention required permissions, behavior on invalid stage_id, or whether any data is returned.

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

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

The description is a single, front-loaded sentence with no filler. Every clause carries information: the action, the target, the ID source, and reversibility. The em-dash structure puts the core action first.

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

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

For a low-complexity two-parameter operation, the description covers purpose, stage_id sourcing, and reversibility. However, the absence of annotations and an output schema means the description should also convey success/return behavior and confirm what 'id' refers to; these are not explicitly addressed.

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

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

The input schema has two bare string parameters with 0% description coverage. The description adds meaning for stage_id by directing the agent to crm_list_stages for valid IDs, but it does not explicitly identify 'id' as the lead identifier or its source. Inference from the tool name and sentence covers this partially, so a mid score is appropriate.

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

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

The description specifies the exact action ('move'), the resource ('a lead'), the target ('a different pipeline stage'), and the mechanism ('by stage_id'). It also invokes a familiar 'drag-and-drop equivalent' semantic and names the relevant sibling crm_list_stages for id discovery, making it distinguishable from broader tools like crm_update_lead or reassignment operations.

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

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

It provides clear usage context: use this tool when a lead should be moved between pipeline stages, and it explicitly instructs the agent to get stage IDs from crm_list_stages. It stops short of naming exclusions or alternatives such as crm_update_lead or reassign_crm_lead, so it does not reach a 5.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses that this sends a real external message from the customer's own account and also moves the lead to a specific stage, plus the required human-approval step. These are material behavioral traits that go well 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.

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

The description is compact, front-loads the core action, and uses a clear imperative warning. Every sentence contributes meaningful information without redundancy or filler.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers the main concerns: real message, source channel, sender identity, stage update, and human approval. It is somewhat thin on return values or failure behavior, but those are not critical for invoking this tool correctly.

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

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

Schema description coverage is 0%, and the description does not explain either parameter in terms of expected values or formats. The 'text' parameter is indirectly referenced as 'drafted text,' but 'id' is never clarified as the lead identifier or how it should be resolved, leaving the agent to infer from the tool name.

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

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

The description states a specific action, sends a REAL LinkedIn message or email reply to the lead on their source channel from the customer's account, and also notes the stage change. It clearly distinguishes this from sibling tools like crm_add_comment or crm_move_lead by emphasizing the real outbound nature and source-channel behavior.

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

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

The description gives a clear safety directive that the drafted text must be shown to a human and approved before calling. It establishes the appropriate context for use but does not explicitly name alternatives or state when not to use this tool versus other CRM communication tools.

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

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

There are no annotations at all, so the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' which is valuable side-effect information, and clarifies the kinds of counts returned. It does not define 'stale,' but for a simple no-parameter stats endpoint the added transparency 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.

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

The description is extremely compact: one sentence containing the key metrics and a read-only warning. Every phrase adds information, and the most distinctive output ('Counts per stage') is front-loaded.

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

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

For a zero-parameter, read-only stats tool, the description covers the essential context: what the tool counts and that it has no side effects. It does not define the 'stale' threshold or timezone semantics, but these are minor gaps for such a simple tool and no output schema exists to provide more structure.

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

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

The input schema has zero parameters, so there is nothing for the description to document. The baseline of 4 applies here because no parameter semantics are needed and the description correctly focuses on the tool's output rather than nonexistent inputs.

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

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

The description names the resource ('CRM pipeline stats') and specifies exactly what it produces: counts per stage, new leads today/this week, and stale leads. This is specific enough to distinguish crm_stats from crm_list_leads, crm_list_stages, and other CRM listing tools.

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

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

The read-only, aggregate nature of the tool makes its intended use reasonably clear: get pipeline summary counts rather than individual lead details. However, it does not explicitly state when to prefer this over sibling tools like crm_list_leads or crm_list_stages, nor does it mention any exclusions.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose that this is a write operation and that there is no credit cost, which is useful safety/billing context. It does not mention partial-update semantics, whether unspecified fields are preserved, or any permission requirements, but the core mutation behavior is clear.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, and the additional behavioral notes ('Write operation, no credit cost') are both relevant and efficiently stated.

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

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

For a simple update tool, this is adequate but not complete. It does not explain whether omitted optional fields are left unchanged or cleared, nor does it describe what the tool returns in the absence of an output schema. An agent can likely proceed, but some behavior would need to be inferred.

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

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

Schema description coverage is 0% and there are six parameters, yet the description provides no detail about id, notes, title, all_day, starts_at, or ends_at. The schema's names and types carry all parameter meaning, and the description does not compensate for the lack of datetime formats, constraints, or update semantics.

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

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

The description states a specific verb and resource: 'Edit an existing custom calendar event.' It clearly differentiates from sibling tools like crm_create_calendar_event and crm_delete_calendar_event by emphasizing 'existing,' so an agent can identify the intended operation without opening the schema.

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

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

The phrase 'Edit an existing' provides clear context that this tool is for modifying already-created events, not for creating new ones. However, it does not explicitly name alternatives like crm_create_calendar_event or state when-not-to-use, so it stops short of a fully explicit routing guide.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It does add a useful 'Reversible' note and implies a partial update via 'Patch', but it omits critical traits like required id, side effects, and return values. Worse, it lists 'tags' as a patchable attribute while the schema has additionalProperties: false, and 'name'/'company' don't cleanly map to first_name/last_name/company_name, making the behavior somewhat misleading.

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

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

The description is appropriately brief and front-loaded: the core verb and resource appear immediately, and 'Reversible' is a distinct, useful behavioral note. The brevity is a strength, though the inaccurate field list slightly undermines the clarity that conciseness is supposed to provide.

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

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

With 9 parameters, 0% schema descriptions, no annotations, and no output schema, this description is far from complete. An agent cannot determine the exact accepted fields, the requirement of id, how field aliases map to schema properties, or what a successful patch returns. The description provides a high-level summary but not enough to invoke the tool correctly without external knowledge.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It names several fields but doesn't cover all nine schema properties, doesn't indicate that id is required, and introduces unsupported fields like 'tags'. The mapping between 'name' and first_name/last_name, or 'company' and company_name, is ambiguous, leaving agents unable to construct a correct request confidently.

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

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

The description clearly states a specific verb (Patch/Update) and resource (lead), and enumerates target attributes, which separates it from tools like crm_create_lead or crm_get_lead. However, it doesn't explicitly distinguish itself from other lead-related mutation tools like crm_move_lead or reassign_crm_lead, and some listed attributes ('name', 'company', 'tags') don't match the schema's actual field names.

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

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

There is no guidance on when to use this tool versus alternatives such as crm_create_lead, crm_move_lead, reassign_crm_lead, or delete_crm_lead. No prerequisites, exclusions, or contextual conditions are provided; the description simply states the operation without situating it among siblings.

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

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

With no annotations, the description carries the full burden. It discloses that this is a write operation, that it has no credit cost, and that turning notifications off has a real human consequence. This is meaningful behavioral context 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.

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

Three sentences, all earning their place: what it does, cost/safety context, and a user-confirmation warning. Front-loaded with the action and examples.

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

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

For a simple 4-boolean settings tool with no output schema, the description covers the key operational concerns: what changes, cost, and human impact. It doesn't document all parameters, but the schema provides names and types, and the description gives enough context for the main use case.

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

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

Schema description coverage is 0%, so the description must compensate. It names two of the four parameters (notify_new_lead, notify_new_reply) and gives them meaning, but it doesn't explain notify_stage_change or analytics_emails_enabled. The description adds some value but leaves half the parameters undocumented.

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

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

The description states a clear verb ('Change') and resource ('CRM settings') and gives concrete examples (mute new-lead or new-reply notifications). It is distinguishable from siblings like crm_get_settings and crm_update_lead, though it doesn't explicitly name them.

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

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

The description provides a concrete use case ('while an integration drives the CRM itself') and a clear caution ('confirm with the user first'). It doesn't explicitly say when to use an alternative, but the context is clear enough for an agent to decide.

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

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

With no annotations, the description must carry behavioral disclosure. It adds a useful restriction: 'System stages (New, Manager Dialog) cannot be renamed.' However, it omits other behavior such as color format, reversibility, permission needs, or effects on leads/workflows.

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

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

The description is two sentences with no filler; the core action comes first and the critical system-stage constraint follows immediately. Every sentence adds value.

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

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

For a simple update tool, the core operation and a key restriction are present. However, without annotations or an output schema, an agent still misses details such as accepted color format, whether at least one update field is expected, and what the response will be.

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

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

Schema description coverage is 0%, so the description must compensate. It maps 'rename' to name and 'recolor' to color and implies id identifies the target stage, but it does not explain color format, optionality, or constraints on id/name values beyond the bare schema.

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

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

The description opens with the exact verb and resource ('Rename or recolor a stage'), clearly identifying an update operation on an existing pipeline stage. This contrasts with sibling tools like crm_create_stage, crm_delete_stage, and crm_list_stages, so an agent can distinguish it by intent.

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

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

The intended use is implied: use this when a stage needs renaming or recoloring. The description does not name alternatives or explicitly say not to use it for creating/deleting stages, though it does note that system stages cannot be renamed as a limitation.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the operation mutates state ('Saves to the agent'), costs 15 credits, takes 60-180 seconds, and requires prior approval. This is strong behavioral transparency for a paid write operation, though it could further clarify whether existing saved scan data is overwritten.

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

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

The description is compact and front-loaded, covering scope, side effect, cost, and precondition in two dense sentences. Every sentence adds operational value, and there is no redundant or filler content.

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

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

For a paid, state-mutating operation with no annotations and no output schema, the description covers the most important operational concerns: prerequisites, cost, duration, and persistence. However, it leaves the three required parameters under-specified and does not describe what happens after the scan completes or what return value the agent should expect.

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

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

The input schema has 0% description coverage, and the description does not explain the meaning of 'id', 'company_name', or 'company_website' as distinct parameters. It implies company_website is the site to crawl, but leaves 'id' and 'company_name' ambiguous, which is a significant gap given the agent must provide all three required fields.

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

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

The description names a specific action ('Crawl 15+ pages'), a specific resource ('the agent's company website'), and specific outputs ('people, contacts, pricing, social links'). It also states the side effect of saving to the agent, which clearly distinguishes it from preview-only or quick-scan sibling tools.

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

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

The description explicitly provides a precondition: 'Only call after preview_deep_scan and user approval.' This tells the agent exactly when it is appropriate to invoke this tool and references the sibling that must precede it, leaving no ambiguity.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly states 'Permanently delete' and 'NOT reversible,' which are critical behavioral facts. It also adds the approval prerequisite. It does not describe cascading effects or permissions, but for a single-resource delete this is adequately transparent.

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

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

Two short sentences deliver the core action, irreversibility, and the required approval step. No filler or repetition; the most important safety information is front-loaded.

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

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

For a one-parameter destructive operation with no output schema, the description covers the essential context: what is deleted, that it is irreversible, and the prerequisite preview/approval flow. It could mention what happens to related data or the return response, but those are minor given the tool's simplicity.

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

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

Schema coverage is 0%, and the description does not explicitly document the `id` parameter. However, with only one required `id` property and a tool named delete_agent, the parameter's meaning is reasonably inferable. The description adds no format, source, or validation detail, so it only partially compensates for the missing schema documentation.

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

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

The description uses a specific verb and resource: 'Permanently delete an agent.' It also distinguishes the tool from its preview sibling by naming `preview_delete_agent`, and the resource differs clearly from delete_campaign and other deletion tools.

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

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

The description gives an explicit invocation condition: only call after the user has reviewed `preview_delete_agent` output and explicitly approved. This is a clear when-to-use gate and helps the agent avoid destructive action without confirmation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the critical irreversible, destructive nature ('Permanently delete', 'NOT reversible') and the required human approval gate. This is exactly the kind of high-risk behavioral context an agent needs before invoking a deletion tool.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, followed immediately by the irreversible warning and the approval prerequisite. Every sentence earns its place.

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

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

For a simple one-parameter deletion tool with no annotations and no output schema, the description provides everything needed to call it correctly: what it does, the destructive consequence, and the required precondition. It even points to the relevant preview tool for the approval workflow.

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

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

The schema provides 0% property descriptions, so the description must compensate. The single `id` parameter is reasonably inferable as the campaign identifier from the tool name and title, but the description adds no explicit detail about the id's format, source, or meaning beyond what the schema name alone implies.

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

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

The description uses a specific verb and resource: 'Permanently delete a campaign.' It clearly distinguishes this destructive action from previewing deletion, and the title's 'irreversible' adds a strong scope cue. An agent can immediately tell this is the actual deletion tool, not a preview or archive operation.

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

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

The description gives an explicit when-to-call condition: only after the user has reviewed `preview_delete_campaign` output and explicitly approved. It does not explicitly name alternatives like `archive_campaign` for reversible actions, but the prerequisite and warning are clear enough to prevent premature invocation.

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

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

With no annotations, the description carries full disclosure burden. It clearly reveals the soft-delete behavior, immediate effect on the pipeline, and that restoration is possible only by support. It does not mention side effects on associated data or response details, but the core safety-critical behavior is transparent.

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

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

Two sentences with no redundant words. The action is front-loaded, the consequence is stated, and the approval gate is explicit. Every word earns its place.

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

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

The description provides all essential safety-related context: the soft-delete nature, restorability constraint, and the required preview/approval workflow. It omits the return value or confirmation behavior and does not define the id format, but for a single-parameter delete operation, the critical information is present.

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

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

Schema coverage is 0% and the only parameter 'id' has no description. The tool description implies the id identifies the lead, but it does not explicitly state that. Since there is only one obvious parameter, the ambiguity is minimal, but the description does not compensate for the empty schema.

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

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

States a specific verb and resource: 'Soft-delete a lead' with immediate consequence 'it disappears from the pipeline'. Clearly distinguishes this from the preview sibling by labeling it a soft delete and from other delete tools by targeting leads specifically.

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

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

Explicitly states the precondition: 'Only call after the user reviewed `preview_delete_crm_lead` output and explicitly approved.' This tells the agent exactly when to invoke this tool and implies the preview tool must be called first, preventing accidental destructive actions.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the operation is destructive, applies only to empty/non-system stages, and requires explicit user approval. This is meaningful safety context, though it doesn't explicitly mention irreversibility or error conditions.

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

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

Two sentences with no filler. The core action and constraints are front-loaded, and the approval precondition follows logically. Every word earns its place.

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

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

For a one-parameter destructive tool with no output schema and no annotations, this description covers the essential context: what can be deleted, under what constraints, and the required approval step. Nothing critical is missing for an agent to invoke it correctly.

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

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

The schema has no description for the sole `id` parameter (0% coverage), and the description doesn't explain that `id` is the stage identifier or specify the expected value format. The tool name and context imply it, but the description adds no explicit parameter guidance.

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

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

The description states a specific verb ('Delete'), a resource ('pipeline stage'), and two explicit constraints ('EMPTY, non-system'). This distinguishes it from the sibling preview_delete_crm_stage (preview vs. actual deletion) and update_crm_stage (modify vs. delete).

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

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

It explicitly states when to call: only after the user reviewed `preview_delete_crm_stage` and explicitly approved. This gives a clear precondition and implicitly routes the agent to the preview sibling for the approval flow.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does add a useful side-effect ('Existing meetings stay in the user's calendar') beyond the title, but it does not explain reversibility, permissions, or what revoking affects beyond this one reassurance.

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

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

Two short sentences with no filler. The core action is front-loaded and the clarifying side-effect is expressed economically.

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

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

The description is adequate for a simple one-parameter tool, but the missing parameter semantics and lack of any guidance on what happens to the connection beyond the calendar note leave a modest completeness gap.

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

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

Schema coverage is 0% and the description does not explicitly explain that 'id' identifies the agent whose Google Meet connection should be revoked. The phrase 'for this agent' hints at it, but the parameter semantics are left mostly to inference.

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

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

The description uses a specific verb ('Revoke') and resource ('Google Meet for this agent'), clearly distinguishing it from connect_google_meet and other sibling tools. It also clarifies the relationship to meetings by stating they remain in the calendar.

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

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

The intended use is implied by the verb 'Revoke' and the contrast with connect_google_meet among siblings, but no alternative is named and no explicit when-to-use or when-not-to-use guidance is given.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It clearly discloses immediate effects: campaigns/SDR searches stop and daily capacity drops. It does not mention reversibility or idempotency, but the key operational consequences are transparent.

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

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

Three concise sentences, each carrying essential information: core action, immediate consequences, and the critical precondition. No filler or redundancy.

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

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

For a simple destructive tool with one parameter and no annotations or output schema, the description covers the key prerequisites and effects. It could be improved by specifying the id source, but the explicit reference to the preview step gives the agent enough context to identify the right account.

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

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

The schema has one required 'id' string with no description, and schema coverage is 0%. The description never explains what id refers to or where the agent should obtain it. While 'LinkedIn account id' is inferable, the description adds no parameter-specific meaning.

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

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

The description states a specific verb and resource: 'Remove a LinkedIn account from the workspace.' This clearly distinguishes it from related siblings like connect_linkedin_account, reconnect_linkedin_account, and preview_disconnect_linkedin_account.

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

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

The description gives an explicit precondition: 'Only call after the user reviewed preview_disconnect_linkedin_account and explicitly approved.' This tells the agent exactly when the tool should be invoked and names the prerequisite sibling tool.

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

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

With no annotations, the description must carry behavioral disclosure. It does add a useful detail: 'Bot keeps existing in Telegram but stops responding', which clarifies that the bot is not deleted. However, it omits other traits that would be valuable for a mutation tool, such as permission requirements, reversibility, or impact on other agents. The disclosure is minimal but non-trivial.

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

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

The description is two short sentences, front-loaded with the action ('Detach the bot from this agent') followed by the key behavioral note. Every word earns its place; nothing is redundant or extraneous.

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

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

For a tool with one required parameter, the description is incomplete because it does not explain what 'id' refers to, which is essential for correct invocation. The effect is described, but the missing parameter semantics leaves the agent unable to confidently call the tool. The lack of an output schema is not critical here, but the parameter gap is.

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

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

The schema has a single required 'id' parameter with 0% coverage (no description). The tool description does not mention 'id' at all, so the agent has no clue what the id represents (e.g., bot id, chat id, integration id). This is a critical gap given the facilitator's expectation that the description compensates when schema coverage is low.

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

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

The description states a specific verb 'Detach' and the resource 'the bot from this agent', and adds the effect (stops responding). It clearly implies the inverse of connecting a Telegram bot, but does not explicitly name or contrast with sibling tools like connect_telegram_bot. This is clear but just short of full sibling differentiation.

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

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

The usage is implied: use this when you want to disconnect a Telegram bot from the agent. However, there is no explicit guidance on when not to use it, nor any mention of alternative tools (e.g., disconnect_google_meet, disconnect_linkedin_account). The context is inferred but not stated.

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

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

With no annotations, the description carries the behavioral disclosure burden. It openly states a key side effect ('Counts toward agent capacity') and clarifies the copy's relationship to the original ('new id, same config'). It does not mention permissions or reversibility, but for a simple non-destructive duplication this is reasonably transparent.

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

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

Two short sentences carry all essential information with no filler. The core mechanism is front-loaded, and the capacity side effect is a separate, deliberate second sentence.

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

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

For a one-parameter agent duplication action, the description covers the input semantics, the behavioral effect, and a quota-relevant consequence. It does not describe the return value, but with no output schema that is a minor omission rather than a blocking gap.

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

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

Schema coverage is 0%, so the description must compensate. It does so by tying the lone id parameter to 'an existing agent,' which clarifies that id identifies the source agent to duplicate. Formatting or additional constraints are not needed for a single string parameter.

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

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

Description states a specific action ('Create a copy'), resource ('existing agent'), and unique semantics ('new id, same config'), clearly distinguishing it from create_agent and update_agent. The parenthetical compresses the core behavior into one precise clause.

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

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

The phrase 'existing agent' plus 'copy' establishes clear context: use this when duplicating an already-created agent rather than building one from scratch. It does not explicitly name create_agent or update_agent as alternatives, 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.

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 mentions cost and the prerequisite, but does not disclose what happens after generation — whether the description is returned, stored on the agent, or shown to the user — nor what the id parameter refers to.

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

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

A single, front-loaded sentence that conveys the action, output length, cost, and prerequisite with no filler. Very efficient.

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

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

The description leaves out essential invocation details: what id should be, what the output looks like, and whether the generated description is persisted. For a tool with no output schema, this is too incomplete for an agent to use confidently.

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

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

The input schema only defines id as a string, and the description gives zero explanation of what id means or how it relates to the agent. Schema coverage is 0%, so the description was expected to compensate but does not.

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

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

The description states a specific action: draft a 2-3 paragraph company description using AI, and the title clarifies the source is a website. This distinguishes it from sibling tools like generate_agent_script or scan_website_quick, though it does not explicitly name alternatives.

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

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

It gives a clear precondition: company_website must already be set, plus a cost warning of 1 credit. This tells an agent when the call is valid and set expectations, though it does not spell out when to prefer this over related tools.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that re-running overwrites the existing script, that it costs 1 credit, and that it requires company data to be present. It does not explain error behavior if the prerequisite is unmet or what the return value is, but the main mutation and cost effects are transparent.

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

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

Three short sentences deliver the output, the prerequisite, and the side effects with no wasted words. The main result is front-loaded, and each sentence earns its place.

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

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

The description covers prerequisites, cost, overwrite behavior, and the two artifacts generated, which is solid context for a mutation tool. However, with no output schema and zero schema-level parameter descriptions, leaving id, purpose, and script_style unexplained means the context is not fully complete for a correct call.

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

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

Schema description coverage is 0%, so the description needed to explain id, purpose, and script_style, but it does not. The title hints at sales/support/info and the schema enums are self-descriptive, yet nothing in the description maps parameters to outputs or explains what id refers to.

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

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

The description clearly states the tool generates the agent's sales script and email_script, which is a specific verb plus resource and distinguishes it from generate_agent_description. However, it only mentions the sales variant in the body while the title and schema include support and info purposes, leaving a minor ambiguity about whether purpose selects the script type.

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

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

The description explicitly gives a prerequisite and a required sequence: company_name and company_description must already be set, and set_agent_company should be called first. It also warns about cost and overwrite behavior. It does not explicitly contrast this tool with alternatives like generate_agent_description, so it misses full when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden. 'Fetch' clearly signals a read-only operation with no side effects, which is the core behavioral disclosure. It does not discuss not-found behavior or permissions, but for a simple fetch-by-id 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.

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

A single, well-structured sentence that front-loads the action, resource, and scoping condition. Every word contributes meaning with no redundancy.

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

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

For a one-parameter read tool, the description plus schema is nearly complete. It clearly indicates the input and the expected scope of output ('full details'). The lack of an output schema and any note about invalid/missing ids is a minor gap but not critical for simple retrieval.

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

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

The schema already fully documents the only parameter as 'The agent UUID' with 100% coverage. The description adds no further parameter meaning beyond restating that retrieval is by id, so the baseline of 3 applies.

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

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

The description states a specific verb ('Fetch'), a resource ('agent'), and a clear scope ('a single agent by id'). It distinguishes itself from list_agents and get_agent_plan_limits by emphasizing single-agent full-detail retrieval.

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

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

The description clearly implies when to use it: when you need full details for one specific agent by id. However, it does not explicitly mention alternatives or conditions for prefering a different tool, leaving some routing to inference.

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

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

No annotations are provided, so the description carries the full burden. It discloses 'Read-only' which is a key behavioral trait, confirming it has no side effects. However, it does not mention any other behavioral aspects such as authentication requirements, rate limits, or whether the response is just a count or includes additional details. Given the tool's simplicity, the single disclosure may be adequate, but it falls short of fully explaining what happens during the call.

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

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

The description is a single, concise sentence that front-loads the core purpose and includes the read-only trait. There is no wasted wording. Every word contributes meaning, and it is easy for an agent to parse quickly.

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

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

Given that there are no parameters, no output schema, and the tool is a simple read-only query, the description is complete. It clearly explains what the tool returns (capacity vs. current usage) and that it is read-only. An agent can invoke it without needing additional context, and the description is sufficient for understanding its behavior.

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

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

The tool has zero parameters, and the schema coverage is 100% (empty schema). The description does not need to explain any parameters because there are none. Per the rubric, a baseline of 4 is appropriate for zero-parameter tools, and the description does not claim anything contradictory.

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

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

The description clearly states what the tool does: returns the number of agents the user can create (base plan + purchased slots) versus how many they have. It uses a specific verb ('get') and resource ('agent plan limits', implied by the tool name and description). It distinguishes itself from sibling tools like get_agent, list_agents, and get_subscription_limits by focusing on capacity/availability. The purpose is unambiguous.

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

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

The description gives context by noting it is read-only and implies it is for checking capacity, but it does not explicitly say when to use this tool versus alternatives. There is no mention of situations where one would prefer get_subscription_limits or list_agents, nor any exclusion criteria. The usage is implied but not stated explicitly.

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

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

With no annotations provided, the description carries the behavioral burden. It explicitly discloses 'Read-only, free,' which is valuable safety and cost information beyond what the title or schema shows. It also states the return contents (filters and contact count), adding meaningful 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.

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

The description is a single, front-loaded sentence with no filler. Every phrase adds value: what it reads, what it returns, and behavioral safety/cost notes.

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

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

For a simple one-parameter read operation with no output schema, the description covers the key return contents (filters, contact count) and safety profile (read-only, free). It is slightly short on explicit parameter guidance, but the overall context 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.

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

Schema description coverage is 0%, and the description does not explicitly explain that the required 'id' parameter identifies the saved audience to read. The semantic is inferable from the tool name and title, but the description itself adds no direct guidance about the parameter's meaning, format, or source.

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

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

The description states a specific verb and resource: 'Read one saved audience' with its filters and contact count. It clearly differentiates from list_audiences (one vs. all) and get_audience_set (audience vs. audience set), so an agent can select it correctly.

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

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

The description implies this tool is for reading a single saved audience by ID, but it does not explicitly state when to prefer it over alternatives like list_audiences or search_audience, nor does it mention any exclusions. Usage context is implied rather than directly guided.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states 'Read-only, free,' and adds pricing context ('2 credits per contact'). This is strong for a simple read operation, though it doesn't describe response format or error behavior.

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

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

Two sentences with no filler. The key details are front-loaded, and every clause adds value: scope, slug, returned fields, and cost calculation.

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

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

For a one-parameter read-only tool with no output schema, the description is complete. It names the main return fields (size, description, freshness) and explains the cost-relevant contact count. Enough for an agent to call it correctly and interpret the result.

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

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

The input schema already documents the single slug parameter with a helpful note that it is a human-readable slug, not a UUID. The description adds that the slug identifies a 'marketplace set,' which is useful, but the schema already covers the parameter's core meaning, so this is baseline 3.

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

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

The description states a specific verb ('Details of one marketplace set'), a specific resource ('by slug'), and names the returned fields (size, description, freshness). This clearly differentiates from siblings like list_audience_sets and get_audience_set_contacts.

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

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

The description gives clear context: use this to view details of a single marketplace audience set and to compute purchase cost from the contact count. It does not explicitly name alternatives or exclusion conditions, but the marketplace-set framing and cost guidance make the intended use apparent.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It says the operation is read-only, free, paginated, and that contact details remain masked until purchase. This meaningfully informs an agent about side effects and cost, which is strong for a simple read tool.

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

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

Two short sentences deliver the core purpose, pagination behavior, masking caveat, and read-only/free status. Every clause earns its place, and the main action is front-loaded.

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

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

For a simple three-parameter read tool, the description covers purpose, behavior, cost, and the key masking caveat. It does not describe the returned payload shape, but given the absence of an output schema and the simplicity of the operation, the definition is still adequately complete.

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

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

Schema description coverage is 0%, so the description must compensate, but it only says 'paginated,' which indirectly maps to limit and offset. It does not explain that slug identifies the marketplace set or describe parameter formats, defaults, or constraints. The tool name helps, but individual parameters are largely undocumented.

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

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

The description opens with a specific verb-resource pair: 'Paginated preview of the contacts inside a marketplace set.' This clearly distinguishes it from sibling tools like get_audience_set (set-level info) and buy_audience_set (purchasing), and the tool name reinforces the target resource.

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

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

The description gives clear contextual guidance: this is for previewing contacts before purchase, and the masking note ('until the set is purchased') implies when it is appropriate. It does not explicitly name alternative tools or state when not to use it, but the pre-purchase preview purpose is evident.

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

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

With no annotations provided, the description carries the full behavioral burden. It explicitly discloses that the operation is read-only, has no side-effects, and incurs no cost, which is valuable for an agent deciding safe execution.

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

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

The description is two short sentences, front-loads the core action, and adds only the essential behavioral qualifier. Every word earns its place.

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

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

For a parameterless read-only balance query, the description is largely complete. It does not describe the return format or whether the balance is live or cached, but the absence of an output schema makes this a minor gap for such a simple tool.

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

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

The tool has zero parameters and 100% schema coverage, so there is nothing for the description to add at the parameter level. The baseline of 4 applies because no parameter documentation is needed.

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

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

The description clearly states the verb and resource: get the current credit balance for the account. It is distinct enough from the broader credit-usage and transaction tools, though it does not explicitly differentiate itself from the closely named sibling get_balance_full.

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

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

The description gives no guidance about when to use this tool versus alternatives such as get_balance_full, get_credit_transactions, or get_credit_usage_by_agent. An agent is left to infer the intended scope from the name alone.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the tool returns balance, credits, spent amounts, free-trial credits, and email/workspace info, which gives a reasonable sense of its read-only nature and data scope. However, it does not mention any potential side effects, response format, or limits, and the phrase 'email/workspace info' is vague. The description does not contradict any annotations.

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

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

The description is a single, compact sentence. It front-loads the key differentiator ('Richer than get_balance') and then lists the specific data points returned. Every word contributes value, with no redundant phrasing.

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

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

Given there is no output schema, the description should fully explain what the tool returns. It lists the main fields but leaves 'email/workspace info' vague and does not specify the exact structure or any limitations. While the tool is simple (no parameters), the description does not fully cover the output details an agent might need to trust its suitability.

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

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

The tool has zero parameters, so the description need not explain parameter semantics. According to the rubric, a baseline of 4 is appropriate for 0 params. The description focuses on output rather than inputs, which is sufficient given the empty input schema.

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

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

The description states a clear verb and resource ('returns balance, total subscription credits...') and explicitly differentiates from the sibling tool `get_balance` by calling itself 'Richer than get_balance'. This makes the tool's purpose unambiguous and distinct from its closest alternative.

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

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

It provides a clear context for when to use this tool versus `get_balance` by stating it is 'Richer than get_balance', implying the need for more detailed billing data. However, it does not explicitly name other alternatives like `get_credit_transactions` or `get_subscription`, nor does it describe when not to use those, so guidance is not fully explicit.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. 'Fetch' effectively communicates a read-only operation, but the description does not mention error handling, authorization needs, or what happens for invalid IDs. This is adequate but minimal.

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

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

The description is a single, compact sentence that front-loads the action and resource, then lists the specific fields returned. Every word contributes, with no redundancy or filler.

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

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

For a simple get-by-id tool with no output schema and no annotations, the description gives enough to call it correctly: what it does, the resource, and the kind of data returned. It could mention error or permission behavior, but that is a minor gap for this tool's simplicity.

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

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

Schema description coverage is 0% and the description does not explicitly define the 'id' parameter. However, with only one parameter named 'id' and the tool being get_campaign, its meaning is easily inferred. The description adds little semantic value beyond that inference.

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

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

The description uses a specific verb ('Fetch'), identifies the resource ('a single campaign'), and lists distinctive content ('status, sequence, channel paused flags, today stats'). This clearly differentiates it from sibling tools like list_campaigns or update_campaign.

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

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

The phrase 'single campaign' implies use when you need detailed data for one campaign rather than a list, but it does not explicitly name alternatives or state when not to use the tool. Usage context is implied, not direct.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It adds useful details: the result set is restricted to deductions and grants, and the ordering is newest-first. However, it doesn't describe the return record fields, default pagination behavior, or any edge-case behavior, leaving some important behavior implicit.

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

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

The description is a single, dense sentence with no filler. The core behavior is front-loaded, and the optional filters are listed compactly without repeating schema details unnecessarily.

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

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

For a tool with five optional parameters and no output schema, the description covers the essential inputs and the ordering behavior. But it omits the response shape, default limits, and whether the date range is inclusive, so an agent must infer some conventions. It is adequate but not fully complete for a tool with no annotations or output schema.

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

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

Schema description coverage is only 40%, but the description compensates by grouping the parameters into type, date range, and pagination, and by giving concrete type examples like EMAIL_SENT, LINKEDIN_INVITE, and SDR_CONTACT. This adds semantics beyond the schema's bare string type for the 'type' parameter and clarifies the purpose of the other parameters.

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

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

The description identifies the resource as credit transaction history, specifies the scope as 'deductions + grants,' and adds the 'newest first' ordering, which is specific enough to distinguish it from balance or aggregate usage endpoints among the credit-related siblings. It lacks an explicit verb, but the tool name supplies 'get,' so intent is clear.

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

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

The intended use is implied by 'Credit deductions + grants' and the optional filters, but there is no explicit 'use when' or 'instead use' guidance. Given the many credit/usage siblings like get_balance, get_credit_usage_by_agent, and get_credit_usage_by_type, the description doesn't proactively route agents to the right tool.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It makes clear this is a read/aggregation operation returning total spend per agent and that it can rank expensive agents. Yet it omits details such as the time period covered, whether results are sorted or limited, and any authentication or rate-limit considerations.

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

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

Two short, front-loaded sentences with no filler. The first states the core result, and the second adds a practical purpose. Every sentence earns its place, even though the opening sentence closely mirrors the title.

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

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

For a zero-parameter read-only aggregate tool, the description is nearly adequate: it names the output and the main use case. However, with no output schema and no annotations, it should more explicitly state the time period and ordering or limit behavior, especially given the cluster of closely related credit-usage tools.

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

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

The tool has zero parameters and the schema is empty with 100% coverage, so the baseline of 4 applies. The description's 'in the workspace' clarifies the implicit scope of the aggregate, which is all the schema can convey.

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

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

The description clearly states the operation (get), resource (credit spend), and aggregation level (per agent in the workspace). It adds an analytic purpose ('Identifies the most expensive agents') that goes beyond the name. However, it does not explicitly distinguish itself from closely named siblings like get_credit_usage_for_agent, get_credit_usage_by_type, or get_credit_usage_monthly, so some clarity is left to inference.

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

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

'Identifies the most expensive agents' implies a clear use case: cost analysis across agents. But the description never says when to choose this over the many similar credit-usage tools in the sibling list, nor does it provide exclusions or alternatives. Usage is implied but not explicitly routed.

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

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

There are no annotations, so the description itself carries the burden. It discloses the output shape (spend grouped by connection type) and the read-only nature is implied by 'get' and 'credit spend.' However, it says nothing about time-window behavior, response format, or any grouping limitations, leaving some behavioral ambiguity.

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

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

The description is a single efficient sentence with useful examples and the core grouping concept front-loaded. 'Useful for analytics' is somewhat generic but not harmful; no wording is redundant.

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

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

With no annotations, no output schema, and undocumented parameters, this description is too incomplete for an agent to reliably construct a correct request. It explains what the result is grouped by but not what the parameters mean, what range they cover, or how this report differs from the many other credit-usage tools.

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

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

The schema has 0% description coverage and the description adds no parameter meaning. The two parameters, 'to' and 'from,' are likely a date range, but this is never stated, and no guidance is given on formatting, required values, or how they affect the grouping.

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

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

The description clearly identifies the resource (per-session credit spend) and the exact grouping dimension (connection type), reinforced with concrete examples. This distinguishes it from sibling tools like get_credit_usage_by_agent or get_credit_usage_monthly even without naming them.

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

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

The only usage hint is 'Useful for analytics,' which is vague and does not explain when to choose this tool over the many closely related credit-reporting siblings. No when-to-use or when-not-to-use guidance is provided, and no alternatives are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the result ('total credits spent') and does not mention whether the total is all-time or date-bounded, whether the operation is read-only, or how missing or invalid agent IDs are handled.

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

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

The description is one short, front-loaded sentence with no filler, making it efficient and easy to parse. However, it is arguably under-specified; the conciseness is a strength, but the minimalism sacrifices useful guidance.

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

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

With no output schema and no annotations, the description leaves unclear what the response looks like (e.g., raw number, formatted string, credits vs. currency) and what time period the total covers. The abundance of credit-related sibling tools makes the lack of differentiation and usage guidance a meaningful gap.

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

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

The schema has no description for agent_id and parameter coverage is 0%, so the description must compensate. It never clarifies that agent_id is the identifier of the agent whose spend is returned, what format it should take, or how to obtain it, leaving semantics mostly to the parameter name.

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

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

The description states that the tool returns the total credits spent by one agent, which names a specific resource and metric. However, it does not distinguish this tool from the similarly named sibling get_credit_usage_by_agent, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as get_credit_usage_by_type, get_credit_usage_monthly, or get_credit_usage_by_agent. The phrase 'one specific agent' implies a use case, but no explicit conditions, exclusions, or alternatives are provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the returned data type ('per-channel credit spend') but does not state read-only behavior, time period covered, result ordering, authentication needs, or what happens when agent_id is invalid. This is a notable gap for an unannotated tool.

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

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

Two short sentences with no filler. The first sentence states the core behavior and the second adds decision-relevant value by explaining the tool identifies the costliest channels. Every sentence earns its place.

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

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

Adequate for a simple single-parameter read operation, but it lacks a time period (e.g., monthly, all-time) and does not describe the output shape despite there being no output schema. Among many credit-related sibling tools, the exact distinction could be sharper, though the core purpose is understandable.

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

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

The single agent_id parameter has zero schema description, but the description says the data is 'for one agent,' which clarifies that agent_id identifies the agent whose channel spend should be returned. With only one obvious parameter, this modest context is sufficient compensation for the 0% schema coverage.

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

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

The description states a specific verb-resource pair ('credit spend by connection') and clearly scopes it to 'Per-channel credit spend ... for one agent.' The concrete examples (widget, telegram, phone) and the 'per-channel' framing distinguish it from sibling tools like get_credit_usage_for_agent or get_credit_usage_by_type, even without naming them.

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

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

The description implies when to use the tool: when you need per-channel credit spend and want to identify costliest channels. However, it does not explicitly state when not to use it or name alternative sibling tools, so an agent has to infer the selection logic from the name and description alone.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses that the output is aggregated by calendar month and spans all categories, but it does not describe return format, date coverage, or whether this is a pure read operation. This is adequate for a zero-parameter query but not richly transparent.

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

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

A single sentence that is efficient and front-loaded. It loses a point because 'Calendar-month' duplicates 'monthly' from the title and 'credit spend' is repeated, though the 'across all categories' addition earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description is nearly sufficient: it names the aggregation period and scope. It does not spell out the exact return values or whether the data covers a specific range, but the simplicity of invocation lowers the burden.

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

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

The tool has no parameters, so the baseline is 4. The description correctly does not invent parameter details, and there is nothing beyond the empty schema to document.

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

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

The description states a clear resource and aggregation: a calendar-month breakdown of credit spend across all categories. It goes beyond the title by specifying the 'across all categories' scope, which helps distinguish it from per-agent or per-type credit usage tools. It lacks an explicit verb but the intent is unambiguous.

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

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

The description gives no guidance on when to prefer this tool over sibling credit tools such as get_credit_usage_by_type or get_credit_usage_by_agent. It implies a monthly reporting use case but does not 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.

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

With no annotations provided, the description carries the disclosure burden. It clearly indicates a read-only list operation and limits results to paid and open invoices, which is useful. But it does not mention pagination, ordering, or any authentication or Stripe-specific constraints.

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

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

Two short sentences, no filler, and the core purpose is front-loaded. The optional-filter information is placed right after the main purpose, making it easy to parse quickly.

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

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

For a low-complexity read-only tool with two optional parameters and no output schema, the description is serviceable: it states the result type and the available filter. However, it omits details about the return shape, pagination, and the exact filtering semantics, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description is the only source of param meaning. It correctly identifies year and month as an optional scope filter, but it does not clarify what date the filter applies to, whether month depends on year, or any default behavior.

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

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

The description names a specific operation and resource: it lists Stripe invoices and explicitly scopes them to paid + open statuses. This makes it easily distinguishable from the many other get_* and list_* sibling tools without needing to inspect schemas.

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

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

The description implies usage: call this when you need Stripe invoices, optionally filtered by year and month. However, it does not explicitly mention alternatives or when-not-to-use it, so some routing burden remains on the agent.

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

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

No annotations are provided, so the description bears the full burden. It offers a hint about the nature of returned data (views, sessions, conversion, drop-off) but omits behavioral details such as read-only status, error handling, or response format. The mention of per-slide drop-off is a slight positive, but overall disclosure 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.

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

The description is extremely short, which earns conciseness points, but it is a fragmented list of metrics rather than a structured sentence. It sacrifices clarity and does not articulate a complete action or resource context.

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

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

With no output schema, no annotations, and an undocumented parameter, the description is severely incomplete. It omits essential information such as return format, pagination, and the meaning of the ID – making reliable invocation impossible.

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

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

The schema has a single required string parameter 'id' with zero description coverage. The description does not clarify what the ID represents (presentation, narrator, campaign?), leaving the agent unable to construct a correct call.

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

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

The description lists output metrics (Views, sessions, conversion to lead, drop-off by slide) but never explicitly states that the tool fetches analytics for a given presentation or narrator ID. The title implies 'get analytics', but the operation's resource is only inferable from the 'id' parameter, which is not explained.

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

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

No guidance is given on when to use this tool versus other analytics tools (e.g., get_telegram_analytics) or any other context. It does not mention prerequisites, alternatives, or excluded scenarios.

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

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

No annotations exist, so the description carries the burden. It reveals relevant behavioral context: the catalogue is public and prices are localized to the user's currency, suggesting a read-only, user-scoped operation. However, it does not clarify authentication requirements, whether the result is a complete list, or any side effects (though 'List' strongly implies none).

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

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

The description is a single sentence that front-loads the key information: the list type, examples, and currency behavior. Every element earns its place, with no fluff or repetition of the title.

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

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

Given there is no output schema, the description should explain the return content, and it does: a list of public plans and add-ons with prices in the user's currency. It could be more precise about field structure or whether the list is exhaustive, but for a simple catalogue with zero parameters, it is largely complete.

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

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

The tool has zero parameters, so the schema is empty and the baseline is 4. The description adds meaningful context about the implicit output scope (public plans, add-ons, user currency) even though there are no parameters to document. This satisfies the semantic need without any parameter-specific elaboration.

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

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

The description states a clear action ('List') and a specific resource ('public plans + add-ons') with concrete examples (Extra Agent Slot, SDR sender pair) and pricing in user currency. It does not explicitly differentiate from sibling tools like get_subscription_limits or get_agent_plan_limits, but 'public pricing catalogue' makes the purpose distinct enough.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_subscription, get_subscription_limits, or get_balance. The word 'public' implies it is for browsing catalogue pricing, but there is no explicit when/when-not or reference to sibling tools, leaving the agent to infer usage.

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

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

With no annotations present, the description carries the behavioral burden and it does disclose that the call is read-only, which is the key behavioral trait. It also clarifies the semantic meaning of the returned numbers (included + purchased extras and estimated throughput), going beyond a simple 'returns capacity.' It does not mention auth/rate-limit concerns, but those are standard and not critical for this read-only getter.

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

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

The description is a single sentence that front-loads the core meaning and appends 'Read-only' as a crisp safety signal. Every phrase earns its place; there is no fluff or repetition of the tool name.

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

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