API-first CRM for LLMs - contacts, companies, deals and activities over a native MCP server.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 41 of 41 tools scored. Lowest: 3.2/5.
Every tool targets a distinct resource-action pair (e.g., create_automation, create_pipeline, create_template), and potential overlaps like batch vs create or log_activity vs create are clearly differentiated in descriptions. No two tools appear to do the same thing.
All 41 tools follow the relm_<verb>_<noun> pattern in snake_case, with conventional verbs like create, get, list, delete, manage, and restore. Minor plural/singular differences (list_automations vs get_automation) follow standard resource-naming practices and do not break consistency.
At 41 tools, the set is far beyond the 25+ threshold and feels heavy for an agent to navigate. While the CRM domain is broad, many tools could be consolidated (e.g., generic get/list by resource type) without losing clarity.
The tool set covers the full record lifecycle (CRUD, restore, batch, search) plus schema management, pipelines, stages, automations, sequences, templates, webhooks, channels, and usage. However, automations, sequences, and templates lack update operations—requiring delete-and-recreate workarounds—which is a minor but notable gap.
relm_automations_capabilitiesADiscover the automation building blocks: valid trigger_events, condition ops, action types, channels/providers, and the shapes of automations/sequences/connections. Call before building a rule or sequence.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Discover' aligns with safe read-only behavior. It adds that the tool returns 'valid' definitions and 'shapes', but doesn't disclose output format or any additional behaviors, which is limited extra value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose ('Discover the automation building blocks'). Every word contributes meaning, with no redundant phrases. It wastes no space and is immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter discovery tool with no output schema, the description covers what information is returned (valid building blocks) and when to use it (before building rules/sequences). It could explicitly state the return format (e.g., 'returns a catalog'), but the current level is sufficient for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description compensates for the lack of parameters by outlining what information the tool returns (valid trigger_events, condition ops, etc.), which is more relevant to the user than parameter details. Baseline 4 for no-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function with 'Discover' and specifies the exact resources (trigger_events, condition ops, action types, etc.). It distinguishes itself from siblings by focusing on automation building blocks rather than creating, managing, or listing actual 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 instruction 'Call before building a rule or sequence' provides clear when-to-use guidance. It doesn't explicitly mention alternatives or when not to use it, but the context of a prerequisites tool is conveyed effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_batchARun up to 100 record writes in ONE call (contact/company/deal/activity) - the fast path for imports/migrations. operations: [{object, method:create|update|delete, data|patch, id?}]. Returns a per-op result array (partial success). Every op still counts against your quota (batch saves round-trips, not quota).
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructive, not read-only, not idempotent), the description reveals that results are a per-op array allowing partial success, that every op counts against quota, and that batching saves round-trips. This is valuable behavioral context not present in the schema or annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack all essential info: limit, objects, operation shape, return format, partial success, and quota nuance. The most important fact ('up to 100 in ONE call') is front-loaded. 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?
For a complex batch tool with no output schema, the description adequately explains the operation format, return behavior (per-op result array), and critical constraints (quota, round-trips). It's sufficient for an agent to invoke correctly without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'operations' has zero schema description coverage. The description compensates by explaining the exact shape: array of objects with fields object, method (create|update|delete), data|patch, and optional id. This adds meaning that the schema structure alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb 'Run' and the resource 'record writes' (contact/company/deal/activity), and specifies 'up to 100 in ONE call'. It stands apart from sibling single-record tools like relm_create, relm_update, and relm_delete due to its explicit batch nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'the fast path for imports/migrations', implying it's for bulk operations. It doesn't explicitly name alternatives or exclusions, but the context is strong enough to guide an agent when to choose this over individual write tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_connect_channelAInspectConnect a BYO messaging channel so automations can send. channel='email', provider='resend', api_key=, from='Team hi@you.com' (must be a verified Resend sender). The key is encrypted at rest.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | ||
| name | No | ||
| api_key | Yes | ||
| channel | No | ||
| provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=false, destructive=false, idempotent=false. The description adds meaningful behavior info: the API key is encrypted at rest, and the 'from' address must be a verified Resend sender. It does not contradict annotations. It could mention side effects or whether it creates/updates a connection resource, but adds useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and directly gives setup details. No fluff, every sentence adds value: purpose, example configuration, and security note.
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 write operation with no output schema, the description gives enough to attempt usage, but lacks details about return values, confirmation behavior, how to verify the connection, or what happens on failure. It also ignores the 'name' parameter. Given the complexity of 5 params and no output schema, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining channel, provider, api_key, and from with concrete examples. However, the 'name' parameter is left unexplained, and no constraints or value ranges are given. Still, it adds significant meaning for 4 of 5 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 the verb 'Connect' and the resource 'BYO messaging channel' with the goal 'so automations can send.' It distinguishes from siblings by specifying BYO channel integration (e.g., email via Resend), which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to set up a messaging channel for sending, and it gives concrete example values. However, it does not explicitly state when to use this versus alternatives like relm_create_webhook or relm_delete_connection, nor does it mention exclusions or prerequisites beyond the verified sender requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_createAInspectCreate a record. data is the object's fields (see relm_describe_schema). Custom fields must be registered first (relm_create_field). A contact needs at least one of: a name, an identifier (email/phone/linkedin_url), a company, or a custom field (email is unique per workspace) - don't invent a placeholder email.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | ||
| object | Yes | Which core object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral rules: custom fields must be registered first, contact records need at least one identifier or custom field, and email uniqueness per workspace. These constraints go beyond what annotations convey, though return value and failure behavior are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all information-dense: the action, the data shape reference, and domain-specific rules. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given minimal schema and no output schema, the description covers key aspects: how to discover fields, prerequisites for custom fields, and contact validation rules. It does not explicitly detail requirements for company/deal/activity records, but the pointer to relm_describe_schema addresses that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only documents the 'object' enum; the 'data' parameter is just 'type: object'. The description explains that 'data' contains the object's fields and directs to relm_describe_schema, while also giving concrete examples of valid contact identifiers, adding substantial 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 'Create a record' and the input schema's enum (contact/company/deal/activity) defines the resource. This distinguishes it from sibling create tools like relm_create_field and relm_create_pipeline, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical usage context: it references relm_describe_schema for field discovery, points to relm_create_field as a prerequisite for custom fields, and specifies contact data requirements. It also warns against inventing placeholder emails, offering clear exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_automationAInspectCreate a single-step rule: when [if ] then . conditions=[{field,op,value}] (ANDed), actions=[{type,...}]. Example: trigger_event='deal.stage_changed', conditions=[{field:'stage',op:'eq',value:'won'}], actions=[{type:'create_activity',body:'Deal won!'}]. See relm_automations_capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| actions | Yes | ||
| enabled | No | ||
| conditions | No | ||
| trigger_event | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context beyond annotations: it specifies that the rule is single-step, conditions are ANDed, and gives a structural example. However, it does not elaborate on side effects or execution behavior, though annotations already indicate openWorldHint=true.
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 core purpose. The example is valuable but slightly lengthy; however, it earns its place by clarifying the data structures.
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 non-trivial structure and no schema descriptions or output schema, the description provides a structural template, an example, and a cross-reference to capabilities. It lacks details on name/enabled and return behavior, but the essentials are covered.
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 significantly enriches the bare schema by explaining trigger_event, conditions, and actions with a concrete example. It covers the main complex parameters, though name and enabled are not explicitly described, they are self-evident.
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 function with a specific verb and resource: 'Create a single-step rule' and elaborates the structure (when/if/then). This distinguishes it from sibling tools like relm_get_automation and relm_manage_automation.
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 for creating an automation rule and references relm_automations_capabilities, but does not explicitly state when to use this tool versus alternatives or when not to use it. The example implies usage, but no explicit exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_enum_valueAAdd a value to an enum group (e.g. group 'contact.type' value 'partner'). Idempotent; returns the full value set. Use this when relm_create rejects an unknown type with a valid_options list.
| Name | Required | Description | Default |
|---|---|---|---|
| group | Yes | ||
| label | No | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states idempotency and return behavior ('returns the full value set'). While idempotentHint is already in annotations, the description adds the return value detail, which is not in the annotations or output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences: purpose, behavior, and usage. The example is embedded naturally. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers purpose, usage context, idempotency, and return value. The only minor gap is the label parameter semantics, which is not critical for understanding the tool's core 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?
Schema provides no parameter descriptions (0% coverage). The description partially compensates by using an example that clarifies 'group' and 'value', but the optional 'label' parameter is not explained. Thus 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?
Description clearly states the tool adds a value to an enum group, with a concrete example ('group contact.type value partner'). It distinguishes itself from sibling relm_create by explicitly referencing the rejection scenario.
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?
Explicit usage guidance is provided: 'Use this when relm_create rejects an unknown type with a valid_options list.' This directly tells the agent when to choose this tool over relm_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_fieldAInspectRegister a new custom field on an object (contact/company/deal/activity). data_type: text|number|boolean|date|select|multiselect|currency|reference|email|url. Must be created before it can be written to a record.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| label | No | ||
| object | Yes | ||
| required | No | ||
| data_type | No | ||
| enum_group | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only generic booleans (readOnly=false, destructive=false), so the description carries the burden of behavioral disclosure. It adds a key ordering constraint (must be created before writing) and enumerates valid data types, but does not describe duplicate-key behavior, permissions, or error handling, which would make it more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact data_type list, with no wasted words. It front-loads the core purpose and immediately provides the most crucial parameter constraint (data_type), earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description covers the core purpose, object types, data_type values, and a necessary prerequisite. But it omits semantics for enum_group and required, and does not mention the return value or error behavior for duplicate keys, leaving gaps for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does for data_type by listing all allowed values and for object by listing valid targets, which is helpful. However, it leaves enum_group, required, key, and label to inference, so the compensation is only partial.
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') and resource ('custom field') with valid object types (contact/company/deal/activity), making it unambiguous. It distinguishes itself from sibling tools like relm_create_enum_value and relm_create_type, which handle other schema elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('Must be created before it can be written to a record') which guides when to use this tool. It does not explicitly name alternatives or exclusions, but the context of registering a field before record writing is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_pipelineBInspectCreate a pipeline. Optionally provide stages [{key,label}] (defaults to lead/qualified/proposal/won/lost) and is_default.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| name | No | ||
| stages | No | ||
| is_default | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that stages default to a standard list when not provided, which adds behavioral context beyond the annotations. However, it does not describe return values, error behavior, or any side effects other than creation, and the annotations already indicate it is a write 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 a single sentence that immediately states the purpose and then adds optional parameter details. 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?
The tool has no output schema and lacks information about return values or post-conditions. The description covers default stages but omits key/name semantics and any mention of what a successful creation returns, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'stages' parameter structure and the 'is_default' boolean, but it does not explain the 'key' and 'name' parameters, leaving half the schema undocumented. With 0% schema description coverage, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a pipeline' with a specific verb and resource, clearly distinguishing from sibling tools like relm_create_automation or relm_manage_pipeline. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of relm_manage_pipeline for existing pipelines or relm_get_pipeline for retrieving, leaving the agent without decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_sequenceAInspectCreate a multi-step drip sequence. trigger={event,filter:[{field,op,value}]} auto-enrolls the matching entity's contact; exit_when=[{field,op,value}] stops it (re-checked before every send); steps=[{wait_days,subject,body}] (first step wait_days:0 sends now). enroll_existing:true also enrolls everything that currently matches. Example: 3 emails to contacts of deals entering stage 'lead', stop if the deal leaves 'lead'.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| steps | Yes | ||
| channel | No | ||
| enabled | No | ||
| trigger | No | ||
| exit_when | No | ||
| connection | No | ||
| enroll_existing | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations indicating a mutating non-destructive operation, the description adds significant behavioral context: trigger auto-enrolls contacts, exit_when is re-checked before every send, and first step with wait_days:0 sends immediately. It also explains enroll_existing side effects, going well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, covering purpose, key parameters, and an example in just three sentences. Every sentence contributes meaning without fluff.
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 complexity of creating a drip sequence, the description covers core behavior, side effects, and provides a concrete example. It does not detail return values, but no output schema exists and it's a create operation, so that's not a gap. The main logic is thoroughly explained.
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 coverage, the description compensates by explaining the structures of trigger, exit_when, steps, and enroll_existing, including nested fields like {field,op,value} and {wait_days,subject,body}. However, it leaves channel, enabled, and connection unexplained, so not all parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a multi-step drip sequence,' clearly stating the verb and resource. It distinguishes from siblings like create_automation or create_template by emphasizing 'multi-step drip' and detailing the sequence components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete example use case ('3 emails to contacts of deals entering stage lead...') that illustrates when to apply the tool. However, it does not explicitly name alternatives or state when not to use it, such as for single-step automations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_templateAInspectCreate a reusable email template. name, html (full HTML, {{field}} placeholders ok), optional subject + text (plaintext alt; auto-derived if omitted). Reference it from a rule/sequence step via {"type":"send_email","template":""}.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| html | Yes | ||
| name | Yes | ||
| text | No | ||
| subject | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that subject and text are optional and that text is auto-derived from HTML, which adds behavior beyond the annotations. It also provides the reference format for using the template. However, it does not mention return values, behavior on duplicate keys, or error handling, though annotations already indicate non-read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no fluff, front-loading the core purpose and then packing parameter semantics and usage example efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains inputs and usage well but omits any mention of the return value, which is significant given there is no output schema. It also doesn't address error conditions or idempotency, though idempotentHint=false hints at potential duplication. For a moderately complex create tool, the description is slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema_description_coverage at 0%, the description compensates by explaining name, html, subject, and text, including placeholders and auto-derivation. It indirectly covers 'key' through the reference format ('<key or tmpl_id>') but does not explicitly state whether key is optional or how it is used as an identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a reusable email template. It also differentiates from sibling create tools by specifying the resource (email template) and providing a reference syntax for use in rules/sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (to create a reusable template for later reference) but does not explicitly mention alternatives or when not to use it. It implies usage by describing how the template is referenced, but lacks explicit exclusion of other tools like relm_update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_typeARegister a new object type in the schema (registry). Idempotent on key; returns the full type set.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| label | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying that the operation is "Idempotent on key" (more precise than the generic idempotentHint) and that it "returns the full type set" (output behavior). It does not contradict the annotations (readOnly=false, destructiveHint=false, idempotentHint=true) and adds helpful context about retries and return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, then adds idempotency and return value. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two simple parameters and no output schema, the description covers the main action, safety traits (idempotency, non-destructive), and return behavior. However, it omits any explanation of parameter semantics and does not provide guidance on when this tool should be chosen over sibling create operations, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for "key" or "label" (0% coverage), and the description does not compensate by explaining their meaning or usage. The only hint is that idempotency is keyed on "key," but the purpose of "label" and the format/expected values for "key" remain unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb "Register" and identifies the resource as "an object type in the schema (registry)," clearly distinguishing this from sibling create tools like relm_create_field or relm_create_enum_value. It also notes idempotency and the return value, reinforcing its 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 implies the tool is for registering a new type, but it does not explicitly state when to use it versus alternatives such as creating a field or enum value. The idempotency note hints that it can be safely retried, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_create_webhookAInspectSubscribe an https endpoint to CRM events. events=['*'] for all, or a subset of ['contact.created','contact.updated','deal.created','deal.updated','deal.stage_changed']. Returns a secret ONCE - the subscriber verifies the Relm-Signature header (t=,v1=<hmac-sha256 of "t.body">). Deliveries retry with backoff and dead-letter after 6 attempts.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| events | No | ||
| enabled | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses critical behavior: secret returned only once, signature verification format, retry with backoff and dead-letter after 6 attempts. This adds value beyond annotations, which only indicate non-read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action, no fluff.
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 minimal param schema, the description covers purpose, event options, security handling, and delivery behavior, making it sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions. The description explains 'url' as the https endpoint and 'events' as a subset of listed event types, adding meaning. Params 'enabled' and 'description' remain implicit but are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Subscribe an https endpoint to CRM events.' This clearly identifies the tool as creating webhook subscriptions and distinguishes it from generic create tools and other webhook management tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: subscribe an HTTPS endpoint to CRM events, with event options. Although it doesn't explicitly mention alternatives, the scope is well-defined for a webhook creation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_deleteASoft-delete a record (recoverable via relm_restore). Never hard-destroys data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| object | Yes | Which core object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the destructiveHint annotation by specifying the deletion is soft/recoverable and never hard-destroys data. This adds essential behavioral context that annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, both information-dense, with no redundancy. Front-loaded with the core message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter deletion tool with annotations and a clear description, all necessary context is present. The absence of an output schema is fine; return values are implicit. The recoverable aspect is clearly communicated.
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 does not add parameter-level detail; the schema already documents 'object' with an enum and 'id' as a string, giving 50% coverage. Since coverage is not low, the baseline applies, and the description's focus on behavior is acceptable.
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 a soft-delete operation on records, with a specific guarantee that data is recoverable via relm_restore. This differentiates it from other delete-related siblings (relm_delete_connection, relm_delete_webhook) and from any permanent 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 implies the appropriate use case: deleting records while preserving recoverability. It names relm_restore as the recovery mechanism, providing clear operational context. However, it does not explicitly contrast with a permanent-delete alternative, though none appears among siblings for core objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_delete_connectionADelete a connected messaging channel by id (e.g. to remove a rotated/wrong Resend key).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds the object type ('connected messaging channel') and an example, but does not disclose additional side effects or prerequisites beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical example. It is front-loaded with the action and resource, and 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?
For a simple one-parameter delete tool with destructive and idempotent hints provided by annotations, the description covers the core purpose and provides a use case. It could be more complete by mentioning relm_list_connections as a way to obtain the id, but the current description is adequate for selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter is 'id' with no description. The phrase 'by id' clarifies that the parameter refers to the connection's identifier, but it does not explain how to obtain the id or what format is expected, so it only partially compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'connected messaging channel by id', clearly distinguishing it from broader sibling tools like relm_delete and relm_delete_webhook. The example 'remove a rotated/wrong Resend key' reinforces the specific 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 provides a concrete use case ('remove a rotated/wrong Resend key') that implies when to use this tool, and the 'by id' phrase indicates scope. However, it does not explicitly compare to alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_delete_webhookADelete a webhook subscription by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that a webhook subscription is deleted, which clarifies the target of destruction. However, it adds no behavioral context beyond what annotations already provide (destructiveHint, idempotentHint). It does not mention side effects, reversibility, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary information. It effectively communicates the essential purpose and key parameter.
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 delete operation with one parameter and no output schema, the description is largely complete. It covers the action and target, while annotations handle safety traits like destructive and idempotent hints. It doesn't mention return values or post-delete state, but these are not critical for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'id' parameter with no description. The description says 'by id', which clarifies that the parameter identifies the webhook subscription to delete. This adds minimal meaning beyond the schema, but does not provide details about id format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('webhook subscription') and specifies the key identifier ('by id'). This clearly differentiates it from sibling tools like relm_create_webhook or relm_get_webhook. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like relm_manage_webhook. It simply states the action without context, prerequisites, or exclusions. The usage context must be inferred entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_describe_schemaAReturn the live schema: every object, its fields (built-in + custom), and all enum groups with their current values (contact types, activity types, etc). ALWAYS call this before guessing a type, stage, or field - it is the source of truth for what exists.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and destructiveHint, so the description adds value by explaining the tool returns live data and serves as the source of truth. It clarifies the scope (built-in + custom fields, enum groups) beyond the structured annotations, without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action ('Return the live schema'), then a concise imperative for usage. No wasted words; every phrase adds value, including the specifics of built-in/custom fields and enum groups.
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 only a read-only annotation, the description is fully complete. It explains what the schema contains, when to call it, and its authoritative nature, leaving no gaps for an agent to misuse 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 tool has zero parameters, and the schema description coverage is 100% (trivially). With no parameters to document, the description does not need to add parameter detail. The baseline of 4 applies due to 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 the tool 'Return the live schema' with specific details on content (objects, fields, enum groups). It uniquely identifies this as the schema-defining tool, distinct from all sibling tools. The imperative 'ALWAYS call this before guessing' reinforces its purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'ALWAYS call this before guessing a type, stage, or field.' It establishes the tool as the source of truth, but does not explicitly mention when not to use it or alternative tools, though no sibling provides similar schema introspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_enrollAManually enroll a contact into a sequence (idempotent per contact+sequence). Optional source={object,id} records what drove the enrollment (e.g. a deal).
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| contact_id | Yes | ||
| sequence_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'idempotent per contact+sequence' beyond the idempotentHint annotation, clarifying the scope of idempotency. It also explains the optional source parameter's purpose, which is not evident from schema. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. It front-loads the primary action and idempotency qualifier in the first sentence, then addresses the optional parameter in the second.
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 enrollment with no output schema, the description covers the essential behavior, idempotency, and the optional source field. It omits return format or error details, but these are not critical given the simple mutation and existing annotations.
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 explicitly explains the source parameter structure and meaning, and the verb phrase clarifies that contact_id and sequence_id refer to the contact and sequence involved. This provides sufficient semantic grounding for all three 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 'Manually enroll a contact into a sequence', specifying the action and resource. It distinguishes from sibling sequence tools by focusing on enrollment rather than creation or 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 implies usage for manually enrolling contacts, but does not explicitly state when to use this tool over alternatives like relm_manage_sequence or relm_create_sequence. It provides no exclusions or alternative references, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_getBFetch one record by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| object | Yes | Which core object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the obvious fetch-by-id operation; it does not disclose error behavior or return format, but also does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. It earns its place by stating the core purpose, though it could be slightly more detailed 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?
For a simple get-by-id tool with annotations and a 2-param schema, the description is minimally adequate. However, without an output schema, it does not explain the return value shape or error behavior (e.g., what happens if the id is not found), leaving minor gaps in 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?
Schema coverage is only 50% (only 'object' has a description). The description 'Fetch one record by id' adds little to the 'id' parameter, which remains undocumented. It does not explain that 'object' is required or the meaning of the enum values, leaving the agent to rely on the parameter names and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetch one record by id' clearly states the verb (fetch) and resource (one record by id). It distinguishes itself from siblings like relm_list (list all records) and relm_search (search records) by focusing on a single record lookup.
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 that relm_list or relm_search should be used for multiple records, nor does it specify any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_get_automationARead one automation by id, with its trigger, conditions and actions.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the response includes trigger, conditions, and actions, which is useful context. However, it does not describe error behavior, return format, or any limitations beyond that.
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, front-loaded with the verb 'read'. No filler, no redundancy. It efficiently conveys the purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with one parameter and clear purpose, the description is mostly complete. It mentions the key content (trigger, conditions, actions), though it omits details about return format and error behavior. Given the lack of an output schema, this is a minor gap but does not hinder 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 input schema has one required parameter 'id' with no description (0% coverage). The description merely says 'by id', which adds no additional meaning about the id's format, source, or validation. Since schema coverage is low, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read one automation by id, with its trigger, conditions and actions.' It uses a specific verb ('read') and resource ('automation'), and explicitly distinguishes itself from generic getters like relm_get by naming the resource and the included components.
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 this tool (when you have an automation id and need its details) but does not explicitly discuss alternatives or exclusions. It doesn't mention when to prefer relm_get_automation over relm_get or relm_list_automations, nor does it state any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_get_pipelineARead one pipeline by key or pl_ id, with its ordered stages and their semantic types (open/won/lost).
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds valuable context about the response structure (ordered stages and semantic types open/won/lost), which is beyond the annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action ('Read one pipeline') and includes essential 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?
For a simple get tool with one parameter and no output schema, the description covers the purpose, identifier type, and key return elements. It does not mention potential error cases or the exact format of 'key', but given the low complexity and rich annotations, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'pipeline' as a string with no description. The description clarifies that this parameter can be a 'key' or 'pl_id', adding meaning beyond the schema. The 0% schema coverage is compensated by this explanation, though examples or format details are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one pipeline by key or pl_id, and lists what is returned (ordered stages with semantic types). This distinguishes it from sibling tools like relm_list_pipelines (listing multiple) and relm_manage_pipeline (mutating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Read one pipeline' implies use for single pipeline retrieval, contrasting with listing tools, but there is no explicit when-to-use or alternative guidance. The context suggests it competes with generic relm_get, but no exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_get_sequenceARead one drip sequence by id. view=sequence (default) returns it with its steps; view=enrollments lists who is enrolled and their state.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| view | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavior context about what each view returns, such as 'returns it with its steps' and 'lists who is enrolled and their state.' This goes beyond the schema while remaining consistent with the safety profile.
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 fluff. The first sentence states the primary purpose, and the second explains the view variations. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and good annotations, the description covers the purpose, views, and return highlights. Without an output schema, it provides enough context about what to expect from each view, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, so the description must compensate. It fully clarifies the 'view' parameter by explaining what each enum value does, and 'id' is implicitly explained as the sequence identifier. This is complete and 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 tool reads one drip sequence by ID, using the verb 'Read' and specifying the resource. It also distinguishes the two available views (default summary with steps vs. enrollments), which differentiates it from sibling tools like relm_list_sequences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you have a specific sequence ID and want to read it) and explains the behavior of the default vs. enrollments view. It does not explicitly name alternatives like relm_list_sequences, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_get_usageARead this workspace's current billing period: requests used, plan, monthly limit, and any metered overage. Call this to see how close you are to the quota before a big import.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns by saying 'Read'. It adds valuable context by specifying the returned information (requests used, plan, monthly limit, metered overage) and frames the tool as a quota check, which goes beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence is front-loaded with the essential action and returns, the second provides a practical use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool with no output schema, the description fully covers what it returns, when to use it, and its read-only nature. There are no gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly omits parameter details and instead clarifies the semantic scope ('this workspace's current billing period'), which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Read') and a clear resource ('this workspace's current billing period'), then enumerates the exact data components (requests used, plan, monthly limit, overage). This distinguishes it from sibling tools, none of which focus on usage/quota inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case: 'Call this to see how close you are to the quota before a big import.' This is clear context, though it doesn't explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_get_webhookARead one webhook by id. view=webhook (default) returns the subscription; view=deliveries returns recent delivery attempts (status, retries, dead-letter) to debug why an endpoint isn't receiving events.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| view | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive. The description adds behavioral context by explaining what each view returns: the subscription or delivery attempts with status, retries, and dead-letter details. This goes beyond the safety signals in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by view-specific details. Every word contributes; there is no extraneous information or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read-only tool, the description is complete: it covers both parameters, the default behavior, and the purpose of the alternative view. Even without an output schema, it gives sufficient return-value context for the agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for id or view, so the description carries that burden. It fully explains the view enum values, including the default ('webhook') and what each returns. The id parameter is self-explanatory from 'by id' in the description.
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 starts with 'Read one webhook by id,' clearly specifying the action (read) and the resource (webhook by id). It distinguishes from list-oriented tools like relm_list_webhooks by emphasizing 'one' and explaining the view parameter's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'view=deliveries ... to debug why an endpoint isn't receiving events.' While it doesn't explicitly name alternatives, the scoped read-by-id nature and debugging scenario guide the agent on when to use this tool versus broader list or management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_listAList records of an object with keyset pagination. Optional filters vary by object (e.g. contact: email/company_id/type; deal: pipeline/stage/company_id; activity: contact_id/deal_id/type).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| filter | No | object-specific filters | |
| object | Yes | Which core object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that it uses keyset pagination and that filters vary by object, which is useful context beyond the annotations. However, it does not disclose response format, limit/cursor semantics, or error handling, so the additional behavioral detail is limited.
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, consisting of two sentences. The first sentence front-loads the core purpose and pagination method, while the second provides brief, relevant examples. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested filter object and absence of an output schema, the description covers the main purpose, pagination, and filter examples, but omits details like response shape, default or maximum limit, cursor usage specifics, or behavior for invalid filter keys. It is adequate but has noticeable gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% with 'filter' described as 'object-specific filters' and no descriptions for 'limit' and 'cursor'. The description compensates by listing concrete filter keys for contact, deal, and activity, substantially clarifying the filter parameter. 'Keyset pagination' also implies the roles of limit and cursor, adding meaningful semantics 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 it lists records of an object with keyset pagination, using the verb 'list' and specifying the resource. It provides concrete filter examples for different objects, making the purpose specific. However, it does not explicitly differentiate from sibling tools like relm_get or relm_search, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for paginated listing with object-specific filters, and gives examples for contact, deal, and activity. It does not explicitly state when to choose this over relm_get or relm_search, nor does it mention any exclusions or preconditions, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_automationsBList reactive rules (automations).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description merely says 'List,' which reinforces the read-only nature but adds no additional behavioral context such as pagination, ordering, filtering, or return format. No added clarity beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence: 'List reactive rules (automations).' It is extremely concise, contains no filler, and every word conveys meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and a read-only hint, so the minimal description is adequate. However, it does not mention return format, pagination, or how it differs from other list tools, leaving some gaps for a 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 tool has zero parameters and an empty input schema. Since there are no parameters to describe, the baseline score of 4 is appropriate, and the description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with a specific resource 'reactive rules (automations),' making the purpose clear. However, it does not explicitly differentiate itself from sibling tools like relm_list or relm_get_automation, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as relm_list, relm_get_automation, or relm_manage_automation. The description lacks any context about exclusions, prerequisites, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_connectionsAList connected messaging channels (never returns the secret key).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds a valuable behavioral guarantee ('never returns the secret key') that goes beyond the annotations. No contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short clauses with the action verb front-loaded. Every word contributes meaning, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description is adequately complete. It states what is listed and includes a key security behavior; missing return-format details are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline of 4 applies. The description appropriately adds no parameter details since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('connected messaging channels'), clearly distinguishing it from sibling list tools like relm_list_pipelines and relm_list_webhooks. The additional note about never returning the secret key reinforces the tool's specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: to view connected messaging channels. It does not explicitly mention alternatives or when not to use it, but the purpose is unambiguous and sufficient for this simple read-only list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_pipelinesAList pipelines with their ordered stages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds minimal behavioral context beyond noting ordered stages, which is an output detail rather than a behavioral trait. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action and a key output characteristic (ordered stages).
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 low complexity (zero parameters, no output schema needed) and the presence of read-only annotations, the description is sufficient. It fully captures the tool's purpose and primary output detail, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing additional to explain. Per rubric, 0 parameters warrants a baseline score of 4. The description does not need to compensate for any undocumented 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 'List pipelines with their ordered stages' uses a specific verb and resource, clearly distinguishing it from sibling tools like relm_get_pipeline (retrieve a single pipeline) and relm_list_sequences. The addition of 'ordered stages' provides precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for listing pipelines, but provides no explicit guidance on when to use it versus alternatives such as relm_get_pipeline or relm_manage_pipeline. No exclusions or alternative-referencing are present, so usage is only implied by the name and verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_sequencesAList drip sequences with their steps and enrollment counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds the useful context that the output includes steps and enrollment counts, but it does not disclose any other behavioral traits like pagination, ordering, 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?
The description is a single concise sentence that immediately states the tool's function. Every word adds value, making it easy to parse and free of any redundant 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?
For a read-only, zero-parameter list tool, the description covers the core purpose and returned data. However, it lacks any mention of possible filters, ordering, or whether active sequences only are returned, which could be relevant for an agent deciding between this and related sequence tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so the baseline is 4. The description appropriately focuses on the tool's output rather than parameters, and there is nothing to contradict or clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the exact resource 'drip sequences' with the included details 'steps and enrollment counts.' This clearly differentiates it from sibling list tools like relm_list_automations 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?
The description states what the tool does but does not explicitly say when to prefer it over related tools such as relm_list or relm_get_sequence. No alternatives or exclusions are mentioned, leaving the agent to infer usage from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_templatesAList reusable email templates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no extra behavioral context, such as result set limits, pagination, or what 'reusable' implies. It merely restates the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word earns its place; there is no wasted text or unnecessary elaboration.
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 0-parameter list tool with good annotations, the description is largely sufficient. However, it does not mention the return format or any constraints on which templates are returned, which could slightly benefit 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?
The tool has zero parameters and the schema coverage is trivially 100%. With no parameters to document, the baseline of 4 applies and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('reusable email templates'), clearly distinguishing it from sibling tools like relm_list_sequences or the generic relm_list. It precisely states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as relm_list or other list-specific tools. The description only states the action, leaving the agent to infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_list_webhooksAList webhook subscriptions in this workspace/mode.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read behavior is covered. The description adds the workspace/mode scoping but does not mention pagination, ordering, or response structure. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. It is concise, front-loaded with the verb and resource, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations covering the safety profile, the description is sufficient for an agent to understand what this tool does. The workspace/mode scoping adds useful context for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers the input contract. Per the rubric, a baseline of 4 applies; the description adds no parameter-specific detail, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'List' clearly indicates the read operation, and 'webhook subscriptions' specifies the resource. Adding 'in this workspace/mode' scopes the list, distinguishing it from single-webhook retrieval tools like relm_get_webhook.
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 minimal context about scope but does not explicitly state when to use this tool versus alternatives such as relm_get_webhook or the generic relm_list. It is implied from the name and sibling context, but 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.
relm_log_activityAInspectLog an activity (note/call/email/meeting/task) on a contact and/or deal. Convenience wrapper over create activity.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | ||
| type | No | ||
| deal_id | No | ||
| contact_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the convenience-wrapper relationship to create activity but does not disclose detailed side effects, permissions, or return behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of about 17 words. It front-loads the core purpose and packs in the activity types, target objects, and wrapper relationship without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four optional string parameters and no output schema, this description provides sufficient context for selection and basic invocation. It could be more explicit about parameter defaults or required combinations, but the current level is adequate and not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by mapping type to the allowed values (note/call/email/meeting/task) and associating deal_id/contact_id with deal/contact. It does not explicitly define body, though that is largely self-evident from the context of logging an activity.
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 specific action 'Log an activity' and enumerates the activity types (note/call/email/meeting/task) and targets (contact/deal). It distinguishes itself from siblings by noting it is a 'convenience wrapper over create activity,' setting it apart from generic create or update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context by framing the tool as a convenience wrapper for logging activities, implying it should be used instead of lower-level activity creation. However, it does not explicitly name sibling alternatives or provide when-not-to-use guidance, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_manage_automationAChange an existing automation by id. action=disable stops it firing (use this to turn off a misbehaving rule); action=enable resumes it; action=delete removes it. To read one, use relm_get_automation. To change a rule's trigger/conditions/actions, delete and recreate.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the behavior of each action: disable stops firing, enable resumes, delete removes. It also notes the limitation that changing trigger/conditions/actions requires delete/recreate. Annotations already mark destructiveHint and readOnlyHint, but the description adds concrete behavioral context about what the actions do, going beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: primary action, specific action semantics, and alternative guidance. It is front-loaded with the main verb and resource, and there is no wasted phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers purpose, each action's meaning, alternative tools, and a key limitation. It gives the agent everything needed to invoke the tool correctly and avoid misuse. The guidance about delete/recreate also prevents the agent from attempting unsupported modifications.
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 the schema having 0% description coverage, the description fully explains parameter semantics. It maps each action enum value to its effect, and clarifies that 'id' refers to an existing automation. The description compensates entirely for the lack of schema-level parameter 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 the tool's purpose: 'Change an existing automation by id.' It enumerates the three specific actions (enable, disable, delete) with their effects, distinguishing it from sibling tools like relm_get_automation (read) and relm_create_automation (create). The verb 'change' plus the resource 'automation' and the action list make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'To read one, use relm_get_automation' and 'To change a rule's trigger/conditions/actions, delete and recreate.' It also gives a specific scenario: 'use this to turn off a misbehaving rule.' This clearly tells when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_manage_pipelineAChange an existing pipeline by key or pl_ id. action=rename changes its display name and/or its key (pass new_key) - deals link by internal id, so they follow a re-key automatically; action=set_default makes it the workspace default; action=delete removes it (fails if deals still use it - move them first). To read one, use relm_get_pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New display name | |
| action | Yes | ||
| new_key | No | New pipeline key (slugified); deals follow automatically | |
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag mutation and destructiveness, and the description adds critical behavior beyond that: deals follow re-key via internal id, delete fails when deals still reference the pipeline, and the display name vs key distinction. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with front-loaded purpose; every clause contributes an action, parameter meaning, or constraint. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description covers all actions, parameter formats, a key failure condition, and a cross-tool pointer. For a mutation tool this is sufficient for safe selection and 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 covers only name and new_key descriptions, leaving pipeline and action open; the description compensates by defining pipeline as key or pl_ id and fully explaining each action enum value. It also clarifies relationship behavior (deals follow automatically) beyond schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with 'Change an existing pipeline by key or pl_ id,' a specific verb and resource. It then enumerates three distinct actions (rename, set_default, delete), clearly distinguishing this tool from sibling creation/read 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?
Explicitly directs read use to relm_get_pipeline, naming an alternative. It also gives conditional guidance for delete ('fails if deals still use it - move them first') and explains rename semantics, so an agent knows when and how to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_manage_sequenceAChange an existing drip sequence by id. action=disable stops further sends (use this to halt a bad sequence); action=enable resumes; action=delete removes it. To read one or list its enrollments, use relm_get_sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true. The description adds valuable context beyond that by explaining exactly what each action does: disable 'stops further sends', enable 'resumes', delete 'removes it'. However, it does not elaborate on whether delete is permanent or what happens on success, though destructiveHint covers the destructive nature.
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-loaded with the core purpose, then a compact list of action semantics, and a final pointer to the read alternative. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema) and the strong annotations, the description is complete. It explains what the tool does, the meaning of each action, and when to use a sibling tool instead. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility. It clarifies each enum value for 'action' (disable, enable, delete) with concrete effects, and 'by id' implies the 'id' parameter is the sequence identifier. This fully compensates for the empty 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?
Description states a specific action on a specific resource: 'Change an existing drip sequence by id.' It then enumerates the three concrete actions (disable, enable, delete), and explicitly distinguishes from the sibling read tool by saying 'To read one or list its enrollments, use relm_get_sequence.'
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 when-to-use guidance: 'disable stops further sends (use this to halt a bad sequence); enable resumes; delete removes it.' It also names the alternative for reading (relm_get_sequence), so the agent knows not to use this tool for read-only operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_manage_stageAAdd, rename/retype, delete, or reorder stages in a pipeline. action=add: key (+optional label, ordinal, type). action=rename: key (existing) + any of new_key / label / type - keys are slugified and deals follow automatically (fixes a typo'd key). action=delete: key (a stage in use by deals cannot be deleted). action=reorder: order = every existing stage key exactly once, in the new order. type is the semantic stage type: open | won | lost - so 'is this deal won?' is a flag (stage_type on every deal), not per-pipeline string matching.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| type | No | ||
| label | No | ||
| order | No | ||
| action | Yes | ||
| new_key | No | ||
| ordinal | No | ||
| pipeline | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses important behaviors: keys are slugified, deals follow renames automatically, and the 'type' parameter is a semantic flag stored on every deal rather than a per-pipeline string. These details add significant context about side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-packed, with each sentence serving a purpose. It uses action= prefixes to structure the content, but the single-paragraph format could be improved with bullets for readability. Still, it avoids fluff and front-loads the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters, no output schema, and destructive annotations, the description is remarkably complete. It covers all four actions, their required inputs, constraints, type semantics, and the side effect of renaming (deals follow). This is sufficient for an agent to correctly select and invoke the 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?
With 0% schema description coverage, the description compensates by explaining most parameters in context: 'key' for add/rename/delete, 'new_key' for rename, 'order' for reorder, and 'type' with its enum values. However, the required 'pipeline' parameter is not explicitly described, and 'ordinal' is only mentioned as optional without full semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add, rename/retype, delete, or reorder stages in a pipeline.' It uses specific verbs and identifies the resource (stages) and scope (pipeline), distinguishing it from sibling tools like relm_manage_pipeline which handle pipeline-level settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context for each action (add, rename, delete, reorder), including required parameters and constraints like 'a stage in use by deals cannot be deleted.' However, it does not explicitly name alternative tools or state when to use this tool instead of them, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_manage_webhookAPause or resume delivery for an existing webhook by id. action=enable/disable. To read one or inspect its delivery attempts, use relm_get_webhook. To remove it, use relm_delete_webhook.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate that the operation is not read-only, not destructive, and is idempotent. The description adds that the tool specifically toggles delivery, which is a meaningful behavioral detail. It does not contradict the annotations, and it clarifies that the webhook itself is not removed or modified beyond delivery state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, with the primary purpose front-loaded and zero filler. The subsequent sentences give pointed guidance on alternatives, making every sentence valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core behavior and alternative tools. It could mention what the operation returns or effect on pending events, but the annotations and simplicity keep the gap small. Overall, it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions, so the description compensates by explaining 'action=enable/disable' and referring to 'by id.' This maps the action enum to 'pause or resume' and clarifies that the id refers to an existing webhook. This adds significant semantic value beyond the raw 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's purpose: 'Pause or resume delivery for an existing webhook by id.' This is a specific verb-action on a resource, and it distinguishes from sibling tools by explicitly mentioning get and delete alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use alternatives: 'To read one or inspect its delivery attempts, use relm_get_webhook. To remove it, use relm_delete_webhook.' This clearly separates the use case from get and delete operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_preview_sequenceADry-run a sequence: how many contacts would enroll now + the send schedule. No side effects.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint=false. The description adds specific behavioral context about what the dry run computes (enrollment count and schedule), which is not present in annotations, enhancing transparency beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and outcome, with zero redundant words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is reasonably complete. It states purpose, output, and side effects. It could mention what 'id' refers to or any assumptions, but the core behavior is adequately covered.
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 shows only an 'id' (string), and schema description coverage is 0%. The description does not explain the meaning of 'id' (likely the sequence ID) nor any constraints or format. It relies on the tool name and implicit context, which is insufficient given zero coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Dry-run a sequence') and the resource ('sequence'), and details the output ('how many contacts would enroll now + the send schedule'). It distinguishes itself from siblings like relm_enroll (actual enrollment) and relm_get_sequence (retrieve existing sequence).
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 as a safe pre-check before actual enrollment by emphasizing 'No side effects.' It provides clear context for when to use the tool but does not explicitly name alternatives or exclusion criteria, though the dry-run nature is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_restoreARestore a soft-deleted record.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| object | Yes | Which core object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the 'soft-deleted' qualifier, which clarifies the target state beyond the annotation title. Since annotations already indicate idempotency and non-destructiveness, the description's extra context is modest but valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that communicates the tool's purpose without waste. It is appropriately concise for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with robust annotations, the one-sentence description provides sufficient context to select and invoke it, though it omits nuances like how soft-deletion is represented or potential error conditions. The presence of sibling relm_delete gives enough context for a user to infer when restore is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; the description does not elaborate on the `id` parameter or clarify how `object` maps to available record types beyond the enum. The meaning of `id` is left implicit, so the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (restore) and the target (soft-deleted record), using a specific verb and resource. It distinguishes itself from relm_delete, relm_get, and relm_update siblings by focusing on the soft-deleted state.
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 a previously soft-deleted record should be made active again, but it does not explicitly contrast with relm_delete or note when not to use it. There is no exclusion guidance for records that were permanently deleted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_searchACross-entity search over contacts, companies and deals by name/email/title.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the cross-entity scope and search fields, but does not disclose behaviors like pagination, result limits, or fuzzy matching. With annotations present, the added context is modest but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It clearly states what the tool does in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple search operation with annotations covering safety, but the description omits details about result structure, pagination, or default limit behavior. Since there is no output schema, the description should clarify the return format, but it does not. It is adequate for a minimal search tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that 'query' can target name/email/title, but it does not explain the 'limit' parameter at all. The description adds some meaning to one parameter but leaves the other ambiguous for agents.
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 performs cross-entity search across contacts, companies, and deals by name/email/title. This specific verb+resource+scope distinguishes it from siblings like relm_get, relm_list, and relm_create.
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 searching across multiple entity types by name/email/title, but does not explicitly state when not to use it or mention alternatives. It gives clear context but no exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_set_spend_capASet (or clear) the hard monthly overage spend cap in USD. overage_cap_usd: a number caps paid overage (requests 429 with spend_cap_reached past it), 0 = never any overage, null = unlimited. This is the recovery for a spend_cap_reached error.
| Name | Required | Description | Default |
|---|---|---|---|
| overage_cap_usd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only indicate idempotency and non-destructiveness), the description explains the behavioral effects of each parameter value: caps paid overage, triggers 429 responses, 0 means no overage, and null means unlimited. This adds meaningful context that annotations do not provide.
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 deliver the core action, parameter semantics, and usage context with zero filler. The information is front-loaded and every clause 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 simple one-parameter tool with no output schema, the description covers purpose, parameter semantics, and the specific error scenario. It is complete for the tool's intended use.
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 carries the full burden for parameter meaning. It thoroughly defines overage_cap_usd, including the meanings of a number, 0, and null, adding value that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set (or clear)') and resource ('hard monthly overage spend cap in USD'), and further distinguishes the tool by describing the error recovery context. This differentiates it clearly from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by identifying this as 'the recovery for a spend_cap_reached error', which tells the agent when to use the tool. No explicit exclusions or alternatives are mentioned, but the guidance is sufficient for this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relm_updateAPatch a record. Pass if_match (the record's current version) for optimistic concurrency; a 412 means re-fetch and retry.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| patch | Yes | ||
| object | Yes | Which core object. | |
| if_match | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is non-read-only, non-destructive, and idempotent. The description adds valuable context about the if_match parameter and 412 retry flow, which goes beyond the annotation metadata. It does not contradict annotations and discloses the key concurrency behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and the concurrency detail earns its place. Every word contributes to understanding the tool's behavior, with no redundancy or fluff.
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 patch operation without an output schema, the description covers the main behavioral nuance (optimistic concurrency) and error handling (412). It does not explicitly state whether patch is a partial merge or what the response contains, but given the tool's straightforward scope, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 1 of 4 parameters (object) has a schema description, and schema coverage is low (25%). The description adds meaning for if_match (current version, concurrency control) but does not explain id or patch fields. While 'patch' implies an update payload, parameter meaning is only partially compensated for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Patch a record,' which combines a specific verb and resource, making the core purpose immediately clear. It distinguishes from sibling tools like relm_create and relm_delete by using 'patch' terminology, and the concurrency note adds specificity without obscuring the primary 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 clear operational guidance on optimistic concurrency (pass if_match, handle 412) but does not explicitly state when to use this tool versus alternatives like relm_create, relm_manage_*, or relm_restore. The usage context is implied from the 'patch' semantics rather than explicitly framed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!