RubiConnect

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

With no annotations, the description itself must carry behavioral disclosure. The verb 'Checks' suggests a read-only capability lookup, and the agent-profile scope is clear; however, it does not disclose the return value shape, whether the check is synchronous, or any operational side effects.

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

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

A single sentence states the operation, scope, and messaging channels with no redundant wording. Every word earns its place.

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

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

For a simple three-parameter check the description is mostly complete, but there is no output schema and no explicit description of what the tool returns (boolean, capability list, etc.). An agent would still know the intent but may have to infer the exact response format.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description reinforces that 'recipient' and 'agent profile' matter but adds no new parameter-level meaning beyond the schema.

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

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

The description uses a specific verb ('Checks whether') and resource ('recipient's phone number... capable of receiving rich messages') and names the exact scope ('RCS or WhatsApp on a specified agent profile'). This clearly distinguishes it from send_message and other siblings.

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

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

The purpose implies that the tool should be run before sending rich messages to a recipient, but the description does not explicitly say when to use it versus alternatives or when not to use it. Sibling tools like send_message are not referenced.

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 communicates that the tool will 'dispatch' a campaign and can stream from a remote URL, but it does not mention permissions, irreversibility, background execution, downstream effects on contacts, or any rate/cost implications.

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 front-loaded with the core action and resource, and includes the key targeting distinction. Every clause earns its place; there is no redundant or filler text.

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 complex mutation tool with 12 parameters, no annotations, and no output schema, the description is too sparse. It omits what happens after dispatch, how the agent should interpret the result, and what setup conditions are required before 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%, so the schema already explains all 12 parameters. The description lightly reinforces the recipientSource distinction by mentioning stored contacts and remote HTTPS CSV/JSONL URLs, but it adds no parameter-level detail beyond what the schema already provides.

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

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

The description names a specific action and resource—'Create and dispatch an outbound messaging campaign'—and clarifies the two audience modes: stored contacts or a remote HTTPS CSV/JSONL URL. This is enough to distinguish the tool from siblings like send_message and create_template.

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 'outbound messaging campaign' implies when the tool should be used, and the two audience modes give context. However, the description does not explicitly state when to choose this over send_message or submit_template_to_meta, nor does it name any exclusions or prerequisites.

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

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 meaningful workflow context by explaining that WhatsApp templates are created as drafts in the workspace for review before Meta submission, which is a key behavioral trait beyond what the schema alone states. It could disclose more side effects or return behavior, but the most important special behavior is present.

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

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

The description is three sentences with no wasted words: it front-loads the core action, then lists supported variants, then adds the important draft-first workflow caveat. 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 14 parameters, rich schema descriptions, no annotations, and no output schema, the description provides the most crucial extra workflow context: the draft-first behavior for WhatsApp agents. A small gap remains around explicit routing to submit_template_to_meta and what the call returns, but the description is otherwise sufficient 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%, so the schema already documents all 14 parameters, including types, defaults, enums, and meanings. The description adds little parameter-level detail beyond mentioning supported template kinds, which the schema already covers, so the baseline score of 3 is appropriate.

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

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

The description clearly states a create action on a message template in the account library, names the supported template formats, and is easily distinguishable from siblings like send_message and submit_template_to_meta. The verb and resource are specific, and the scope is explicit.

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 strong contextual guidance by noting that WhatsApp agents create templates as drafts first for user review, implying this is the creation step rather than the submission step. It does not explicitly name an alternative such as submit_template_to_meta or state when to use it, so the guidance is clear but not fully exhaustive.

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 what is retrieved but does not disclose whether this is a read-only operation, whether it requires specific permissions, whether the agent must be verified, or what happens if the agent is not found. The description adds some context about the fields returned but lacks behavioral depth.

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

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

The description is a single, concise sentence that front-loads the main purpose and lists the key data categories. It is efficient and easy to parse, though it could be slightly more structured with explicit usage 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?

For a retrieval tool with no output schema and no annotations, the description is adequate but not complete. It lists what is retrieved but doesn't explain return format, error behavior, or prerequisites. Given the tool's simplicity and the schema covering parameters, this is a minimum viable description with clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate. It doesn't clarify the format of agentId or accountId, but the schema descriptions are sufficient.

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

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

The description clearly states the tool retrieves agent status, verification state, webhook endpoints, and configuration. It uses a specific verb ('retrieves') and resource ('agent'), making the purpose clear. However, it doesn't explicitly distinguish itself from sibling tools like list_agents or get_server_status, though the specific fields mentioned help differentiate it.

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 for inspecting agent details, and the schema notes that agentId is optional and falls back to the active agent from context. However, there is no explicit guidance on when to use this tool versus alternatives like list_agents or get_server_status, nor any exclusions or conditions.

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 disclose behavior itself; it clearly marks this as a retrieval operation and lists the returned metrics, which implies no side effects. It does not address error behavior, data freshness, or required permissions, but for a read-only analytics tool this is a moderate but not severe gap.

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 states the action, object, and key metrics with no filler. Every clause contributes useful signal.

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, parameters are fully documented, and the core metrics are listed, so an agent can invoke it. Still, without an output schema or a usage note, the description does not define the response shape or how this tool differs from get_message_stats/get_campaign_status.

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

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

Schema description coverage is 100%, so the baseline is 3; the description adds no new parameter-level details beyond reinforcing that campaignId identifies the campaign. Optional agentId and accountId are already fully explained in the schema.

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

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

States a specific verb ('retrieves'), a specific resource ('a specific campaign'), and concrete analytics (delivery rates, read rates, unique engaged users). This separates it from get_campaign_status, which suggests status rather than performance metrics.

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 'in-depth performance analytics' implies when the tool is relevant, but there is no explicit when-to-use guidance or mention of sibling alternatives like get_campaign_status or get_message_stats. An agent must infer the boundary from the tool name and description.

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 clearly signals a read-only operation via 'Retrieve' and discloses the specific data points returned, which is useful. It does not explain return structure, status value semantics, error behavior, or how optional filters affect results, but for a simple read tool the core behavior 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?

A single sentence that is front-loaded with the verb and resource, and lists the returned metrics without waste. 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 low-complexity tool with all parameters documented in the schema, the description is nearly sufficient: an agent knows the required parameter and what data will be returned. The lack of any output schema or mention of return format/status conventions leaves some ambiguity, but the gaps are not severe enough to prevent 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%, so the description need not reiterate parameter details. The phrase 'for a campaign' correctly maps to the required campaignId, but the description adds no extra meaning about agentId or accountId filtering beyond what the schema already states.

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 ('Retrieve') with a clear resource ('delivery status... for a campaign') and enumerates the exact metrics returned (sent, delivered, read, failed). It is clearly scoped to a single campaign, though it does not explicitly distinguish itself from siblings like get_campaign_performance or get_message_stats.

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

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

The description implies the tool is for checking campaign delivery metrics in real time, which gives reasonable context for use. However, it does not state when to prefer this tool over similar siblings, nor mention any exclusions or alternative routing.

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

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

With no annotations, the description carries full burden. 'Retrieves' clearly signals a read-only operation, and 'recent' adds a time-based scope. However, it does not mention ordering, pagination, or any response structure, which would be useful for a tool with no output 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?

A single, front-loaded sentence with no filler. It states the verb, object, and scope efficiently 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 simple read tool with a fully documented schema, the description covers the basic purpose, but it lacks usage guidance relative to siblings and does not explain return values or ordering, which would be more critical given the absence of an 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 100%, so parameter semantics are fully documented. The description adds minimal value beyond echoing 'recipient' and implying limit through 'recent', which does not exceed the baseline for fully covered schemas.

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 ('Retrieves') and resource ('recent back-and-forth chat messages and transcript') scoped to a recipient. It is clear but does not explicitly contrast with siblings like get_inbox_messages, which may also retrieve messaging data.

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 send_message, get_inbox_messages, or get_message_stats. The description implies a recipient-specific use case but does not state exclusions or prefer conditions.

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 says 'retrieve,' implying a read operation, but does not explicitly state that it is read-only or safe, nor does it mention pagination, auth requirements, or any side effects. This is a significant gap for a tool with zero annotation coverage.

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 efficiently states the core purpose. It is front-loaded with the verb and resource, but could have used the spare structure to add usage hints without becoming verbose, so it earns a 4 rather than a 5.

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 is the sole source of behavior info. It leaves key gaps: no mention that all parameters are optional, no hint about how omitted agentId resolves, no sense of whether this is a safe read, and no distinction from conversation history. For a tool with 4 optional parameters, this 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 100%, so the baseline is 3. The description adds only the notion of 'specific agent profile,' which maps to agentId, but does not add meaningful semantics beyond what the schema already documents (e.g., default limit, senderType enum, accountId scoping). It neither harms nor significantly helps.

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 ('Retrieve recent inbox messages and chat logs') and scopes it to 'a specific agent profile.' However, it does not differentiate from the sibling tool get_conversation_history, which likely serves a similar purpose, so it misses the explicit sibling distinction that would earn a 5.

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 get_conversation_history or get_message_stats. The description implies usage for recent inbox/chat retrieval but provides no conditions, exclusions, or alternative routing, leaving the agent to infer the right choice.

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

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

No annotations are provided, so the description must disclose behavioral traits itself. It reveals that the tool performs a read operation ('Retrieves') and returns aggregated metrics, but it does not mention permissions, rate limits, pagination, or any side effects. The read-only nature is inferable from the verb but not explicitly confirmed.

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, front-loading the key metrics. Every word contributes to the purpose, making it highly efficient.

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

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

The description explains the core output categories (volume, delivery rates, status breakdowns), which partially compensates for the missing output schema. However, it does not specify how these are structured (e.g., individual statuses vs. aggregates) or any defaults/limitations, leaving some ambiguity 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 100%, so each parameter is already documented. The description's mention of a date range adds little beyond the schema's startDate/endDate descriptions; the parenthetical examples (today, yesterday, last 7 days) are mild additions but not critical.

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 ('Retrieves...') and resource ('message volume, delivery rates, and status breakdowns'), which immediately distinguishes it from sibling tools like get_inbox_messages that retrieve raw messages. The specific metrics listed make the tool's purpose unmistakable.

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

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

The description implies usage for date-range analysis ('for a specific date range') but provides no explicit guidance on when to use this tool versus alternatives such as get_inbox_messages or get_campaign_performance. No exclusion criteria or alternative tool names 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. 'Retrieve' signals a read-only operation and 'real-time' implies a live network call, but there is no disclosure of error behavior, latency, or the absence of side effects. This is adequate for a simple status fetch but not deeply 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, well-constructed sentence that lists all three outputs without any fluff. The core purpose is front-loaded, and every word 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?

With no output schema, the description enumerates what will be returned (health status, messaging channels, protocol version) at a useful level of detail. It is complete enough for an agent to invoke the tool correctly, though it does not describe the exact response format.

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 are no parameter semantics to explain. The description appropriately focuses on the outputs rather than inputs. This meets the baseline for a no-parameter tool.

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 ('retrieve') and names three concrete resources: real-time health status, supported messaging channels, and MCP protocol version. It clearly identifies the RubiConnect server as the subject, making it easy to distinguish from sibling tools like get_agent_profile or list_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?

No guidance is given on when to use this tool versus alternatives, such as check_capability, which could overlap on checking supported channels. There is no mention of preflight use cases or explicit exclusions, so the agent is left to infer usage 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, the description carries full responsibility for behavioral disclosure. It conveys that this is a read-only retrieval operation and mentions the scope of data ('full content and configuration'), but it does not describe the return shape, error behavior, authorization needs, or what happens when the identifier is not found.

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 focused sentence with no filler. It front-loads the primary action and resource, and every word contributes meaning.

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?

This is a simple read tool with 100% schema coverage and no output schema, so the description is mostly adequate. However, because there is no output schema, the description should more concretely specify what 'full content and configuration' includes, and it could clarify the relationship to list_templates for an agent choosing among 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 100%, so the schema already fully documents all three parameters. The description adds no additional parameter semantics beyond restating that templates can be looked up by 'name or ID', which mirrors the schema's description of templateIdentifier.

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 ('Retrieves'), identifies the resource ('full content and configuration for a specific template'), and explains how the template is identified ('by its name or ID'). This clearly distinguishes it from sibling tools like list_templates, which enumerate templates rather than retrieving individual details.

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 its use case: retrieving detailed information about one specific template. However, it does not explicitly state when to prefer this over list_templates or create_template, nor does it provide 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 full burden of behavioral disclosure. It says 'cancel or delete' which implies mutation, but it does not explain consequences such as whether the action is reversible, whether any notifications are sent, or if there are any prerequisites like permissions. The ambiguity between 'cancel' and 'delete' is also unresolved.

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 conveys the essential purpose without any filler. It is appropriately sized for a simple tool with one parameter, and the 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?

While the tool is simple, the absence of annotations and output schema leaves gaps. The description does not clarify the distinction between canceling and deleting, nor does it mention side effects, required permissions, or what the response looks like. For a mutation tool, this is insufficient context.

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

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

Schema description coverage is 100%, so the visitId parameter is fully documented in the schema with an example. The description does not add any semantic meaning beyond what the schema provides, which meets the baseline for a tool with full schema coverage.

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

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

The description clearly states the action (cancel or delete) and the resource (scheduled appointment/visit) within the Jobber calendar context. This distinguishes it from sibling tools like jobber_schedule_visit, jobber_reschedule_visit, and jobber_get_visits, which are obviously different 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?

There is no guidance on when to use this tool versus alternatives. It does not mention when cancellation is appropriate, whether it should be preferred over rescheduling, or any conditions that might make it unsuitable. The description simply states what it does without contextual usage cues.

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 only states the action without revealing side effects (e.g., duplicate client handling, automatic property creation), permission requirements, or output 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 a single sentence with no filler, front-loading the action and subject. It is appropriately sized for the minimal information it conveys.

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 mutation tool with 9 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what happens after creation, what is returned, or any constraints beyond the input 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 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond what the schema already provides, though it does give high-level context of creating both a client and property.

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 (create), resource (client profile and property), and system (Jobber CRM). It is easily distinguishable from sibling tools like jobber_create_job and jobber_create_quote.

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 jobber_search_clients for existing clients or jobber_create_job for jobs. No prerequisites or selection criteria 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?

There are no annotations, so the description carries the full burden of disclosure. 'Create and book' communicates that this is a mutation possibly affecting job and visit records, but it doesn't mention permissions, idempotency, whether repeated calls create duplicates, or what response the agent should expect. This is a significant transparency gap for a 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?

The description is a single tight sentence with no filler, front-loading the core action and keeping optionality in a trailing clause. 'Book' and 'appointment scheduling' are mildly redundant, which keeps it from a 5.

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 10-parameter creation tool with no output schema and no annotations, one sentence is insufficient. The description doesn't clarify how the various date/time parameters interrelate, the required fields are only in the schema, and there's no mention of what the tool returns on success. The agent must rely heavily on the schema with no additional guidance.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds almost no parameter-level meaning beyond stating that appointment scheduling is optional, which is already clear from the optional date/time properties in the schema.

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

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

The description states a specific verb ('Create and book') and a resource ('field service job work order in Jobber'), which clearly distinguishes it from sibling tools like jobber_create_quote and jobber_create_client. The optional appointment scheduling is also mentioned, though it doesn't explicitly contrast with jobber_schedule_visit, preventing a perfect score.

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

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

The description implies this tool is for creating a new job, and 'optional appointment scheduling' hints at when scheduling fields should be used. However, it does not explicitly state when to use this tool versus alternatives like jobber_schedule_visit or jobber_create_quote, leaving usage guidance only 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The one-sentence description only states the action; it does not mention side effects, idempotency, permissions, success/failure responses, or any state changes beyond creation. For a write operation with zero annotation coverage, this is a significant gap.

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, succinct sentence with no redundancy. It front-loads the core action and target audience, making it easy to parse. Every word contributes to the purpose, earning full marks for conciseness.

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

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

For a creation tool with no output schema and no annotations, the description is incomplete. It omits information about expected return values (e.g., created quote ID), error scenarios (e.g., invalid clientId), or any prerequisites (e.g., client must exist). While the schema covers parameters, the description does not address operational context, leaving the agent without crucial details for correct invocation and result handling.

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

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

Schema description coverage is 100%, so each parameter already has a descriptive entry. The tool description adds minimal semantic value beyond the schema, only reinforcing that the quote is for a client. Since the schema handles parameter documentation well, a baseline of 3 is appropriate; the description does not enrich parameter understanding further.

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's purpose: generating a new price estimate/quote for a client in Jobber. It uses a specific verb ('Generate') and a resource ('quote'), and it distinguishes itself from sibling creation tools like jobber_create_client and jobber_create_job by explicitly targeting quotes.

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

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

The description implies the tool is for creating quotes but provides no explicit guidance on when to use it versus alternatives. It does not mention prerequisites (e.g., needing an existing client) or exclusions, leaving the agent to infer usage from context. Given the simplicity of the operation, this is acceptable but not thorough.

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 states the creation action and the 'triage/review' purpose, but does not mention permissions, side effects, response format, or any restrictions. For a mutation tool with no output schema, this is a significant gap—an agent cannot anticipate what happens after invocation or what errors might occur.

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 no wasted words. It front-loads the core action and key context, making it easy to scan. Every clause adds value, so conciseness is exemplary.

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

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

Given the absence of annotations, no output schema, and the tool's complexity (8 parameters, 1 required, part of a large sibling family), the description is too sparse. It does not explain the return value, the distinction from creating a job or quote, or any post-creation behavior. An agent needs more context to correctly select and invoke this tool over its 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?

The input schema has 100% description coverage for all 8 parameters, so the schema already provides thorough meaning. The description adds a minor hint about 'photos/images' aligning with imageUrls, but this is already documented. With high schema coverage, the baseline of 3 is appropriate; the description does not introduce additional 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 clearly states the action ('Create'), the resource ('inbound service request or lead inquiry'), and the context ('in Jobber for office triage/review'). It explicitly mentions attached photos/images, and the phrasing distinguishes this from sibling tools like jobber_create_job or jobber_create_client, making its purpose unmistakable.

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 context with 'inbound' and 'for office triage/review', signaling it is for new customer requests that need review rather than confirmed work. However, it does not explicitly name alternative tools or conditions when not to use it, leaving some inference to the agent. It provides clear context but lacks explicit exclusion criteria.

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 behavioral burden. It only uses 'Retrieve' to imply read-only behavior, but does not disclose what happens when the optional status filter is omitted, whether results are paginated, or how 'outstanding balances' relate to invoices. Critical behavioral details are missing.

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, focused sentence with no wasted words. The verb and resource are front-loaded, making it maximally concise.

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

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

For a simple one-parameter tool, the description is minimally adequate, but given no annotations and no output schema, it leaves important gaps such as default behavior, response format, and the relationship between invoices and balances. It could be more complete without becoming verbose.

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

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

Schema coverage is 100% with the status parameter fully described. The tool description adds no extra meaning to the parameter, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Retrieve') and resource ('billing invoices and outstanding balances') from 'Jobber', which distinguishes it from sibling tools that fetch jobs, quotes, or visits. However, it does not explicitly contrast with those siblings, and the phrase 'outstanding balances' is somewhat ambiguous about whether they are separate data objects.

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 no guidance on when to use this tool versus alternatives, no conditions, and no exclusions. It only states what the tool does, leaving the agent to infer usage from the name and resource type.

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 transparency burden; 'Retrieve' implies a read-only operation, which is useful, and the mention of statuses gives some sense of the output. However, it does not disclose pagination, result size, authentication implications, or whether statuses are returned alongside jobs or as a separate list.

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 entire description is a single, front-loaded sentence with no filler. It states the verb and object immediately and wastes no words.

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

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

For a simple read tool with one optional parameter this is almost sufficient, but the absence of an output schema and annotations means the description should do more to clarify the return shape and edge behaviors. The current text leaves the relationship between jobs, work orders, and statuses ambiguous.

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

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

Schema description coverage is 100%, so the status parameter is already documented. The description's mention of 'statuses' aligns with that parameter but adds no new semantic detail such as allowed formats, default behavior, or how filtering affects results.

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 a clear action ('Retrieve'), a specific resource ('job work orders and statuses'), and a source ('Jobber'), which distinguishes it from sibling tools like jobber_get_invoices and jobber_get_quotes. It does not, however, explicitly say it lists all jobs or how it relates to jobber_create_job.

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 about when to choose this tool over alternatives, no mention of exclusions, and no context about how the status filter should be used in selection. The only usage signal is implicit in the name and the optional status parameter.

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 on its own. It implies a read-only operation via 'Fetch' but says nothing about pagination, returned fields, authentication, or side effects, so it provides minimal 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 a single five-word sentence with no filler or repetition. It frontloads the verb and resource and wastes no space.

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?

There is no output schema and no annotations, yet the description doesn't hint at the response shape or any operational details like filters and limits. For a simple one-param tool this is on the edge, but an agent still lacks the information needed to interpret results 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 only parameter, status, is fully described in the schema with allowed values. The description adds no parameter-level detail beyond that, so baseline 3 applies.

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

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

The description uses a specific verb ('Fetch') and identifies the resource ('estimates and quotes from Jobber'), so an agent can tell this is a retrieval tool for Jobber quotes. It doesn't explicitly contrast with siblings like jobber_get_invoices or jobber_get_jobs, but the resource name is enough to disambiguate among the sibling 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?

No usage guidance is given. The description doesn't explain when to prefer this over jobber_create_quote, jobber_get_invoices, or other retrieval tools, and offers no prerequisites 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?

No annotations are present, so the description carries the disclosure burden. 'Fetch' reasonably signals a non-mutating read operation, and 'inbound' adds source context, but pagination behavior, authentication needs, output format, or any side-effect caveats are not mentioned.

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 clear sentence that states the resource, scope, and source with no filler. It is front-loaded and 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?

While the tool is simple and has only one optional parameter, the description does not provide enough context to reliably distinguish it from closely related sibling getters. There is no output schema and no guidance on what the returned requests look like, which leaves an agent guessing at the exact 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 single parameter 'status' is already fully documented in the schema with an example, and schema description coverage is 100%. The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Fetch') with a clear resource ('inbound quote and service requests from Jobber'), so an agent can tell it operates on Jobber request records. It does not explicitly differentiate itself from closely related siblings like jobber_get_quotes or jobber_get_jobs, which keeps it from a 5.

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 about when to use this tool versus alternatives such as jobber_get_quotes, jobber_get_jobs, or jobber_get_invoices. The only hint is the word 'requests' in the tool name; no conditions, exclusions, or alternative routes 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?

With no annotations, the description carries the full burden of disclosing behavior. 'List' clearly indicates a read-only operation with no apparent side effects, but the description does not mention response shape, pagination, authentication, or whether all or only active technicians are 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?

A single, front-loaded sentence conveys the entire purpose with no filler or repetition. Every word contributes meaning.

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 provides the essential context needed to invoke it: what it lists and in which system. It could add a bit more about the return format or the distinction between team members and field technicians, but nothing essential is missing 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?

There are zero parameters, so there is no parameter semantics for the description to clarify. The baseline for a no-parameter tool is 4, and the description appropriately avoids inventing unnecessary parameter 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 uses a specific verb, 'List', and a clear resource, 'team members and field technicians in Jobber'. This distinguishes it from all sibling tools, which handle jobs, quotes, visits, campaigns, or messaging.

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

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

The description implies the tool should be used when a caller needs the list of Jobber team members and field technicians. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites.

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

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. 'Retrieve' implies a read operation, but the description does not mention authentication, rate limits, pagination, or what happens if no visits match. This is minimal transparency beyond the tool's basic purpose.

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, focused sentence with no filler or redundant elaboration. It communicates the tool's purpose efficiently and is appropriately front-loaded.

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

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

For a simple tool with one optional parameter registered in the schema, the description is minimally adequate. However, there is no output schema and no mention of return structure or pagination, so the description does not fully cover what an agent might need when invoking the tool successfully.

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 documents the single optional 'status' parameter with an example of valid values, so schema coverage is complete. The description adds no further meaning about the parameter, but the baseline of 3 applies because the schema already handles parameter documentation adequately.

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 ('Retrieve') and resource ('scheduled visits and calendar appointments from the Jobber schedule'), making the tool's purpose understandable. However, it does not explicitly differentiate this from sibling retrieval tools like jobber_get_jobs or jobber_get_quotes, so it stops short of a 5.

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 about when to use this tool versus alternatives such as jobber_get_jobs or jobber_search_clients. The description only states what the tool does, leaving the agent to infer appropriate usage without any contextual selection criteria.

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. The description only says 'reschedule' which implies a mutation but does not detail what happens to the original appointment (e.g., whether it is deleted and recreated, or updated in place), whether it is destructive to any existing data, or any implications like conflict handling. This is a significant gap for a mutation 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 that is clear and front-loaded with the core purpose. There is no filler or redundant information, making it appropriately concise for the tool's simplicity.

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

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

Given the tool has 6 parameters and no output schema, and operates on existing data (a mutation), the description should provide more context about the side effects of rescheduling (e.g., what happens to the original appointment, whether it overrides or requires availability, and any restrictions). The schema covers parameter formats, but the description fails to explain the operational impact, which is essential for safe 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 description coverage is 100%, so all parameters are described in the schema. The tool description does not add additional meaning beyond the schema, but the schema already explains the purpose of each parameter. The description adds no extra context, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: to reschedule an existing Jobber calendar visit (appointment) to a new date and time. The verb 'reschedule' and resource 'Jobber calendar visit / appointment' are specific, and the action is distinct from creating or canceling a visit, though it could be more explicit about which sibling it replaces.

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

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

The description implies the tool is used when an existing visit needs a new date/time, but it does not explicitly say when to use it versus alternatives like jobber_schedule_visit (for new visits) or jobber_cancel_visit (for cancellations). It lacks explicit exclusions or conditions, but the adjacent siblings are clear enough for an agent to infer.

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 only conveys that a visit is scheduled, without mentioning that this mutates Jobber data, any conflict/idempotency concerns, or required permissions.

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 little waste. 'Jobber calendar schedule' is slightly redundant, but the overall structure is efficient.

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

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

For a mutating tool with 9 parameters)Skip no output schema, and no annotations, a one-sentence description is incomplete. It does not explain how startDate/startTime relate to startAt/endAt, which parameters are needed for a valid visit, or what the tool returns.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds no parameter-level meaning beyond restating that the job must exist, 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 ('schedule'), a resource ('appointment visit'), and a scope ('for an existing Job'). It is clear and semantically distinct from the sibling cancel/reschedule tools, 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?

