Read AiSensy contacts, templates and campaigns; add contacts, send WhatsApp messages on approval.
Scored across 16 tools
Most tools map to a distinct resource+action, and the descriptions explicitly separate the tricky pairs (get_contact by id vs find_contact by phone, list_api_campaigns vs list_campaigns, get_campaign_analytics vs list_campaign_audience). The one genuinely blurry overlap is send_message vs send_campaign_message, since both deliver a WhatsApp template to a number; they are differentiated only by campaign binding, which an agent could easily misselect.
All 16 tools share a uniform aisensy_ prefix with snake_case verb_noun naming (create_/get_/list_/update_/send_). The only deviation is find_contact, which uses a different verb from the otherwise dominant get_ for single-record retrieval, though that difference is deliberate and documented.
16 tools is on the heavier side but each one covers a real resource (project, contacts, templates, campaigns, messages, audience, analytics) with almost no redundancy. Nothing looks like filler, and splitting reads into list/get pairs is justified by the different parameter shapes (phone lookup, cursor paging, date filters).
Coverage of the read side is strong and sending has proper confirmation semantics, but there are meaningful gaps: no tool to move a created API campaign to LIVE (yet sending requires a LIVE campaign), no delete for contacts or campaigns, no way to list a project's messages despite aisensy_get_message, and no template creation. These create dead ends for campaign lifecycle and message auditing workflows.
WRITE: create an API campaign that binds a name to an APPROVED WhatsApp template. It sends nothing; messages go out only when aisensy_send_campaign_message is called for it. Not idempotent: calling twice with the same name may create two campaigns or fail. POST /project/{project_id}/campaign/api.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_name | Yes | Name of the new campaign. | |
| template_name | Yes | Exact name of an APPROVED template (see aisensy_list_templates). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real context beyond the annotations: the exact consequence of non-idempotency ('may create two campaigns or fail') rather than just idempotentHint=false, plus the side-effect boundary that nothing is sent and the underlying POST endpoint. It stops short of stating auth/permission requirements or rate limits, which is the only remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with the 'WRITE:' operation class, and each one carries distinct information — purpose, effect boundary, idempotency risk, endpoint. 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 two-parameter create call with full schema coverage and annotations declaring mutation/non-idempotency, the description covers purpose, side effects, and failure mode. With no output schema, it doesn't say whether the response returns an identifier needed to later call aisensy_send_campaign_message, a minor but real chaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already tells the agent that template_name must be an APPROVED template and points at aisensy_list_templates. The description reinforces the name-to-template binding but adds no format, constraint, or validation detail beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb + resource ('create an API campaign') with the resource's semantics spelled out: it binds a name to an APPROVED WhatsApp template. It also disambiguates from the sibling that actually delivers messages by naming aisensy_send_campaign_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the boundary condition: 'It sends nothing; messages go out only when aisensy_send_campaign_message is called for it,' which tells an agent both when to call this tool and which sibling to call afterward. It also names aisensy_list_templates as the prerequisite lookup for the APPROVED template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: add a contact (name and phone number with country code). AiSensy opts new contacts in to WhatsApp notifications automatically, so only add people who agreed to be messaged. A number that already exists returns a 409 conflict. POST /project/{project_id}/contact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| phone_number | Yes | Phone number with country code, e.g. 919876543210 (digits; a leading + is dropped). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the generic write profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true); the description adds genuinely new behavior — contacts are auto opted-in to WhatsApp notifications, and duplicate numbers return a 409 conflict. The consent warning flags a real, non-obvious side effect an agent would otherwise miss.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the WRITE marker and the core action, then compliance caveat, then the error contract. Every sentence carries unique information; the trailing endpoint path is the only borderline item and it usefully anchors the call.
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 2-param, non-destructive write with no output schema, the description covers action, side effects, and the duplicate-error path. It does not describe the success payload (contact ID and what fields come back), which matters since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: phone_number already documents the country-code format and + handling in the schema, so the description merely restates it. The name parameter's constraints (1–200 chars) are covered by the schema but not explained in prose, so the description adds little semantic value beyond structured fields — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with an explicit verb+resource+mode ('WRITE: add a contact'), which cleanly separates it from the read siblings (find_contact, get_contact) and from update_contact. It never names a sibling or states an exclusion, so it stops just short of the top mark.
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?
Gives a concrete precondition ('only add people who agreed to be messaged') and warns that duplicates yield a 409, which implies checking existence first. It does not explicitly route the agent to find_contact/get_contact or tell it to switch to update_contact for existing numbers, so the guidance is contextual rather than prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a contact by phone number: id, name, tags, attributes, opt-in/chat state and last activity. 404 means no such contact. GET /project/{project_id}/contact?action=FetchContact&mobile_number=.
| Name | Required | Description | Default |
|---|---|---|---|
| phone_number | Yes | Phone number with country code, e.g. 919876543210 (digits; a leading + is dropped). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral information not captured in the schema or annotations, specifically detailing the fields returned (e.g., opt-in/chat state) and the specific error code mapping (404 means no contact found).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and highly efficient. It includes the key functional definition, the result set, and the error condition in two clear statements.
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 description is complete for the agent. By listing the specific fields and the 404 error behavior, the agent knows exactly what to expect from the tool's execution even without a formal output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the parameter semantics are well-covered structurally. The description adds no semantic value beyond what the schema already provides for the 'phone_number' field, matching the baseline for high 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 purpose is stated immediately and clearly: 'Look up a contact by phone number.' It specifies the resource (contact) and the action (lookup), distinguishing it from siblings like get_contact which implies a different search key.
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 specifies exactly what information the agent receives (id, tags, attributes, etc.), indicating when this tool should be preferred over a basic lookup. While it doesn't explicitly name alternatives, the scope of returned data provides strong usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One API campaign by id: status, template, parameters and counts. GET /project/{project_id}/campaign/api/{campaign_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds value by enumerating what the response contains (status, template, parameters, counts) and the underlying endpoint, but says nothing about not-found handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the selector and the returned fields come first. The second sentence is a bare endpoint path, which is the only mildly wasteful element.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so listing the returned fields is necessary and present. However, the description does not clarify how API campaigns differ from the regular campaigns exposed by sibling tools, nor what happens when the id is unknown, leaving a small but real gap for a lookup 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 100% and the single campaign_id parameter is documented as an AiSensy record id with a format pattern. The description's "by id" phrasing repeats that without adding format or sourcing detail, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one API campaign) and the selector (by id), which distinguishes it from aisensy_list_api_campaigns at a glance. It is slightly less crisp than a full verb+scope statement, but the read intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"One API campaign by id" implies the single-record fetch versus the list sibling, but the description never names aisensy_list_api_campaigns or says when to prefer one over the other. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily delivery and credit-usage statistics of one campaign (sent, delivered, read, failed counts and message credit usage), optionally within a date range. POST /project/{project_id}/campaign/analytics/{campaign_id} (a read: it only queries).
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, yyyy-mm-dd. | |
| start_date | No | First day, yyyy-mm-dd. | |
| campaign_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context by clarifying that the POST endpoint is actually a read-only query, which complements the readOnlyHint annotation. It still omits operational details such as default date-range behavior, error handling, authentication needs, and pagination or response shape, so the behavioral disclosure remains moderate.
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 tightly written sentences with the core purpose front-loaded. The endpoint parenthetical is compact and helps resolve the POST-versus-read ambiguity without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter read-only analytics tool with full schema coverage and annotations, the description gives enough context to invoke it correctly and understand the returned metrics. It could be stronger by stating what happens when the date range is omitted, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents campaign_id, start_date, and end_date semantics. The description reinforces that the date range is optional and tied to one campaign, but adds no format or constraint details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and metric set: daily delivery and credit-usage statistics for one campaign, including sent, delivered, read, failed counts, and credit usage. It is clearly more specific than the tool name alone, though it does not explicitly contrast the tool with siblings such as get_api_campaign or list_campaigns.
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 optional date range is mentioned, implying the tool can be used for campaign analytics over a period. However, there is no explicit guidance on when to use this versus campaign detail or campaign listing tools, and no stated prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One contact by id: name, phone number, tags, attributes, chat state and last activity. GET /project/{project_id}/contact/{contact_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly=true, non-destructive, open-world, so the safety story is covered. The description adds value beyond annotations by disclosing the shape of the return (name, phone, tags, attributes, chat state, last activity), which matters because there is no output schema; it omits failure behavior for a missing/invalid id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded fragments with zero filler; the returned-field list earns its place given no output schema. The trailing raw endpoint ('GET /project/{project_id}/contact/{contact_id}') is marginal for an agent and slightly dilutes an otherwise tight definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full schema coverage and annotations, the description supplies the one thing structured data lacks — what comes back — and identifies the resource uniquely. Nothing essential to invoking it correctly 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?
There is a single parameter with 100% schema description coverage, including a pattern and an origin hint ('as returned by the list tools'), so the schema does the heavy lifting. The description only restates 'by id' and adds no format, source, or lookup guidance beyond it — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('One contact by id') and enumerates the returned fields, which is more than a restatement of the title. It does not explicitly contrast with the sibling aisensy_find_contact, so the agent must infer that 'by id' vs 'search' is the dividing line.
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 'One contact by id' implies lookup-by-identifier usage, but the description never says when to use it instead of aisensy_find_contact or aisensy_list_campaign_audience, nor does it state prerequisites such as needing a valid id from a list tool (that hint lives only in the schema).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One WhatsApp message by id: status (SENT, DELIVERED, READ), sent/delivered/read times, sender, campaign, content and price. GET /project/{project_id}/messages/{message_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds useful context by enumerating returned fields and the underlying endpoint, but does not disclose error behavior, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the resource and return fields, then appends the endpoint. No sentence is wasted.
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-by-id tool with full schema coverage, annotations covering safety, and no output schema, the description is largely complete because it enumerates returned fields. Minor gaps remain around not-found/error behavior, but nothing essential 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 coverage is 100% and the single parameter is fully documented in the schema. The description adds only the phrase 'by id', which reinforces the schema rather than adding new syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (one WhatsApp message) and the lookup key (id), and lists the exact fields returned, which clearly separates it from list-style siblings. It does not explicitly name an alternative tool or verb, but the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use when a message_id is available, but gives no explicit when-to-use guidance, no alternatives for related lookups, and no conditions for choosing get_contact/get_campaign/etc. over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The AiSensy project (WhatsApp account) this key belongs to: name, status, plan and renewal date, monthly active user quota and usage, credit balance (raw units as AiSensy reports them), WhatsApp number, display name status, quality rating and messaging tier. GET /project/{project_id}.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is read-only and non-destructive. The description adds useful context beyond that: the project is scoped to the calling key, and credit balance is in raw AiSensy units, which matters for interpreting results. It still omits error or rate-limit behavior, so it is not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single dense sentence with the resource and scope front-loaded, and no wasted preamble. The long field list is justified because there is no output schema, though the trailing endpoint is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description supplies the key information an agent needs: the auth scoping, the returned project fields, and a caveat about raw credit units. Nothing essential for calling or interpreting this simple read 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?
There are zero parameters, so the baseline is 4. The description mentions the underlying /project/{project_id} path but does not introduce additional parameter semantics, and the key-bound wording implies the project is resolved from authentication rather than an argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact resource (the AiSensy project/WhatsApp account), its key-bound scope, and enumerates the metadata returned. It is clearly distinct from contact, campaign, message, and template siblings, though it relies on the trailing GET endpoint rather than an explicit 'returns' verb.
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 'this key belongs to' implies the tool is for fetching the current account/project context, and the field list signals the questions it answers. However, it never states when to call it versus the many other get/list tools, nor does it name any alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One WhatsApp template by id, with status, rejection reason, buttons and text. GET /project/{project_id}/wa_template/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| template_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior context by naming the response fields (status, rejection reason, buttons, text) and the underlying GET endpoint, but says nothing about not-found handling or errors.
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 compact sentences, zero filler, with the resource and returned fields front-loaded before the endpoint detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully compensates by enumerating return fields, and annotations cover the read-only nature. Only error/empty-result behavior is left unstated, which is a minor gap for a one-parameter lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single template_id parameter already documents its format and that ids come from the list tools. The description's 'by id' adds no syntax or provenance detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (one WhatsApp template) and the key (id), and enumerates the fields returned (status, rejection reason, buttons, text), which separates it from aisensy_list_templates. The verb is implied by 'One ... by id' rather than stated, so it stops just 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?
Usage is only implied: fetch details when you already hold a template_id. There is no explicit instruction to prefer aisensy_list_templates for discovery or any stated precondition/exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the project's API campaigns (the campaigns messages can be sent through) with status and template. A campaign must be LIVE to send. GET /project/{project_id}/campaign/api.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuine business context that annotations cannot convey: the result carries status and template, and only LIVE campaigns are sendable. It does not describe pagination, result size, or what statuses other than LIVE look like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose before the precondition and the endpoint. The trailing 'GET /project/{project_id}/campaign/api' is marginally useful for API-oriented agents but is the weakest sentence of the three.
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 0-parameter, non-destructive list tool with no output schema, the description supplies enough: what is listed, what fields come back (status, template), and the business rule that gates sending. Missing only return volume/pagination detail, which is minor here.
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 takes zero parameters, so there is no parameter semantics to explain; the schema is empty and fully described. Baseline for a 0-param tool is 4, and nothing in the description contradicts the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the project's API campaigns') and parenthetically defines what an API campaign is — one that messages can actually be sent through — which separates it from the general aisensy_list_campaigns. It never names that sibling outright, so the differentiation must be inferred from the parenthetical rather than being explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'A campaign must be LIVE to send' implies the usage context (call this to find a sendable campaign before send_campaign_message), but the connection is left implicit — no tool names an alternative or states when not to use this. The guidance is present but requires the agent to join the dots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who a campaign was sent to, with name, number and sent/delivered/read times, optionally filtered by outcome (SENT, DELIVERED, READ, FAILED, REPLIED, CLICKED) and date range. Pages by cursor: pass next_after from the previous reply as after. GET /project/{project_id}/campaign/audience/{campaign_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| after | No | Cursor from the previous reply's next_after. | |
| limit | No | Recipients per page, 1-1000 (default 20). | |
| category | No | Only recipients with this outcome. | |
| end_date | No | Latest day, yyyy-mm-dd. | |
| start_date | No | Earliest day, yyyy-mm-dd. | |
| campaign_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely useful behavior: the concrete return fields, the set of filterable outcomes, and the cursor loop ('pass next_after from the previous reply as after') plus the underlying endpoint. It does not mention rate limits or empty-result behavior, keeping it below a 5.
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 return content is front-loaded in the first clause, followed by filters, pagination mechanics and the endpoint — a logical order with little waste. The literal HTTP path is borderline noise for an agent but is defensible as operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and seven parameters, the description carries real weight and does supply returned fields, filter semantics and pagination. Gaps remain around total counts, empty audiences and error/expired-cursor handling, but nothing essential for a correct call 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 coverage is 86%, so the schema already documents after, limit, category and the date bounds; the baseline is 3. The description mostly restates the enum values and cursor usage already present in the schema descriptions, and says nothing about sort or how start_date/end_date interact, so it adds little beyond the structured fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (campaign audience) and the exact fields returned (name, number, sent/delivered/read times), which clearly separates it from analytics or campaign-listing siblings. It never uses an explicit verb like 'list', instead opening with 'Who a campaign was sent to', so it is one step short of the crispest possible statement.
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 explains the optional filters (outcome, date range) and the cursor-pagination workflow, which implies when the tool is useful. But it never routes the agent away from alternatives — there is no mention of when to prefer get_campaign_analytics or how this differs from list_campaigns, and no prerequisite/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List campaigns (API campaigns, broadcasts or both) with name, type, status, audience size, submitted count, template and creation time. Pages with skip + limit. POST /project/{project_id}/campaigns (a read: it only queries).
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Campaigns to skip (default 0). | |
| limit | No | Campaigns per page, 1-100 (default 20). | |
| campaign_type | No | Which campaigns (default ALL). |
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 phrase 'a read: it only queries' largely restates that. The genuinely additive piece is disclosing that the underlying call is 'POST /project/{project_id}/campaigns', which preempts an agent mistaking the POST endpoint for a write, plus pagination 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?
Front-loaded with the verb and returned field set, then pagination, then the endpoint note. Every sentence carries information, though '(a read: it only queries)' is mildly redundant given readOnlyHint=true.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and explaining pagination and type filtering — enough to call it correctly. Minor gap: no mention of sort order or total-count behavior, and no routing to the narrower sibling list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so a baseline of 3 applies; the description clears it slightly by grouping skip and limit as a pagination pair and flagging campaign_type as the type selector. It does not add bounds or defaults beyond the schema, but it does reinforce the intended combination of the two paging params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List campaigns') and enumerates the returned fields (name, type, status, audience size, submitted count, template, creation time), which makes the tool's output scope concrete. It also distinguishes filtering modes (API, broadcasts, or both). It stops short of naming the overlapping sibling aisensy_list_api_campaigns, so sibling differentiation is only implicit via campaign_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: campaign_type ALL/API/BROADCAST hints at when this tool covers the narrower list_api_campaigns case, and 'pages with skip + limit' implies list-scan scenarios. There is no explicit when-to-use or when-not guidance, and no mention of the alternative aisensy_get_campaign_analytics for per-campaign detail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the WhatsApp template messages of the project with name, language, status (PENDING, APPROVED, REJECTED), category, text and parameter count. Only APPROVED templates can be sent. Pages by record id: pass next_after from the previous reply as after. GET /project/{project_id}/wa_template/.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Return records after this template id (exclusive); use the previous reply's next_after. | |
| limit | No | Templates per page, 1-100 (default 10). | |
| before | No | Return records before this template id (exclusive). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered; the description adds genuine context on top: the status vocabulary (PENDING/APPROVED/REJECTED), the business rule that only APPROVED templates are sendable, and the cursor pagination model. It stops short of auth/permission or rate-limit details, and there is no output schema to describe.
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 tight sentences: what is returned, the status rule, then the pagination mechanic. Returned fields and the cursor rule are front-loaded with no repetition of the name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return shape and does so well by listing the per-template fields, plus it covers pagination continuation. It omits how paging terminates (absence of next_after) and any scope/permission notes, leaving minor gaps for an agent handling multi-page results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description earns an extra point by explaining the cursor interplay that the schema only partially states — 'pass next_after from the previous reply as `after`' — which is the key operational detail for paging. It says nothing extra about `limit` or `before`, both of which the schema already handles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (WhatsApp template messages of the project) and enumerates the fields returned (name, language, status, category, text, parameter count). It does not name a sibling such as aisensy_get_template to explicitly draw the list-vs-get boundary, so it falls short of the top band.
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 line 'Only APPROVED templates can be sent' hints at why an agent would list templates, and the pagination instruction gives procedural guidance. But there is no explicit when-to-use-this vs aisensy_get_template / aisensy_send_message and no exclusion or prerequisite statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE, SENDS A WHATSAPP MESSAGE TO A CUSTOMER AND SPENDS AISENSY CREDIT: send the template of a LIVE API campaign to one phone number (a new contact is created if the number is unknown). Not idempotent: every call sends again. template_params must match the template's parameter count. Show the user the recipient and the template first and set confirm=true only after they approve. POST /project/{project_id}/campaign/api/send.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Recipient's name. | |
| tags | No | Existing tags to put on the contact (unknown tags are ignored). | |
| source | No | Lead source label. | |
| confirm | Yes | Must be true. Set it only after the user has seen and approved the recipient and the message in this conversation. | |
| media_url | No | Public https URL of the image/video/document for a media template. | |
| attributes | No | Contact attributes as name → text value. AiSensy ignores attribute names that do not exist in the project. | |
| phone_number | Yes | Phone number with country code, e.g. 919876543210 (digits; a leading + is dropped). | |
| campaign_name | Yes | Name of a LIVE API campaign (see aisensy_list_api_campaigns). | |
| media_filename | No | File name shown for the media. | |
| template_params | No | Values for the template's {{1}}, {{2}}... in order; the count must match the template. | |
| default_country_code | No | Country code to assume when phone_number has none, e.g. 91. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantive behavior beyond the annotations: the call spends AiSensy credit, creates a new contact when the number is unknown, resends on every call, and requires a human approval gate before confirm=true. Those are the exact side effects an agent needs before firing a destructive, non-idempotent write.
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?
Front-loaded with the risk signal (WRITE, SPENDS CREDIT) before any detail, then a compact colon-separated chain of constraints and the endpoint. Every clause carries operational value; nothing is padding.
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 an 11-parameter destructive write with nested objects, it covers cost, idempotency, contact creation, and the approval gate. It says nothing about the response (no output schema exists) or media-template requirements, though the schema covers those parameter-level details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters including template_params ordering and confirm semantics. The description only restates the template_params count constraint and the confirmation workflow, adding little new parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('send the template of a LIVE API campaign to one phone number') and flags it as a write that costs credit. This clearly separates it from the generic sibling aisensy_send_message and from read tools like aisensy_list_api_campaigns.
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?
Gives explicit prerequisites: show the user the recipient and template first and set confirm=true only after approval, and points at aisensy_list_api_campaigns to find a LIVE campaign. It does not explicitly say when to prefer aisensy_send_message over this tool, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE, SENDS A WHATSAPP MESSAGE TO A CUSTOMER AND MAY SPEND AISENSY CREDIT: send either a free-text message (type=text; WhatsApp only delivers it inside the 24-hour window after the customer last wrote) or an approved template (type=template with template_name, language_code and body_params). Not idempotent. Show the user the recipient and the text first and set confirm=true only after they approve. POST /project/{project_id}/messages.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Message text (type=text). | |
| type | Yes | text = free-form reply; template = an approved template. | |
| confirm | Yes | Must be true. Set it only after the user has seen and approved the recipient and the message in this conversation. | |
| body_params | No | Values for the template's body {{1}}, {{2}}... in order (type=template). | |
| phone_number | Yes | Phone number with country code, e.g. 919876543210 (digits; a leading + is dropped). | |
| language_code | No | Template language code such as en, en_US, hi (type=template; default en). | |
| template_name | No | Approved template name (type=template). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing cost ('may spend aisensy credit'), the WhatsApp 24-hour delivery constraint that determines whether a send will even land, and a mandatory human-approval gate tied to confirm=true. Annotations already cover destructive/non-idempotent, so the description is adding genuinely new operational context rather than restating 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?
Front-loaded with the highest-stakes facts (WRITE, sends, may cost credit), then the mode branch, then the confirmation protocol. Dense but every clause carries decision-relevant information; nothing is padding.
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 destructive, credit-spending mutation with no output schema, the description covers cost, delivery preconditions, and the approval workflow, which are the things an agent must know before calling. It omits what a successful send returns (message id) and any failure/rate-limit behavior, leaving a modest gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds the conditional dependency between 'type' and the required companion fields (template_name, language_code, body_params), which the flat schema does not express. It doesn't add format detail for phone_number beyond the schema, so it sits just above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (send) and resource (WhatsApp message to a customer), then names the two mutually exclusive modes (free-text vs approved template) with the exact type value for each. An agent can distinguish this from campaign-sending siblings like aisensy_send_campaign_message purely from the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete when-to-use rule for each mode: free text only inside the 24-hour window after the customer last wrote, otherwise an approved template. It does not explicitly route away from the campaign-sending siblings, so the alternative-selection guidance is strong but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: change a contact's name, custom attributes, WhatsApp opt-in status or blocked status. Setting opted_in=false stops campaign messages to that person; blocked=true blocks them. Only the fields you pass change. PATCH /project/{project_id}/contact/{contact_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| blocked | No | Whether the contact is blocked. | |
| opted_in | No | Whether the contact accepts WhatsApp notifications. | |
| attributes | No | Contact attributes as name → text value. AiSensy ignores attribute names that do not exist in the project. | |
| contact_id | Yes | AiSensy record id (as returned by the list tools). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a write, destructive, open-world, idempotent operation. The description adds meaningful behavioral context: opted_in=false stops campaign messages and blocked=true blocks the contact, plus partial-update semantics. It does not mention permissions or reversibility, but it adds real value 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 front-loaded with 'WRITE:'. Every sentence contributes: fields changed, operational consequences, partial-update behavior, and the endpoint.
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 annotations and lack of an output schema, the description provides enough to invoke the tool correctly, including field effects and partial-update behavior. It could be more complete with permission requirements or expected return behavior, but those are minor gaps for this update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema already documents most parameters. The description still adds useful meaning by identifying the updatable fields and explaining the consequences of opted_in and blocked, while the endpoint clarifies contact_id usage. Nested attributes semantics are left mostly to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: change a contact's name, custom attributes, opt-in status, or blocked status. It also names the PATCH endpoint, making clear this is an update rather than create/get/find contact operations among its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates use for changing existing contacts and adds the important partial-update rule that only passed fields change. It does not explicitly contrast against alternatives like aisensy_get_contact or aisensy_create_contact, but the operation is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
aisensy_create_api_campaignaisensy_create_contactaisensy_find_contactaisensy_get_api_campaignaisensy_get_campaign_analyticsaisensy_get_contactaisensy_get_messageaisensy_get_projectaisensy_get_templateaisensy_list_api_campaignsaisensy_list_campaign_audienceaisensy_list_campaignsaisensy_list_templatesaisensy_send_campaign_messageaisensy_send_messageaisensy_update_contactManage Wati WhatsApp and Instagram contacts, chats, campaigns and templates, plus Astra AI agents.
Place calls, send WhatsApp messages, and read call records, contacts, leads and campaigns
WhatsApp CRM for AI agents: search contacts, read chats, manage the sales pipeline, send messages.
Send and schedule SMS and WhatsApp messages, manage contacts and templates, and track delivery.
Add one secure layer between your agents and this server.
