Relm CRM

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

No annotations provided, so description carries full burden. It describes the output (building blocks) and implies read-only behavior. Lacks detail on performance or side effects, but for a discovery tool it is adequate.

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

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

Extremely concise: two sentences with no extraneous information. Every word is necessary.

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 zero parameters and no output schema, the description is mostly complete. It tells what to expect and when to use it. Minor gap: does not describe output format or provide examples, but sufficient for its simplicity.

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

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

No parameters exist, so schema coverage is 100% by default. The description adds value by explaining what the tool returns, exceeding the baseline of 4.

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 it discovers automation building blocks and lists what it provides (trigger_events, condition ops, action types, etc.). It distinguishes itself from sibling CRUD tools by being a prerequisite discovery call.

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 says 'Call before building a rule or sequence,' giving clear when-to-use context. Does not mention alternatives or when not to use, but the context implies no alternative for discovery.

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 mentions that every operation counts against quota and that results are partial success, which are important. However, it does not disclose destructive potential (e.g., deletes) or any other behavioral traits like idempotency or error handling.

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

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

Two sentences front-load purpose and scope, followed by concise details on operation structure and quota behavior. No wasted words, every sentence adds value.

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

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

Given one parameter with nested objects, no output schema, and no annotations, the description provides sufficient context for an agent to invoke the tool: it explains the operation structure, the return type (partial success array), and a key behavioral note (quota). Minor lack of detail on error handling or rate limits, but adequate for most batch operations.

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

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

The input schema has one parameter with nested structure and 0% description coverage in the schema. The description adds meaning by detailing the array structure: 'operations: [{object, method:create|update|delete, data|patch, id?}]', which clarifies the allowed fields and methods.

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 it runs up to 100 record writes in one call, specifying the record types (contact/company/deal/activity) and positioning as the 'fast path for imports/migrations'. This distinguishes it from sibling single-record tools like relm_create, relm_update, relm_delete.

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

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

The description indicates the tool is for batch imports/migrations, implying when to use it, but does not explicitly state when not to use it or mention alternatives. The context is clear enough for an agent to differentiate from single-record operations.

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?

Discloses that the API key is encrypted at rest, which is valuable behavioral info. No annotations are provided, so description carries full burden. Could add details on idempotency or side effects, but the given disclosure is strong.

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

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

Two sentences, no fluff, front-loaded with purpose. Every sentence adds value.

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

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

Given 5 parameters, no output schema, and no annotations, the description covers purpose and key parameters but omits name, return value, prerequisites, and error scenarios. Adequate but has 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?

The description adds meaning for channel, provider, api_key, and from with example values, but does not explain the 'name' parameter. Schema description coverage is 0%, so description partially compensates but misses one 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 tool connects a BYO messaging channel so automations can send, specifying verb 'Connect' and resource 'messaging channel'. It distinguishes from sibling CRUD tools by focusing on channel connection.

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

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

The description provides context ('so automations can send') but lacks explicit guidance on when to use this tool vs alternatives, prerequisites (e.g., having a Resend account), or when not to use it.

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

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

No annotations, so description must carry transparency. It notes custom fields must be registered first and contacts need specific fields. Lacks details on side effects, permissions, or return values.

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?

Concise and front-loaded. Every sentence adds value 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?

Covers key constraints (custom fields, contact requirements). Lacks error handling and return value details, but sufficient for a simple creation tool.

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

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

Schema coverage is 50% (only object described). Description adds that data refers to relm_describe_schema and provides contact constraints. Adds value but still incomplete.

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 'Create a record' and the object parameter defines the types (contact, company, etc.). It distinguishes from sibling create tools (e.g., relm_create_field) by being the generic creation tool. However, it does not explicitly contrast with specific siblings.

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

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

Provides guidance: references relm_describe_schema for fields, relm_create_field for custom fields, and specifies constraints for contacts. However, it does not say when not to use this tool vs 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 full burden. It discloses that the automation is 'single-step' and provides the structure of conditions and actions, but does not mention side effects, authorization needs, or behavioral traits like whether it overwrites existing automations. This is minimal 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 two sentences plus an example, efficiently stating the purpose and key structure. It is front-loaded with the main action. The example adds value. Could be slightly more structured with separate lines for params.

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 5 parameters, no output schema, and no annotations, the description covers the main structure and provides an example. However, it does not explain the return value (e.g., created automation object) or error conditions, leaving some gaps. The reference to relm_automations_capabilities helps but is not fully complete.

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

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