No guidance is provided about when to use this tool versus jobber_reschedule_visit or jobber_cancel_visit. The phrase 'existing Job' implies a prerequisite, but there is no mention of exclusions, scheduling conflicts, or alternative tools.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It communicates that the tool searches by several field types and implies a read-only operation, but it does not state side effects, return behavior, pagination, or result limits.

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 redundant wording. It front-loads the action and resource, then provides the key search dimensions, making it efficient and easy to parse.

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 search tool, the description is mostly adequate for selection, but with no output schema and no annotations, it fails to state what the tool returns or how results are presented. This gap makes it minimally complete rather than fully 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 100% and the description essentially restates the schema's parameter meaning. It adds no significant semantics beyond what the input schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'Search' and names the exact resource, 'Jobber CRM clients,' along with the supported identifiers (name, phone, email). This clearly distinguishes it from sibling tools like create, get, or schedule 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?

The intended use is implied by the verb and resource: use it when you need to find a Jobber client by contact information. However, it does not explicitly discuss alternatives, exclusions, or when not to use it, leaving routing largely 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 must carry the full behavioral disclosure. It mentions the 'active' filter and account scoping, but does not disclose pagination, ordering, result limits, or error conditions. For a list operation, this is a notable gap since the agent cannot predict if all agents are returned at once or if further calls are needed.

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 with no fluff. It states the action, resource, and scope immediately. Every word earns its place.

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

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

For a simple list tool with one optional parameter and no output schema, the description sufficiently explains what is returned (active agent profiles) and the account scoping. It lacks details on return format or pagination, but given the low complexity and that the parameter is fully described, the description is almost complete. The missing behavioral details slightly reduce completeness.

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

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

The only parameter (accountId) has 100% schema description coverage ('Optional account ID (automatically scoped).'). The description adds no extra meaning to the parameter, so the schema already handles it. Baseline 3 applies because the schema fully documents the 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?

The description clearly states the verb 'Retrieve' and the resource 'active messaging agent profiles (RCS and WhatsApp)'. It distinguishes this from siblings like list_campaigns, list_templates, and get_agent_profile by specifying it lists agents rather than campaigns/templates and returns a collection rather than a single profile.

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 for listing agents, but it does not explicitly contrast with get_agent_profile for fetching a single agent. The context signals include siblings, but the description itself gives no explicit 'use this when...' or 'instead of...' guidance. The usage is reasonably clear from the resource name, but not formally 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?

Annotations are absent, so the description carries the full burden. It discloses the output (live delivery status, basic stats) and 'recent' ordering scope, but fails to state that this is a read-only operation, what 'recent' means, or any authentication or side-effect details.

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 with clear front-loading of the action and resource, and a compact description of included stats. No superfluous words; the only mild lapse is the omission of usage guidance, which costs a point.

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 small list tool with no output schema and no annotation, the description covers the core return content but not pagination/sorting details or the behavior of omitted agentId/accountId. The schema fills the latter gap, leaving residual ambiguity about the 'recent' boundary and statistics.

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

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