Schema coverage is 0%, but the description adds significant meaning: it explains that 'conditions' is an array of objects with field, op, value (ANDed), and 'actions' is an array with type and body. It provides an example that clarifies usage. However, parameters like 'name' and 'enabled' are not elaborated beyond their schema types.

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 it creates a single-step rule with trigger_event, conditions, and actions. It uses specific verb 'create' and resource 'automation', distinguishing it from sibling tools like relm_manage_automation and relm_list_automations.

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 when you want to create a single-step automation, but does not explicitly state when to use this tool versus alternatives like relm_manage_automation for updates. It mentions relm_automations_capabilities for more info, which provides some context but no direct 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?

Discloses idempotency and return value (full value set). No annotations provided, so description carries full burden; adds key behavioral traits.

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

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

Two sentences, zero waste. Front-loaded with purpose and example, followed by 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?

Covers purpose, usage context, idempotency, and return value. No gaps given the tool's simplicity and no 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?

Description adds meaning for 'group' and 'value' with example, but 'label' parameter is not explained. Schema coverage is 0%, so description partially compensates.

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?

Clearly states verb 'Add', resource 'enum group', and example. Distinguishes from sibling tool relm_create by specifying when to use it (when relm_create rejects unknown type).

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

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

Explicitly says to use this tool when relm_create rejects an unknown type with a valid_options list. Provides clear context, though no explicit when-not-to-use.

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

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

Discloses a behavioral constraint (prerequisite for writing) but no annotations exist. Missing details on side effects, auth needs, error states, or idempotency. With zero annotation coverage, more transparency would be expected.

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

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

Two sentences, no filler. First sentence states purpose and scope; second adds type options and a key prerequisite. Every word is functional and 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?

With 6 parameters, no output schema, and no annotations, the description covers only objects and data_type, ignoring key, label, required, and enum_group. Also lacks return value or error behavior, making it insufficient for full understanding.

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

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

Schema has 0% description coverage; description partially compensates by listing data_type values and object options. However, key, label, required, and enum_group remain unexplained. Only adds limited 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?

Description clearly states it registers a custom field on specific objects (contact/company/deal/activity), using a strong verb 'register'. It distinguishes from sibling tools like relm_create_pipeline or relm_create_enum_value by focusing on custom fields.

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

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

Provides a prerequisite ('Must be created before it can be written to a record') but no explicit guidance on when to use this tool versus alternatives like relm_create_enum_value. Lacks when-not or context for exclusion.

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

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

With no annotations provided, the description carries full burden. It states a write operation (create) but does not disclose side effects, permissions, idempotency, or what happens on duplicate keys. The description is too brief for effective behavioral disclosure.

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

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

The description is a single, efficient sentence of 20 words, front-loading the core purpose. However, it could benefit from slight structural enhancement (e.g., listing parameters).

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

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

The tool has 4 parameters, no output schema, and no annotations, yet the description fails to explain key and name parameters, return behavior, or error conditions. This leaves significant gaps for an agent attempting to use the tool correctly.

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

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

Schema description coverage is 0%. The description adds meaning for two parameters (stages default format, is_default) but ignores key and name. This partial coverage is insufficient given the complete lack of schema descriptions.

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

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

The description clearly states 'Create a pipeline,' which is a specific verb+resource combination. While it does not explicitly differentiate from sibling create tools like relm_create_automation, the resource 'pipeline' is distinct enough to convey unique purpose.

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 mentions optional parameters and defaults but provides no guidance on when to use this tool versus alternatives like relm_manage_pipeline or relm_create. There is no context about prerequisites, use cases, or exclusions.

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

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

With no annotations, the description fully describes behavior: trigger auto-enrolls contacts, exit_when stops before each send, steps schedule emails, and enroll_existing enrolls current matches. Example clarifies real-world use. No contradictions.

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?

Concise, front-loaded structure: first sentence states purpose, then parameter semantics, then example. No unnecessary words; every sentence adds value.

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

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

Given 8 params, nested objects, no output schema, the description covers the key logic and provides a relevant example. It sufficiently enables correct tool invocation without requiring external knowledge.

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

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

Despite 0% schema description coverage, the description explains critical parameters (trigger, exit_when, steps, enroll_existing) and provides an example. However, it omits explanations for name, channel, enabled, and connection, leaving some gaps.

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

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

Clearly specifies 'Create a multi-step drip sequence', identifying the verb and resource. Differentiates from sibling tools like relm_create_automation or relm_create_template by detailing the sequence structure (trigger, steps, exit conditions).

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

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

Provides clear context about when to use (creating drip sequences) but lacks explicit when-not or alternative tool suggestions. The purpose clarity implicitly guides usage, but no exclusions 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 must disclose behavior. It explains auto-derivation of plaintext from HTML, allowed placeholders, and that subject/text are optional. No side effects or permissions mentioned, but adequate 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 three sentences: first states purpose, second covers parameters with brief details, third gives usage example. No wasted words, well-structured and front-loaded.

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

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

The description covers input sufficiently and provides usage context. However, it does not describe the return value or error conditions. For a creation tool with 5 parameters and no output schema, this is a minor gap but overall 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 0%, so the description must compensate. It explains that name and html are required, subject and text are optional with auto-derivation, and placeholders are allowed. This adds meaning beyond property names.

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 'Create a reusable email template', specifying the action and resource. Among many sibling tools with 'create' prefix, this one uniquely targets templates, making it distinguishable.

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 contextual usage: 'Reference it from a rule/sequence step via {...}', which guides the agent on how to use the created template. It does not explicitly exclude alternatives or state when not to use, but the integration guidance adds value.

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. It discloses idempotency on key and return of full type set, but lacks details on permissions, side effects, error behavior, or what happens if the key already exists (though idempotency suggests no error). More behavioral context is 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?

The description is one sentence, front-loaded with purpose. It is concise and to the point, though could be structured to include more detail without losing 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?

Given the tool's simplicity (2 params, no nested objects, no output schema), the description provides the essential purpose and a key behavioral trait (idempotency). However, missing parameter explanation for 'label' and no output schema description make it minimally adequate.

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

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

Schema description coverage is 0%, so description must compensate. It provides meaning for 'key' (idempotent) but does not explain 'label' at all. Insufficient to fully guide agent on parameter usage.

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 ('Register a new object type') and specifies the context (schema/registry). It also mentions idempotency and return value. However, it does not differentiate from sibling create tools like relm_create_field, but the name 'type' is distinct.

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

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

No explicit guidance on when to use this tool versus alternatives. The usage is implied by the name and description but no when-not-to-use or prerequisites are given.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: returns a secret only once, describes signature verification, and explains retry with backoff and dead-letter after 6 attempts. It does not cover prerequisites or error conditions, but the provided details are substantive.

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 efficiently structured with two sentences. The first sentence delivers the primary purpose concisely. The second adds essential behavioral details without redundancy. 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 the tool has 4 parameters and no output schema, the description covers the return value (secret once), signature verification, and retry policy. It lacks details about the enabled and description parameters, but overall provides sufficient context for an agent to use the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the events parameter by listing allowed values. However, it does not explain the url (though implicit), enabled, or description parameters beyond their schema types. Partial compensation.

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: 'Subscribe an https endpoint to CRM events.' It specifies the verb (subscribe) and resource (endpoint to CRM events), and distinguishes from sibling tools like relm_delete_webhook and relm_list_webhooks by focusing on 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 description implies when to use the tool (to create a new webhook subscription) but does not explicitly state when not to use it or mention alternatives among sibling tools. No guidance is given for choosing between this and relm_manage_webhook or other webhook 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?

Without annotations, description carries full burden; it discloses soft-delete behavior and permanence policy. Lacks details on side effects or 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?

Single sentence, front-loaded with 'Soft-delete', zero waste. 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?

Covers main behavioral trait but omits return value, confirmation, or asynchronous behavior. Adequate for simple tool but could be richer.

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?

Only one of two parameters has schema description; the description adds no extra meaning to parameters beyond 'which core object'.

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?

Clearly states it performs a soft delete and distinguishes from hard delete. Explicitly mentions recoverability via sibling tool relm_restore.

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?

Indicates use for deletion with recoverability, but does not explicitly exclude scenarios or differentiate from other delete tools like relm_delete_connection.

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 bears full burden. It states 'Delete' but does not disclose whether the deletion is irreversible, whether it requires special permissions, or what side effects occur. The example hints at safe cleanup but lacks detail.

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

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

The description is exceptionally concise: one sentence with an embedded example. Every part is necessary and front-loaded, with no wasted 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?

Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. However, it lacks behavioral details like permanence of deletion, dependencies, or error conditions, which are important for a delete operation.

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

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

Schema coverage is 0% (no description for the id parameter). The description adds value by specifying the parameter is used 'by id' and gives an example (Resend key), but it does not fully describe the parameter's format or constraints.

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 'Delete' and the resource 'connected messaging channel' along with an example use case involving a Resend key. This distinguishes it from siblings like relm_delete and relm_delete_webhook, though the term 'connected messaging channel' could be more specific.

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

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

The description gives a concrete example of when to use the tool ('to remove a rotated/wrong Resend key'), implying its use case. However, it does not explicitly state when not to use it or compare it to alternatives, leaving some ambiguity.

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

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