Input schema coverage is 100%, so the schema already thoroughly documents limit, agentId, and accountId. The description does not add parameter-specific meaning, which is acceptable per baseline when schema coverage is high.

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 action and resource precisely: 'list recent messaging campaigns' with the specific return content 'live delivery status and basic stats.' It is immediately distinguishable from siblings like get_campaign_status (single campaign) and get_campaign_performance (performance analytics).

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 explicit when-to-use instructions or alternatives to route to, such as get_campaign_status for a single campaign. The 'list' verb implies usage for getting multiple campaigns, but no exclusions or conditions are 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 full burden of behavioral disclosure, but it is minimal. It says 'Retrieves', implying a read operation, but does not explicitly state that it does not modify data, nor does it describe the return format, potential pagination, or any side effects. For a listing tool, the lack of information about what is returned (e.g., full objects vs. summaries) is a gap.

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 with no filler. It front-loads the core purpose, lists the specific template types, and specifies the scope. 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?

Given no output schema, the description should explain what the tool returns (e.g., a list of template objects, or summaries), but it does not. It also omits any mention of pagination, ordering, or authentication requirements. For a simple listing tool, however, the core functionality is clear, but the missing return details make it less than 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 coverage is 100%, so both parameters (agentId and accountId) are already described in the schema. The description adds no extra meaning beyond the schema, such as how agentId is used or what 'automatically scoped' means for accountId. Baseline of 3 is appropriate when schema already documents all 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 clearly states a specific verb ('Retrieves') and resource ('pre-configured rich media, card, carousel, and text message templates') scoped to 'an agent profile'. It distinguishes itself from siblings like create_template (creation) and get_template_detail (single template) by indicating a plural list retrieval, so an agent can tell it apart without opening 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?

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention that for a single template one should use get_template_detail, or that create_template is for creation. It only implies the action of listing, leaving the agent to infer appropriate usage. Given the existence of closely related siblings, more explicit routing would be 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the search scope and does not clarify whether this searches a local corpus, returns snippets or full pages, or has any limitations. While 'search' implies a non-destructive action, the agent is left without meaningful behavioral detail beyond the purpose itself.

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. Its list of content types is slightly redundant ('documentation' plus many subcategories), but it remains compact and easy to scan.

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 search tool, the description is mostly sufficient for selection and invocation. However, with no output schema, it does not state what the agent should expect as a result, and it lacks explicit usage routing. These are gaps but not crippling ones 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 description coverage is 100%, so the schema already documents both parameters adequately. The description adds some context by listing what kind of queries are supported, but it does not materially enrich the parameter semantics beyond the schema's own examples and the topic enum.

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: 'Search official RubiConnect documentation.' It also enumerates concrete content types (API references, character limits, console navigation, how-to guides), which makes the tool's scope immediately clear and distinguishes it from siblings like search_images and send_message.

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: whenever an agent needs official RubiConnect documentation or feature guidance. However, it does not explicitly state when not to use it or name an alternative, so an agent must infer this from the resource scope rather than receive direct routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does not mention what the tool returns (e.g., image URLs, metadata), whether it is read-only, or any side effects. While 'search' implies a read operation, the absence of explicit behavioral details leaves the agent uncertain about output format and potential mutations. The index parameter in the schema hints at multiple results, but the description fails to state this 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 concise (two sentences) and front-loaded with the core purpose, followed immediately by a sharp usage criterion. Every clause earns its place; no filler, no repetition of schema details. The 'ONLY use' constraint is bolded for emphasis, aiding quick scanning.

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 two simple parameters and no output schema, the description is expected to explain what the tool returns and any limitations. It does not mention the structure of results (e.g., list of image URLs, thumbnail sizes), how many results are returned, or how the 'index' parameter interacts with results (beyond schema's minimal note). This gap forces the agent to guess about the return format, which is critical for using the tool's output. The description also omits any constraints like licensing or content policy. Given the absence of annotations and output schema, this is a significant incompleteness.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by providing concrete example query terms ('espresso', 'discount banner', 'sunset'), which help the agent formulate effective queries. It also restates the purpose of the keyword query in context ('for message templates or cards'). This enriches the schema's basic parameter descriptions without redundant repetition.

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

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

Description clearly states it searches for stock photos/graphics for message templates or cards, with a specific verb and resource. It also distinguishes the intended use from general search by mentioning the specific context, which helps separate it from sibling tools like search_documentation.

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 only conditions under which to use the tool ('ONLY use this tool when the user specifically requests a card/carousel example or when actively creating a rich card template'). This provides clear when-to-use guidance and implicitly excludes other scenarios, leaving no ambiguity about 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, and it does add valuable traits: zero-persistence, remote streaming, and RCS/WhatsApp targeting. It does not disclose consequences such as send-side effects, costs, fallback behavior, or what happens when neither recipient nor contactsUrl is supplied, so transparency is only partial.

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 dense sentence with no filler; the primary single-recipient behavior is front-loaded and the bulk mode is appended as a clearly delimited alternative. Every component adds discriminative 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 9-parameter tool with zero required fields and no output schema, the description leaves critical calling context unstated: which parameters must accompany each mode, whether recipient and contactsUrl are mutually exclusive, and what the invocation returns. The omission is significant despite the 100% schema coverage.

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

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

Schema coverage is 100%, so the baseline of 3 applies. The description reinforces the role of contactsUrl ('remote HTTPS CSV/JSONL URL') and urlFormat ('csv/jsonl') but does not clarify parameter combinations or mutual exclusivity beyond what the schema already states.

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 and resource ('Sends a rich or text message') and then disambiguates the two invocation modes (single recipient vs bulk stream) plus channels (RCS/WhatsApp). It stands apart from siblings like create_campaign by emphasizing zero-persistence streaming rather than campaign creation.

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 OR between single-recipient and bulk-stream gives an implicit usage choice, and the 'zero-persistence' phrasing hints at when a direct send is appropriate. However, it never names alternatives or states when not to use it versus create_campaign, so the agent must infer routing.

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 disclosing side effects. It clearly signals an external submission action and includes a user-confirmation safeguard. It does not mention idempotency, reversibility, auth requirements, or rate limits, but the primary behavioral risk is well 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 concise sentences, front-loaded with the core action and followed by the critical guardrail. Every sentence earns its place and there is 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?

Given a complete parameter schema and a clear, action-guarding description, the agent can select and invoke the tool correctly. However, with no output schema or annotations, the description could add what happens after submission or what the return state indicates to be 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 100%, so the parameters are already well documented. The description does not add meaningful parameter-level detail beyond the schema; it only reinforces that the template already exists.

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 uses a specific verb ('Submits') with a clear resource ('existing WhatsApp template from the account library') and target ('Meta Graph API for official review and approval'). This clearly distinguishes it from siblings like create_template and list_templates.

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 states the precondition: 'ONLY invoke this tool after the user has seen the template preview and explicitly confirmed they want to submit it to Meta.' This gives clear when-to-use and 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.