With no annotations, the description must fully disclose behavior. It only states 'delete' but does not confirm irreversibility, potential cascading effects, or whether special permissions are needed. The agent lacks crucial safety context for a destructive action.

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 without unnecessary words. While it lacks structure (e.g., no section headers), it is efficient for a simple delete tool. Not penalized heavily due to the tool's low complexity.

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?

Despite the tool's simplicity, the description fails to mention what happens on success or failure (no output schema). It also omits error scenarios (e.g., invalid id, webhook in use). The agent lacks complete context for expected outcomes.

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

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

Schema description coverage is 0% and the description adds no meaning for the 'id' parameter. It does not specify the format (e.g., UUID, integer) or how to obtain the id. The agent must rely solely on the schema type 'string', which is insufficient.

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 (delete) and the resource (webhook subscription) with the identifier method (by id). It is specific and unambiguous, distinguishing it from sibling tools like relm_create_webhook or relm_list_webhooks.

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 like relm_manage_webhook (which might update or disable). There are no prerequisites, conditions, or exclusions mentioned, leaving the agent to infer usage context.

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

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

Without annotations, the description carries the burden and adequately states the tool is read-only and returns schema elements. It does not disclose potential performance or caching behavior, but for a schema retrieval tool this is acceptable.

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

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

Two sentences with no wasted words. The first sentence defines the function, the second provides critical usage guidance. Structured effectively for quick agent comprehension.

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

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

The description is complete for a zero-parameter, no-output-schema tool. It covers what the tool returns and when to use it. Minor gap: not specifying the return format (e.g., JSON), but not essential.

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

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

The tool has no parameters, so the baseline is 4. The description adds no parameter details, but none are needed. It adds value by describing the output structure.

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 specifies the tool's purpose: returning the live schema including objects, fields, and enum groups. It uses a specific verb ('Return') and resource ('live schema'), and differentiates from sibling CRUD and automation tools.

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

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

The description explicitly advises 'ALWAYS call this before guessing a type, stage, or field - it is the source of truth.' This provides strong when-to-use guidance and implies it should precede other operations.

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

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

No annotations exist, so description must carry burden. It mentions idempotency but fails to disclose behavior such as whether enrollment triggers automations, if it is reversible, 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?

Two sentences, no redundant information, key points front-loaded (idempotency, source optional).

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?

No output schema, no mention of return values or error handling. Idempotency behavior not fully explained. Missing details for nested parameter and overall result of successful enrollment.

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

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

Schema has 0% description coverage. Description explains source as recording what drove enrollment but does not clarify contact_id or sequence_id beyond their names. Nested object lacks format 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?

Clearly identifies the action (enroll), the resources (contact into a sequence), and key property (idempotent). Distinguishes from siblings like relm_manage_sequence which likely handles automated enrollment.

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?

Description implies manual enrollment but does not explicitly state when to use this tool versus alternatives like relm_manage_sequence or other tools. No guidance on prerequisites or when not to use.

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

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

No annotations available, and the description lacks behavioral details such as error handling (e.g., if id not found) or return format. The description carries the full burden but only states the basic action.

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

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

Single sentence, very concise. However, it could include a brief mention of the object parameter without losing 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?

Given the lack of output schema and minimal description, the tool is under-explained. Missing details like success/failure behavior and required id format. Not enough for an agent to use reliably.

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 50% (only object has a description). The description does not add meaning for the 'id' parameter, which is missing a schema description. It also doesn't clarify the id format or expected values.

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 'Fetch one record by id.' It differentiates from list and search siblings. However, it doesn't explicitly mention the object type parameter, which is critical for understanding what records can be fetched.

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 on when to use this tool vs alternatives like relm_list or relm_search. The description provides no context for tool selection.

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

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

The description indicates this is a read operation, but with no annotations, it does not disclose other behavioral aspects such as authentication requirements, rate limits, or cost implications. For a simple read tool, the core behavior is clear, but additional transparency would improve it.

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

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

The description is two sentences, front-loading the tool's output and then providing a usage scenario. Every sentence adds value, and there is no wasted 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?

Given the tool has no parameters and no output schema, the description fairly covers what the tool returns and its typical use. It could be slightly more complete by mentioning that it is workspace-specific, but that is already implied by 'this workspace's'.

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

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

The tool has zero parameters, and the schema coverage is 100% trivially. The description adds meaning by explaining what data the tool returns, which is useful for an AI agent. With no parameters, a score of 4 is appropriate as the description compensates well.

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 it reads the workspace's billing period, listing specific data points (requests used, plan, monthly limit, overage). The verb 'Read' and resource 'workspace's current billing period' are specific, and this purpose is distinct from sibling tools which focus on automations, batches, etc.

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

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

The description explicitly advises using this tool to check quota before a big import, providing a concrete use case. While it does not enumerate when not to use it or list alternatives, given the tool's simplicity and unique purpose among siblings, this guidance is sufficient.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions keyset pagination but does not describe read-only behavior, rate limits, side effects, or what happens if filters invalid. For a list operation, it is likely safe, but lack of explicit transparency 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?

Two sentences: first states purpose and pagination, second provides filter specifics. No wasted words, front-loaded with key information. Efficient and well-structured.

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

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

Given 4 parameters, nested filter object, and no output schema, the description covers pagination and filter examples but omits details like cursor usage, limit defaults, and return format. Adequate but not comprehensive for complex usage.

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 leaves limit and cursor without descriptions, but the description adds keyset pagination context and concrete filter examples (email/company_id for contacts, etc.) that enrich understanding beyond the schema's vague filter description. Schema coverage is 50%, so description compensates well.

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 it lists records of an object with keyset pagination. It distinguishes from siblings by specifying core objects (contact, company, deal, activity) and noting optional filters per object, which contrasts with specific list tools like relm_list_automations.

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 records of core objects but does not explicitly state when to use this tool versus alternatives like relm_get, relm_search, or specific list tools. No exclusions or prerequisites 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?

The description lacks any behavioral detail beyond 'List'. With no annotations provided, the agent is not informed about read-only nature, pagination, or return structure. This is a significant gap for a list operation.

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

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

The description is concise and front-loaded with the key action and resource. However, it could be considered a fragment rather than a complete sentence, slightly reducing structure.

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 and no parameters, the description is incomplete. It fails to specify what information is returned (e.g., names, IDs) or any pagination behavior, which is essential for a list tool.

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

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

No parameters exist, so the description adds minimal value beyond the empty schema. Baseline for 0-parameter tools is 4, and the description is sufficient without param 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 explicitly states 'List reactive rules (automations)' which clearly defines the action and resource. It distinguishes from siblings like `relm_create_automation` and `relm_manage_automation` by focusing on listing.

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 like `relm_search` or `relm_list`. There is no mention of context or prerequisites, leaving the agent without decision support.

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 behavior. It reveals that the tool never returns the secret key, which is a critical security detail. However, it does not mention other behavioral aspects such as read-only nature, authentication requirements, or error handling, leaving some gaps.

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

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

The description is a single sentence that efficiently conveys the purpose and a key behavioral detail without any excess. It is well-structured and front-loaded.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description is minimal. It covers the core action and a notable constraint but does not describe the output format or any side effects, leaving room for ambiguity about what the agent will receive.

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

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

The tool has no parameters, so schema coverage is effectively 100%. The description does not need to elaborate on parameters. The score is a baseline 4 for parameterless tools.

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 'List' and the resource 'connected messaging channels', providing a specific purpose. It distinguishes from sibling tools like 'relm_list' by focusing on connections and explicitly noting that secret keys are never returned, which is unique to this tool.

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 (to list channels without exposing secrets) but does not explicitly state when not to use or provide alternatives. For example, if the secret key is needed, the agent would need to infer that another tool should be used. No explicit guidance is given.

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

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

No annotations exist, so the description carries full burden. It only states the action without disclosing any behavioral traits such as authentication needs, rate limits, or return format.

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

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

The description is a single, concise sentence. It gains no points for depth but loses none for verbosity.

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

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

For a simple zero-parameter tool, the description is minimally adequate. However, lacking explanation of 'ordered stages' or any broader context leaves room for improvement.

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

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

Input schema has zero parameters, so baseline is 4. No additional parameter info needed.

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

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

The description clearly states it lists pipelines and mentions 'ordered stages', which adds specificity. However, it does not explicitly distinguish from sibling list tools like 'relm_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 guidance on when to use this tool versus alternatives. With many sibling list tools, the description should provide context for tool selection.

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 for behavioral disclosure. It only says 'List', implying read-only, but does not explicitly state any side effects, permissions, or return behavior. The description lacks 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, short sentence with no unnecessary words. Every part is relevant and 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 no parameters and no output schema, the description covers the purpose but lacks details on output format or any constraints. It is minimally adequate.

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, and schema description coverage is 100% trivially. According to rubric, zero parameters baseline is 4. The description adds no parameter info because none exist.

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 it lists drip sequences with steps and enrollment counts, using a specific verb and resource. However, it does not explicitly differentiate from sibling list tools like relm_list or relm_list_automations, which slightly reduces clarity.

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. There is no mention of context, prerequisites, or when not to use it.

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

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

No annotations provided, so the description carries full burden. It only states the action (list) and resource (templates), implying a read operation but lacking details like pagination or scope.

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

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

Single sentence, no wasted words. Efficient but could benefit from slightly more structure.

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

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

Adequate for a simple list operation with no parameters and no output schema. Still, could mention that it returns all templates or any ordering.

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?

No parameters exist; schema coverage is 100%. Baseline 4 applies as per instructions for zero-parameter tools.

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 it lists reusable email templates, but does not differentiate from sibling list tools like relm_list or relm_list_automations.

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 on when to use this tool versus alternatives. Usage is implied but not explicit.

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

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

With no annotations provided, the description carries the full burden. It only states 'list webhook subscriptions,' which implies a read-only operation, but does not disclose potential pagination, authorization requirements, or whether it returns all subscriptions or just a subset. More detail is 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?

The description is a single concise sentence, front-loaded with the core action. No wasted words; every part 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 the simplicity of a list operation with no parameters and no output schema, the description is minimally adequate. However, it could mention return value format, pagination, or scope to improve 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 input schema has 0 parameters with 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema already conveys, which is acceptable given the absence of 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 it lists webhook subscriptions in the workspace/mode, using a specific verb and resource. Although it does not explicitly differentiate from sibling tools like relm_create_webhook or relm_manage_webhook, the action 'list' naturally distinguishes it from create/manage/delete 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 description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions. The usage is only implied by the tool name and brief 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?

No annotations are provided, so the description must fully disclose behavioral traits. It only states the tool logs an activity, without mentioning permissions, side effects, reversibility, or what happens on success/failure.

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

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

Two concise sentences with no wasted words. The purpose and key details are 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?

Given four parameters, no output schema, and no annotations, the description is too minimal. It lacks details on return values, error handling, defaults, or required combinations of parameters.

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

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

With 0% schema description coverage, the description adds meaning by listing activity types and indicating that contact_id and/or deal_id are needed ('on a contact and/or deal'), but doesn't specify constraints like which field is required or enumerate valid values for 'type'.

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 logs an activity (note/call/email/meeting/task) on a contact and/or deal. It specifies the action and the resource, distinguishing it as a convenience wrapper over a generic create activity.

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 mentions it's a convenience wrapper over 'create activity', implying an alternative to a more general tool, but provides no explicit guidance on when to use this tool versus other sibling tools like 'relm_create' or when not to use it.

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

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

With no annotations provided, the description carries the full burden. It explains the immediate effect of each action (e.g., disable stops firing, enable resumes, delete removes), which is good. However, it does not disclose potential side effects, errors (e.g., automation not found), idempotency, or authentication requirements. The description is minimally transparent but leaves gaps.

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 very concise: two short sentences plus one more for guidance. It front-loads the core purpose ('Manage an existing automation by id') and immediately lists actions. Every sentence earns its place, with no wasted 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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers the basic actions and usage hints. However, it fails to mention prerequisites (automation must exist), what the 'get' action returns, error scenarios, or required permissions. This leaves some important context missing for an AI agent to reliably invoke it.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains each enum value for 'action' (get, enable, disable, delete) with brief behavior statements. However, it only says 'by id' for the 'id' parameter, adding minimal meaning beyond the schema. Overall, it provides some semantic value but does not fully compensate for the lack of schema descriptions.

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

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

The description clearly states 'Manage an existing automation by id' and enumerates specific actions (get, disable, enable, delete), indicating the tool's purpose. It distinguishes from sibling tools like relm_list_automations and relm_create_automation by focusing on managing an existing automation, but does not explicitly differentiate from relm_delete for the delete action.

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

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

The description provides explicit usage guidance: 'action=disable stops it firing (use this to turn off a misbehaving rule)' and 'To change a rule's trigger/conditions/actions, delete and recreate.' These help the agent choose the right action and understand when to use this tool versus other approaches. However, it lacks guidance on when to use this over alternatives like relm_list_automations for reading automation details.

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

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

Describes key behaviors: get returns pipeline and stages, set_default changes default, delete fails if deals still reference it. No annotations provided, so description carries full burden; it covers the main behavioral traits but omits return values or concurrency 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?

Two sentences: first states overall purpose, second details each action. No redundancy, front-loaded with key information. Every sentence adds value.

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

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

For a tool with 2 parameters and no output schema or annotations, the description covers the main use cases and constraints. Lacks description of return format for the get action, but overall sufficient for basic understanding.

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

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

Schema descriptions are absent (0% coverage). The description adds meaning by explaining the action enum values and notes pipeline is identified by key or pl_id, but does not elaborate on the pipeline parameter format or constraints. Adequate but not thorough.

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?

Clearly states the tool manages existing pipelines by key or pl_id. Lists three specific actions (get, set_default, delete) with distinct verbs and resources, differentiating from sibling tools such as relm_create_pipeline and relm_list_pipelines.

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

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

Provides context for each action: get reads pipeline with stages, set_default makes it workspace default, delete removes it but warns it fails if deals still use it, advising to move deals first. Offers clear when-to-use guidance though not explicit 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 present, so description covers basic behavior for each action (read, stop, resume, delete, list) but omits details like reversibility of delete, error states, 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?

Single, well-structured sentence that front-loads the purpose and efficiently lists all actions without extraneous 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?

Covers core functionality but lacks explanation of the id field, output format for 'get' and 'enrollments', and prerequisites or error handling, which are important for a management tool.

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

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

Schema has 0% description coverage; description explains each action enum value beyond schema, but provides no details on the 'id' parameter (e.g., format, source).

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

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

Description clearly states 'Manage an existing drip sequence by id' and enumerates five specific actions, distinguishing it from sibling tools like relm_create_sequence (creation) and relm_list_sequences (listing).

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?

Description provides usage hints for disable ('use this to halt a bad sequence') but does not explicitly state when to avoid this tool or mention alternatives for other actions (e.g., enrolling users via relm_enroll).

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

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

The description discloses one behavioral constraint: 'a stage in use by deals cannot be deleted.' It also specifies the exact requirement for reorder: 'order = every existing stage key exactly once.' However, it does not mention other traits like idempotency, authorization needs, or side effects. Since no annotations exist, the description carries the full burden but only partially fulfills it.

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

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

The description is extremely concise with two clear sentences. The first sentence gives the overarching purpose, and the second breaks down actions. No fluff, and every word earns its place.

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

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

Given the tool has 6 parameters and no output schema, the description covers the primary functionality and parameter dependencies but omits the return value structure and details about the pipeline parameter. It is adequate but not fully comprehensive.

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

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

The input schema has 0% description coverage, so the description must compensate. It explains which parameters are required for each action (add, delete, reorder) and introduces the concept of ordinal position. This adds meaningful context beyond the raw schema types and enums. However, it does not explain every property individually, e.g., what 'pipeline' refers to or the exact format of keys.

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: 'Add, delete, or reorder stages in a pipeline.' It specifies a verb (add, delete, reorder) and a resource (stages in a pipeline), and it distinguishes from sibling tools like relm_manage_pipeline which manage pipelines themselves.

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 explains the parameter requirements for each action but does not explicitly guide when to use this tool versus alternatives. For instance, it does not say 'use this for stage modifications, not for pipeline settings.' The guidance is implicit but not comparative.

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. It clearly explains the behavior for each action, especially that deliveries returns recent attempts with status/retries/dead-letter for debugging. It doesn't mention any destructive effects beyond toggling, which is sufficient.

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

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

The description is concise, two sentences with clear structure. The first sentence states the overall purpose; the second lists actions and their effects. No wasted words, and each sentence adds value.

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

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

Given no output schema and no annotations, the description is fairly complete. It explains all actions and mentions debugging delivery failures. However, it does not specify the return format or pagination for deliveries, which could be helpful for a debug tool. Still, it covers the core functionality well.

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

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

Schema coverage is 0%, so description must compensate. It explains the action enum (get, deliveries, enable, disable) in detail, covering one of two parameters. The 'id' parameter is not described, but its purpose is self-evident from context. The description adds meaningful value beyond the schema.

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

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

The description clearly states the tool inspects or toggles an existing webhook by id. It lists each action (get, deliveries, enable, disable) and distinguishes itself from the delete sibling tool, making its purpose unambiguous.

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

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

The description provides when to use each action, e.g., deliveries for debugging delivery failures, and explicitly mentions that deletion is handled by relm_delete_webhook. However, it does not contrast with other siblings like relm_create_webhook or relm_list_webhooks, so it lacks full alternative 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 must carry full burden. It correctly states 'No side effects' and explains the output, but it omits details on required permissions, how to handle errors (e.g., invalid ID), or any limitations. Basic behavior is covered, but not comprehensively.

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 effectively front-loads the key purpose ('Dry-run a sequence') and concisely adds the output and side-effect note. Every word adds value 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?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is fairly complete: it covers purpose, output, and safety. However, it could be enhanced by mentioning that the sequence must exist or providing expected output format. Still, it suffices for the tool's basic function.

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 'id' is a string with no description. With 0% schema description coverage, the description should explain what 'id' represents (e.g., the sequence ID). The description does not mention 'id' at all, adding no 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 clearly states the tool is for dry-running a sequence, detailing what it outputs (enrollment count and send schedule) and that it has no side effects. This distinguishes it from sibling tools like relm_enroll which actually enroll, or relm_manage_sequence which modifies.

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 preview without side effects, but it does not explicitly state when not to use it or mention alternatives like relm_enroll. The context of sibling tools suggests a comparison, but the description lacks guidance for choosing between similar tools.

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

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

With no annotations, the description carries full behavioral burden. It lacks details on what 'soft-delete' entails, permissions required, reversibility, or impact on associated data.

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

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

The description is a single sentence, front-loaded with the core purpose. It is concise but could benefit from slightly more detail without becoming verbose.

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 and no annotations, the description is insufficiently complete. It fails to provide behavior details, usage context, or post-restore state, leaving gaps for effective tool 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 coverage is 50% (only 'object' has a description). The description adds no additional meaning beyond the schema; it does not explain 'id' or the enum values.

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 'Restore a soft-deleted record' clearly states the action (restore) and the resource (soft-deleted record), distinguishing it from siblings like create, delete, or update.

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 restoring soft-deleted records but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.

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

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

The description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or return format. Since no annotations are provided, the description should carry this burden, but it only states search behavior without safety or operational context.

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

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

The description is a single sentence of 11 words, efficiently conveying the core function without redundancy. Every word earns its place.

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

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

The description covers the main purpose but lacks details on pagination, search behavior (exact vs fuzzy), and return structure. Given no output schema, additional context would be beneficial for complete understanding.

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

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

The description adds meaning to the query parameter by specifying searchable fields (name/email/title), but does not explain the limit parameter (default, effect, etc.). With 0% schema description coverage, the description partially compensates.

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

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

The description clearly identifies the tool as a cross-entity search over contacts, companies, and deals by specific fields (name/email/title). It distinguishes from sibling tools like relm_list and relm_get, which operate on single entities or list all of one type.

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

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

The description implies usage for broad search across multiple entity types but does not explicitly state when to use this vs. alternatives like relm_list or relm_get. No exclusions or when-not-to-use guidance 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 provided, the description carries the full burden. It comprehensively explains the tool's behavior: setting a cap, the meaning of different values (overage, 429 error, unlimited, no overage), and its role as error recovery. No contradictions.

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

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

Two concise sentences with zero wasted words. The main purpose is front-loaded, and every phrase adds value.

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

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

For a one-parameter tool with no output schema, the description is complete. It covers the action, parameter semantics, behavioral outcomes, and usage scenario. No additional information is needed.

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

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

Schema coverage is 0%, but the description fully compensates. The single parameter 'overage_cap_usd' is thoroughly explained: it caps paid overage when a number, 0 means no overage, null means unlimited. This adds significant 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 clearly states the action ('Set or clear'), the resource ('hard monthly overage spend cap in USD'), and the effects of different values. It distinguishes itself from sibling tools by focusing on spend cap management.

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 mentions that this tool is 'the recovery for a spend_cap_reached error', providing clear context. While it doesn't explicitly state when not to use it, the behavior of each value (0, null, number) is clearly explained, guiding appropriate usage.

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

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

No annotations are provided, so the description carries the full burden. It discloses the concurrency behavior and the 412 error, which is a key behavioral trait. However, it does not explicitly state that the tool mutates data, permissions, or other 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?

The description is extremely concise with two sentences. The first sentence states the purpose, and the second adds key usage guidance. No redundant or unnecessary information.

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

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

The description is too brief given the tool's complexity (4 parameters, no output schema, no annotations). It does not explain the return value, error codes beyond 412, or whether the update is partial or full. This leaves significant gaps 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 only 25% (only 'object' has a description). The description adds value for 'if_match' by explaining its use in optimistic concurrency, but it does not describe 'id' or 'patch', leaving the agent to infer their meanings from 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 begins with 'Patch a record,' clearly indicating the verb and resource. The name 'relm_update' and the sibling tools (e.g., relm_create, relm_delete) confirm the update purpose, but the description does not explicitly differentiate it from other tools.

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

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

The description provides specific guidance on using the 'if_match' parameter for optimistic concurrency and how to handle a 412 response (re-fetch and retry). However, it does not state when to use this tool versus alternatives like relm_create or relm_search.

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