Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Respond.io MCP Server send a welcome message to contact id:12345"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server implementation for the Respond.io API, enabling seamless integration with AI assistants, automation tools, and Claude Desktop.
✅ Get, create, update, and delete contacts
✅ Create or update contact (upsert by identifier)
✅ Merge two contacts (primary + secondary)
✅ List contacts with filters and search
✅ Add and remove contact tags
✅ Update contact lifecycle stages
✅ List contact channels (e.g. WhatsApp, Facebook)
✅ Send messages (text, attachments, WhatsApp templates, emails)
✅ Retrieve message details and status
✅ List messages for a contact (with pagination)
✅ Support for multiple channel types
✅ Assign/unassign conversations to users
✅ Open and close conversations
✅ Add closing notes and summaries
✅ List users and get user by ID
✅ List, get, and create custom fields
✅ List channels and message templates (e.g. WhatsApp)
✅ List closing notes (for closing conversations)
✅ Create, update, and delete workspace tags
✅ Add internal comments to contacts
✅ Mention users in comments
✅ Can run as a local subprocess via stdio or as an HTTP server (/mcp endpoint)
✅ Health endpoint (/health) for monitoring and uptime checks
✅ CORS enabled for HTTP mode
Related MCP server: MCP WaliChat WhatsApp API Connector
Node.js 18+
npm / yarn / bun
Git
# Clone the repository
git clone https://github.com/respond-io/mcp-server.git
cd mcp-server
# Install dependencies (includes Respond.io SDK)
npm install
# Build the project
npm run buildThe project depends on @respond-io/typescript-sdk. See SETUP_GUIDE.md for full installation and configuration.
The server is configured using environment variables. Set them in your shell or deployment environment.
RESPONDIO_API_KEY: (Required) Your Respond.io API key.
RESPONDIO_BASE_URL: The base URL for the Respond.io API (defaults to https://api.respond.io/v2).
MCP_SERVER_MODE: The server mode, either stdio or http (defaults to stdio).
PORT: The port for HTTP mode (defaults to 3000).
You can use this server with Claude Desktop in either STDIO (local subprocess) or HTTP (hosted or local HTTP server) mode.
Configure Claude Desktop (For Development Purpose):
{
"command": "node",
"args": [
"/<Your Local Folder Path>/dist/index.js"
],
"env": {
"RESPONDIO_API_KEY": "your_api_key",
"MCP_SERVER_MODE": "stdio"
}
}Configure Claude Desktop (For Production Usage):
{
"command": "npx",
"args": [
"@respond-io/mcp-server"
],
"env": {
"RESPONDIO_API_KEY": "your_api_key",
"MCP_SERVER_MODE": "stdio"
}
}Launch Claude Desktop and add this MCP server.
The server will start as a subprocess and communicate over stdio.
Test: Try any MCP tool from Claude Desktop, e.g., get a contact or send a message.
Start the server in HTTP mode:
npm run start:httpor (if built):
export MCP_SERVER_MODE=http
node dist/index.jsConfigure Claude Desktop:
{
"command": "npx",
"args": [
"-y",
"mcp-remote",
"http://localhost:3000/mcp",
"--header",
"Authorization:${AUTH_HEADER}"
],
"env": {
"AUTH_HEADER": "Bearer your-token-here"
}
}Test HTTP health:
curl http://localhost:3000/health
# {"status":"ok"}Test HTTP MCP endpoint:
curl -X POST http://localhost:3000/mcp \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"list_tools","params":{}}'You should get a JSON list of available tools.
get_contact({ identifier: "id:12345" })
get_contact({ identifier: "email:user@example.com" })
get_contact({ identifier: "phone:+60123456789" })create_contact({
identifier: "phone:+60123456789",
firstName: "John",
lastName: "Doe",
email: "john.doe@example.com",
language: "en",
custom_fields: [
{ name: "Company", value: "Acme Corp" },
{ name: "Order Number", value: 12345 }
]
})list_contacts({
limit: 50,
search: "john@example.com",
timezone: "Asia/Kuala_Lumpur"
})add_contact_tags({
identifier: "id:12345",
tags: ["vip", "premium", "sales"]
})create_or_update_contact({
identifier: "email:user@example.com",
firstName: "John",
lastName: "Doe",
email: "user@example.com"
})merge_contacts({
primaryContactId: 1,
secondaryContactId: 2,
firstName: "Merged Name"
})list_contact_channels({ identifier: "id:12345", limit: 10 })update_contact_lifecycle({ identifier: "id:12345", stage: "Lead" })
// Clear lifecycle: stage: nullsend_message({
identifier: "id:12345",
channelId: null, // Use last interacted channel
messageType: "text",
text: "Hello! Thank you for contacting us."
})send_message({
identifier: "phone:+60123456789",
channelId: 5678,
messageType: "whatsapp_template",
templateName: "order_confirmation",
templateLanguage: "en"
})send_message({
identifier: "email:user@example.com",
channelId: 1234,
messageType: "email",
text: "Your order has been shipped!",
subject: "Order Shipment Notification"
})send_message({
identifier: "id:12345",
channelId: 5678,
messageType: "attachment",
attachmentUrl: "https://example.com/invoice.pdf",
attachmentType: "file"
})get_message({ identifier: "id:12345", messageId: 987654 })list_messages({
identifier: "id:12345",
limit: 20,
cursorId: undefined // optional, for pagination
})assign_conversation({
identifier: "id:12345",
assignee: "123"
})
assign_conversation({
identifier: "id:12345",
assignee: "agent@example.com"
})
assign_conversation({
identifier: "id:12345",
assignee: "null"
})update_conversation_status({
identifier: "id:12345",
status: "close",
category: "Resolved",
summary: "Customer issue resolved successfully"
})create_comment({
identifier: "id:12345",
text: "Customer requested a callback tomorrow at 2 PM"
})
// Mention a user
create_comment({
identifier: "id:12345",
text: "{{@user.456}} please follow up with this customer"
})list_users({ limit: 20 })get_user({ id: 123 })list_custom_fields({ limit: 10 })get_custom_field({ id: 1 })create_custom_field({
name: "Customer Tier",
slug: "customer_tier",
description: "Customer membership tier",
dataType: "list",
allowedValues: ["Bronze", "Silver", "Gold", "Platinum"]
})list_channels({ limit: 10 })list_closing_notes({ limit: 10 })list_templates({ channelId: 5678, limit: 10 })create_tag({
name: "VIP",
description: "VIP customers",
colorCode: "#FF5733"
})update_tag({
currentName: "VIP",
name: "Premium",
colorCode: "#FFD700"
})delete_tag({ name: "Old Tag" })The server exposes 28 MCP tools for contacts, messaging, conversations, comments, and workspace management.
Summary:
Contact (11): get_contact, create_contact, update_contact, delete_contact, list_contacts, add_contact_tags, remove_contact_tags, create_or_update_contact, merge_contacts, list_contact_channels, update_contact_lifecycle
Messaging (3): send_message, get_message, list_messages
Conversation (2): assign_conversation, update_conversation_status
Comment (1): create_comment
Workspace (11): list_users, get_user, list_custom_fields, get_custom_field, create_custom_field, list_channels, list_closing_notes, list_templates, create_tag, update_tag, delete_tag
Tool parameters are defined in the server’s tool schemas (see src/tools/). Response shapes, rate limits, and API behavior come from the Respond.io Developer API and the @respond-io/typescript-sdk used under the hood.
The project uses Jest for tests. Tests run against an in-memory MCP transport and mock the Respond.io API so no real API key is needed for unit tests.
# Run tests once
npm run test
# Run tests in watch mode
npm run test:watch
# Run tests with coverage
npm run test:coverageTests cover:
Server & list_tools: All 28 tools are exposed; each has name, description, and inputSchema; server name/version and capabilities are reported.
All 28 tools (with mocked API): contact, messaging, conversation, comment, and workspace tools.
Validation & error scenarios: Unknown tool name, missing required args, invalid enums, empty arrays where non-empty is required.
mcp-server/
├── src/
│ ├── index.ts # Main server implementation
│ ├── server.ts # MCP server factory
│ ├── middlewares/ # Express middlewares
│ ├── protocol/ # STDIO / HTTP protocol handlers
│ ├── utils/ # Utility functions (API client)
│ └── tools/ # Tool definitions
├── dist/ # Compiled JavaScript output
├── tests/ # Jest tests
├── .env.example # Environment variable template
├── README.md # Documentation
└── SETUP_GUIDE.md # Setup instructions# Run in development mode with auto-reload
npm run dev
# Build the project
npm run build
# Run linter
npm run lint
# Fix linting issues
npm run lint:fix
# Format code
npm run format
# Type check
npm run type-check✅ TypeScript - Full type safety
✅ ESLint - Code quality and consistency
✅ Prettier - Code formatting
✅ Strict Mode - TypeScript strict mode enabled
✅ Error Handling - Comprehensive error handling
✅ Modular Design - Clean separation of concerns
The Respond.io API has rate limits. The server handles rate limit errors and includes rate limit information in error responses:
Retry-After - Seconds until retry is allowed
X-RateLimit-Limit - Request limit for the endpoint
X-RateLimit-Remaining - Remaining requests
The server provides detailed error messages:
// API errors include status codes and messages
{
"error": "API Error 404: Contact not found"
}
// Network errors
{
"error": "Network Error: timeout of 30000ms exceeded"
}
// Validation errors
{
"error": "API Error 400: Validation error."
}Never commit API keys - Use environment variables
Use HTTPS - All API calls use secure connections
Validate input - All inputs are validated before API calls
Error sanitization - Sensitive information is not exposed in errors
Contributions are welcome! Please follow these guidelines:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
Follow TypeScript best practices
Use meaningful variable and function names
Add comments for complex logic
Ensure all tests pass
Run linter before committing
Check that your API key is correct in .env
Ensure the API key has the necessary permissions
Verify the contact identifier format (id:123, email:user@example.com, phone:+60123456789)
Check that the contact exists in your workspace
Wait for the time specified in the Retry-After header
Consider implementing exponential backoff for retries
Run npm install to ensure all dependencies are installed
Delete node_modules and dist folders, then reinstall
Ensure you are using a supported TypeScript version (recommended: 5.3.x)
If you see warnings about any, use Record<string, unknown> or define explicit interfaces
Ensure the MCP server is running in HTTP mode (MCP_SERVER_MODE=http)
Check the correct port (PORT) is open and matches your configuration
Use curl http://localhost:3000/health to test
MIT License - see LICENSE file for details
For issues and questions:
GitHub Issues: [Create an issue]
Respond.io API Documentation: https://docs.respond.io
Respond.io Support: https://support.respond.io
Initial release
Full support for Contact, Messaging, Conversation, Comment, and Space APIs
Comprehensive error handling
TypeScript with strict mode
MCP SDK integration
HTTP and STDIO dual-mode support
Health endpoint for monitoring
Built with Model Context Protocol SDK
Powered by Respond.io API
Made with ❤️ for seamless customer engagement automation
Add tags to a contact.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | An array of tag names to add to the contact. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits. It does not mention whether tags are appended, overwritten, or any side effects, error scenarios, 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?
The description is a single sentence, which is concise. However, it lacks structured information like prerequisites or return values, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema, no annotations), the description is too minimal. It fails to explain what happens after tags are added, whether the contact must exist, or any potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear parameter descriptions for 'identifier' and 'tags'. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add tags to a contact' uses a clear verb+resource format, and it distinguishes from the sibling 'remove_contact_tags' implicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'remove_contact_tags' or 'update_contact'. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assign or unassign a conversation to a user.
| Name | Required | Description | Default |
|---|---|---|---|
| assignee | Yes | The user ID or email of the assignee. Set to null to unassign. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as whether previous assignments are overwritten, required permissions, or side effects. With no annotations provided, the description should compensate but does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters and no output schema, the description is minimal and does not explain return values or confirm the action's success. Lacks completeness for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds no additional meaning beyond the schema; it just restates the tool's purpose. The schema already explains that assignee can be null to unassign.
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: assign or unassign a conversation to a user. The verb 'assign' and resource 'conversation' are explicit, but it does not differentiate from similar tools like update_conversation_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_conversation_status. Missing context about prerequisites or whether the tool is for initial assignment or reassignment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a comment to a contact for internal reference.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The comment text. Max 1000 characters. To mention a user, use the format {{@user.ID}}. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral traits. It mentions 'internal reference' but does not specify visibility, notification triggers, or other side effects. The schema hint about mentioning users is a detail, but overall transparency is low.
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 is concise but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling tools and no output schema, the description is too sparse. It does not explain the return value, what happens on success, or how the comment relates to other entities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are well-documented in the schema. The description adds the 'internal reference' context but does not explain parameter details 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 adds a comment to a contact for internal reference. It uses a specific verb and resource, and distinguishes from sibling tools like create_contact or send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For instance, it doesn't clarify when to use add_comment vs send_message for contacting a user, or prerequisites like the contact existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new contact in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The contact's email address. | ||
| phone | No | The contact's phone number, including the country code (e.g., +60123456789). | |
| language | No | The contact's language code, based on the ISO 639-1 standard (e.g., 'en' for English, 'ms' for Malay). | |
| lastName | No | The last name of the contact. | |
| firstName | Yes | The first name of the contact. | |
| identifier | Yes | The contact's identifier, using their phone or email, formatted as 'email:user@example.com' or 'phone:+1234567890'. | |
| custom_fields | No | An array of custom field objects, each with a name and value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must fully disclose behavioral traits. It identifies the tool as a mutation ('Create') but does not mention any side effects, validation rules, duplication checks, or required permissions. The identifier format is described in the schema but not reiterated in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence that front-loads the key action and resource. However, the brevity sacrifices important contextual information that could be included without significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and a rich sibling tool set, the description is insufficient. It does not explain the special 'identifier' format, the optional nature of custom_fields, or constraints on email/phone. The output (response) is also not mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter semantics beyond what is already in the input schema, which is adequate but not improved upon.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new contact') and specifies the scope ('in the workspace'). It effectively distinguishes from sibling tools like 'delete_contact' and 'list_contacts', but does not differentiate from 'create_or_update_contact', which has overlapping functionality.
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 alternative tools such as 'create_or_update_contact' or 'update_contact'. The agent receives no context about prerequisites, failure scenarios, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new custom field.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the custom field (max 50 characters). | |
| slug | No | A unique identifier for the custom field (letters, numbers, and underscores only). | |
| dataType | Yes | The data type of the custom field. | |
| description | No | A description for the custom field. | |
| allowedValues | No | An array of allowed values, required for 'list' data types. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as side effects, required permissions, or response details beyond the basic creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could benefit from slightly more structure or 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 minimal description, the tool lacks completeness. It does not explain the return value, error states, or creation effects, making it insufficient for a new user.
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 adequately describes each parameter. The description adds no additional 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 'Create a new custom field' clearly states the verb and resource, and it distinguishes from sibling tools like 'list_custom_fields' or 'get_custom_field'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or exclusions mentioned. The user must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a contact if they do not exist, or update the existing contact. Uses the contact identifier to match.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The contact's email address. | ||
| phone | No | The contact's phone number, including the country code (e.g., +60123456789). | |
| language | No | The contact's language code, based on the ISO 639-1 standard (e.g., 'en' for English). | |
| lastName | No | The last name of the contact. | |
| firstName | Yes | The first name of the contact. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. | |
| custom_fields | No | An array of custom field objects, each with a name and value. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states upsert behavior but does not disclose whether fields not provided are preserved or overwritten, nor any idempotency, authentication, or response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant information. It is appropriately sized and front-loads the core action.
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 annotations, no output schema, and moderate complexity, the description is incomplete. It does not mention return values, partial update behavior, or any potential side effects, which are critical for an upsert 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?
Input schema has 100% description coverage, so baseline is 3. The description adds no extra meaning beyond schema, merely referencing '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 creates or updates a contact based on an identifier, distinguishing it from separate create and update tools. The verb 'create_or_update' and resource 'contact' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for upsert operations but does not explicitly compare to 'create_contact' or 'update_contact' siblings. It lacks guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a workspace tag (used to tag contacts or conversations).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The tag name. | |
| emoji | No | Optional emoji for the tag. | |
| colorCode | No | Optional hex color code for the tag (e.g. #FF5733). | |
| description | No | Optional description for the tag. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the action (create) but does not disclose any side effects, permissions, or restrictions. For a simple creation tool, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, highly concise, with the key information front-loaded. Every word is earned.
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 tool with 4 well-documented parameters and no output schema or annotations, the description covers the essential purpose. It could mention workspace scoping, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's 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 verb 'Create' and resource 'workspace tag', and specifies its usage ('used to tag contacts or conversations'), distinguishing it from sibling tools like delete_tag or update_tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to create a tag for tagging contacts or conversations), providing clear context. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a contact from the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action without disclosing whether the operation is irreversible, what data is affected (e.g., associated conversations or tags), or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence stating the core function. It is concise but could be more helpful without being wordy. 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 delete operation with no annotations or output schema, the description lacks critical context such as irreversibility, impact on related data, and authorization needs. It meets only the minimum to convey the basic action.
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 schema already describes the identifier parameter in detail (ID, email, or phone). The description adds no additional parameter information, meeting baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Delete) and resource (a contact from the workspace). It is distinct from sibling tools like create_contact, update_contact, etc., which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no mention of 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.
Delete a workspace tag by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The name of the tag to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. It states 'Delete' but does not disclose whether the operation is destructive, requires permissions, or has cascading effects on contacts. A delete tool should warn about reversibility or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate but lacks behavioral details for a deletion tool. It is complete enough for basic use but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning to the single parameter beyond what is already in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Delete) and resource (tag), clearly stating the action on a workspace tag. It effectively distinguishes from sibling tools like create_tag and update_tag.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions (e.g., tag not in use). However, the purpose is straightforward, so it scores at the minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about a specific contact by their ID, email, or phone number.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number, formatted as 'id:123', 'email:user@example.com', or 'phone:+1234567890'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It implies a read operation ('Retrieve information') but does not disclose error handling (e.g., what happens if identifier not found), authentication needs, 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?
The description is a single sentence that is front-loaded with the verb and object, containing no unnecessary words 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?
The description adequately explains the tool's purpose and parameter, but lacks information about the return value (what 'information' is returned), which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'identifier' parameter format. The description adds no extra meaning beyond repeating the schema; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'contact', and specifies the identifier options (ID, email, phone), distinguishing it from sibling tools like 'list_contacts' and 'create_contact'.
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?
While the purpose is clear (retrieve a specific contact), there is no explicit guidance on when to use this tool versus alternatives like 'list_contacts' or 'search_contacts', nor any mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a custom field by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The custom field ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states retrieval by ID, lacking details on what happens if the ID is invalid, whether the field is deleted, or any permission requirements. This is insufficient for a mutation-free read 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 a single, front-loaded sentence with no extraneous words. Every word is essential and serves the 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?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate for a basic retrieval operation. However, it fails to mention the return value or any edge-case behavior, leaving the agent with incomplete 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 schema has 100% coverage for the single parameter 'id' with a description. The tool description adds 'by its ID', which slightly reinforces the schema but does not provide additional meaning or context beyond what the schema already states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('custom field') with the identifier mechanism ('by its ID'). It is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'list_custom_fields', though the singular retrieval is implied.
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 'list_custom_fields' for multiple fields or 'create_custom_field' for creation. The description provides no context for appropriate usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a message by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| messageId | Yes | The ID of the message to retrieve. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'Retrieve' with no mention of side effects, authentication needs, rate limits, or whether the tool is read-only. This is insufficient for a mutational or sensitive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It clearly conveys the core purpose 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 is too minimal. It does not indicate what the tool returns (e.g., a message object), nor does it mention error conditions, pagination, or response format. Given the absence of an output schema, the description should provide hints about the return value.
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 parameter descriptions are already clear (e.g., messageId is 'The ID of the message to retrieve', identifier is 'The contact's identifier...'). The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the target resource ('a message'), and the retrieval criterion ('by its ID'). It distinguishes from siblings like 'send_message' (create) and 'list_messages' (multiple), as the ID implies a single, specific 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?
No guidance on when to use this tool versus alternatives (e.g., list_messages, get_contact). The description does not mention context, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a workspace user by their ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The user ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It correctly indicates the operation is a read (get), but does not disclose any behavioral traits such as permissions needed, rate limits, or what happens if the user does not exist. Minimal but accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, front-loaded with the core action and resource. Every word is informative.
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 1-parameter retrieval tool, the description is nearly complete. However, without an output schema, it would benefit from mentioning the return value type (e.g., 'returns the user object') for full 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 description coverage is 100% (single parameter with 'The user ID.'). The description adds no further semantic value beyond what the schema already provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' and resource 'user', and clarifies the scope by mentioning 'by their ID'. This clearly distinguishes it from sibling 'list_users' which retrieves multiple users.
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 user ID is available, but it does not explicitly state when to use this over alternatives like 'list_users' or provide any exclusion criteria. No guidance on prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all messaging channels connected in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of channels to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It claims to 'get all' but the schema shows pagination, which is not mentioned. There is no information about return format, authentication 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?
The description is very concise at one sentence (7 words), but it lacks necessary details. It is well-structured and front-loaded, but it could benefit from additional context without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's pagination and lack of output schema, the description is incomplete. It omits how to use pagination, what the response looks like, and any prerequisites. It fails to provide a complete picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. It does not explain how limit and cursorId affect results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get all messaging channels connected in the workspace.' The verb and resource are specific, and it distinguishes from siblings like list_contact_channels. However, it implies returning all channels at once, while the schema includes pagination, creating a slight 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 provides no guidance on when to use this tool versus alternatives like list_contact_channels or list_messages. There is no mention of context, prerequisites, or scenarios where another tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List closing note categories/options used when closing conversations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of closing notes to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool lists notes, but does not mention if it is read-only, pagination behavior, authentication requirements, or side effects. The agent cannot infer safety or 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 with no extraneous words. It follows the front-loading principle and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description is incomplete. It does not explain what the returned data looks like, pagination handling, or how this tool fits into the workflow of closing conversations. A list tool needs more context to be usable.
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%; both 'limit' and 'cursorId' have descriptions in the schema. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'closing note categories/options' used when closing conversations. The phrase 'categories/options' is slightly vague but distinguishable from sibling tools that list other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are no usage prerequisites, conditions, or related tools mentioned. The description does not help the agent decide between this and other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all messaging channels connected to a contact (e.g. WhatsApp, Facebook).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of channels to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action is listing, implying read-only, but omits details like pagination behavior, error handling for nonexistent contacts, or response format. This is insufficient for a tool with pagination parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and to the point, with no redundant words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return format or structure, but it does not. Pagination is implied by parameters but not explained. The description lacks completeness for a tool with three parameters and no return 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?
Schema coverage is 100% with clear parameter descriptions (e.g., 'identifier' can be ID, email, or phone). The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('messaging channels connected to a contact'), with concrete examples (e.g., WhatsApp, Facebook). It differentiates from siblings like 'list_channels' (which likely lists all channels) by specifying per-contact 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 implies use when needing channels for a specific contact, but provides no explicit guidance on when to use this tool vs. alternatives like 'list_channels' or 'send_message'. No when-not or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List contacts with optional filters and search.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of contacts to return, between 1 and 100. | |
| search | No | A search query to filter contacts. | |
| cursorId | No | The cursor ID for pagination. | |
| timezone | No | The timezone to use for the search (e.g., 'Asia/Kuala_Lumpur'). | UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic action and does not disclose that it is a read operation, any authentication needs, or pagination behavior beyond what is inferred from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using a single sentence with no redundant words. However, it sacrifices informative detail for brevity, which may limit its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters and no output schema, the description lacks completeness. It does not explain pagination through cursor and limit, the effect of timezone on search results, or the return format, leaving significant gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is defined. The description adds marginal value by mentioning 'optional filters and search', but does not explain the role of limit, cursorId, or timezone in context, leaving the agent to rely solely on 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 contacts with optional filters and search, which is a specific verb+resource. However, it does not differentiate this tool from sibling tools like list_contact_channels or get_contact, leaving ambiguity about 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?
No guidance on when to use this tool versus alternatives. The description does not mention scenarios, exclusions, or refer to sibling tools like get_contact for single contact retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of all custom fields in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of custom fields to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It says 'all custom fields' but doesn't disclose that limit restricts results or that pagination exists. Missing behavioral info like permissions or data freshness.
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, very concise. It could be slightly longer to add context, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and minimal description. For a simple list tool with 2 params, it is minimally adequate but lacks details on pagination, return format, or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'custom fields' with scope 'in the workspace', distinguishing it from siblings like get_custom_field (singular) and create_custom_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like get_custom_field. The usage is implied for listing all custom fields, but lacks context like when pagination is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List messages for a contact with optional pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of messages to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must stand alone. It only states that it lists messages with optional pagination, omitting behavioral details such as ordering, error handling, or whether it is read-only. The lack of transparency is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose. It is efficient, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and no output schema, the description covers the basics (resource, filtering by contact, pagination). However, it lacks details on response format, ordering, or edge cases, making it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions 'for a contact' (identifier) and 'optional pagination' (limit/cursorId), but these are already implied by the schema. No additional semantic meaning is added.
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 lists messages for a contact with optional pagination. It uses a specific verb (list) and resource (messages), and distinguishes from siblings like get_message and send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing messages per contact but provides no explicit guidance on when to use this tool versus alternatives like get_message or send_message. No when-not-to-use or context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List WhatsApp (or channel) message templates for a channel.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of templates to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. | |
| channelId | Yes | The channel ID to list templates for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'list', implying a read operation, but does not confirm it is non-destructive. It lacks details about pagination behavior, rate limits, or what happens if the channel does not exist.
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 extraneous words. It efficiently conveys the core 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?
The description does not explain the return value or pagination behavior, despite the presence of pagination parameters (limit, cursorId). For a list tool without an output schema, this omission leaves the agent uncertain about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with 100% coverage. The description adds no additional meaning or context beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'WhatsApp (or channel) message templates', and specifies the scope 'for a channel'. This distinguishes it from sibling tools like send_message or list_channels.
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. It does not mention any prerequisites, such as needing a valid channelId, or contrast with related operations like send_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a list of users in the workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of users to return, between 1 and 100. | |
| cursorId | No | The cursor ID for pagination. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions listing users but does not disclose behavioral traits such as pagination, sorting, or read-only nature, leaving gaps for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loading the purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks details on return format, default behavior, or sorting. For a list tool, additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so baseline is 3. The description adds no extra meaning beyond the schema, as it is generic.
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 'Get a list of users in the workspace' with a specific verb and resource, and it distinguishes from the sibling 'get_user' which returns a single user.
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 use when needing a list of users, but does not explicitly state when not to use it or mention alternatives like 'get_user' for a single user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Merge two contacts. The primary contact is kept; the secondary is merged into it. Optionally update fields on the primary.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Update the primary contact's email. | ||
| phone | No | Update the primary contact's phone. | |
| lastName | No | Update the primary contact's last name. | |
| firstName | No | Update the primary contact's first name. | |
| primaryContactId | Yes | The contact ID of the contact to keep (primary). Must be numeric ID. | |
| secondaryContactId | Yes | The contact ID of the contact to merge into the primary (secondary). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose all behavioral traits. It fails to specify whether the secondary contact is deleted after merging, nor does it mention any side effects (e.g., on conversations, tags, or lifecycle). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action. Every sentence adds value without redundancy. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should indicate the return value (e.g., the merged contact). It does not. Additionally, given sibling tools like update_contact, more context on when to merge vs update would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only restates that fields can be optionally updated, which is already clear from the schema's 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 'Merge two contacts' and explains that the primary is kept and secondary merged, with optional field updates. This distinguishes it from sibling tools like update_contact (single contact) and create_contact (new contact).
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 does not provide guidance on when to use merge vs. updating or deleting contacts. No explicit when-to-use or when-not-to-use information is given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove tags from a contact.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | An array of tag names to remove from the contact. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose any behavioral traits: no info on side effects, permissions, idempotency, error handling, or what happens if tags don't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words. It is front-loaded and immediately conveys the tool's 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?
Given the lack of output schema and annotations, the description is too minimal. It omits important context about return values, idempotency, and behavior in edge cases, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the existing parameter descriptions are sufficient. The tool description adds no additional context beyond what the schema provides, but it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove tags from a contact.' clearly states the action (remove) and resource (tags from a contact). It effectively distinguishes from sibling tools like add_contact_tags and delete_tag.
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 prerequisites, when not to use it, or which sibling tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to a contact through a specific channel.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The message text, required for 'text' and 'email' message types. | |
| subject | No | The email subject, required for 'email' message types. | |
| channelId | No | The channel ID to send the message from. If null, the last interacted channel will be used. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. | |
| messageType | Yes | The type of message to send. | |
| templateName | No | The name of the WhatsApp template, required for 'whatsapp_template' message types. | |
| attachmentUrl | No | The URL of the attachment, required for 'attachment' message types. | |
| attachmentType | No | The type of the attachment. | |
| templateLanguage | No | The language code of the WhatsApp template, e.g. 'en', 'en_US'. | |
| templateComponents | No | Dynamic components for the WhatsApp template. Use this to fill in variable values ({{1}}, {{2}}, etc.) in the template body, header, or buttons. Example: [{ type: 'body', parameters: [{ type: 'text', text: 'John' }, { type: 'text', text: 'ORDER-123' }] }]. Omit if the template has no dynamic variables. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the tool 'sends a message' without noting side effects like triggering notifications, cost implications, rate limits, or whether it is idempotent. The agent gains little insight into the tool's operational 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, clear sentence with no extraneous words. It is highly concise and efficiently communicates the tool's fundamental 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?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description is severely lacking. It does not explain return values, error handling, or prerequisites. The agent would need to infer or trial-and-error many 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?
The input schema has 100% description coverage, with each parameter already well-documented. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Send', the resource 'a message', the recipient 'to a contact', and delivery method 'through a specific channel'. It unequivocally identifies the tool's purpose and distinguishes it from sibling tools like list_messages and get_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?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites, limitations, or exclusions mentioned. The description does not help the agent decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing contact's information.
| Name | Required | Description | Default |
|---|---|---|---|
| No | The contact's new email address. | ||
| phone | No | The contact's new phone number. | |
| language | No | The contact's new language code. | |
| lastName | No | The contact's new last name. | |
| firstName | No | The contact's new first name. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. | |
| custom_fields | No | An array of custom fields to update. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden for behavioral disclosure. It only states the purpose, not side effects (e.g., whether missing contact causes an error), idempotency, or return value. The lack of output schema amplifies this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it is too terse for a tool with 7 parameters. It could include a brief list of typical use scenarios without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 7 parameters, the description is incomplete. It lacks information on return values, error handling, and whether updates are partial or full. Fails to provide adequate context for correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameters have descriptive comments. The description adds no extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing contact's information' clearly states the action (update) and resource (contact), distinguishing it from sibling tools like create_contact or get_contact. However, it could be more specific about which fields are affected, though the schema covers that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as create_or_update_contact or merge_contacts. There is no mention of prerequisites (e.g., contact must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a contact's lifecycle stage, or remove the lifecycle (pass stage as null or empty to clear).
| Name | Required | Description | Default |
|---|---|---|---|
| stage | Yes | The lifecycle stage name to set. Set to null or omit to remove the contact's lifecycle. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key behavior of clearing the lifecycle via null/empty, but does not mention error handling, permissions, or side effects. The hidden details are unknown.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is clear, front-loaded, and concise with no unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description is adequate. It explains the core functionality and edge case (clearing). Minor gap: no return value description, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds marginal value. It clarifies that passing null or empty clears the lifecycle, which is already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update', the resource 'contact's lifecycle stage', and the special behavior of removing the lifecycle by passing null or empty. This distinguishes it from sibling tools like update_contact or delete_contact.
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 updating or clearing lifecycle stages, but does not explicitly state when to use this tool versus alternatives like update_contact or when not to use it. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open or close a conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | The desired conversation status, either 'open' or 'close'. | |
| summary | No | A summary of the conversation, required when closing. | |
| category | No | The closing note category, required when closing a conversation. | |
| identifier | Yes | The contact's identifier. Can be the contact's ID, email, or phone number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It fails to disclose that summary and category are required when closing, nor does it mention side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, the description is insufficient. It omits critical details like the requirement of summary/category for closing and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema, merely restating that the tool opens or closes conversations, which is already clear from the status 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 clearly states the tool's function: opening or closing a conversation. It uses a specific action on a resource, distinguishing it from sibling tools like delete_contact or send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., assign_conversation). The description does not mention prerequisites or conditions such as the need for summary and category when closing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing workspace tag.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The new name for the tag. | |
| colorCode | No | Optional new hex color code (e.g. #FFD700). | |
| currentName | Yes | The current name of the tag to update. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It only says 'Update', but does not disclose any behavioral traits such as permissions, merging behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, directly conveying the core function.
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?
Description does not explain return values or side effects, but for a simple update tool with full schema coverage, it is minimally adequate. Missing context like whether tag must exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description adds no additional meaning beyond the schema, earning baseline score.
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 action ('Update') and resource ('existing workspace tag'), distinguishing it from siblings like 'create_tag' and 'delete_tag'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create_tag' or 'delete_tag'. Description is too minimal to inform decision.
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.
v3.0.0add_contact_tagsassign_conversationcreate_commentcreate_contactcreate_custom_fieldcreate_or_update_contactcreate_tagdelete_contactdelete_tagget_contactget_custom_fieldget_messageget_userlist_channelslist_closing_noteslist_contact_channelslist_contactslist_custom_fieldslist_messageslist_templateslist_usersmerge_contactsremove_contact_tagssend_messageupdate_contactupdate_contact_lifecycleupdate_conversation_statusupdate_tagScored across 28 tools
Most tools have distinct purposes, but create_contact and create_or_update_contact overlap significantly, potentially causing misselection. Other tools are clearly separated.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.
28 tools is on the higher end but covers a broad domain (contacts, messaging, tags, custom fields, etc.), justifying the count. Slightly heavy but not excessive.
Most core CRUD lifecycle operations are covered for contacts, tags, messages, and users. Minor gaps like missing delete for messages or conversations are acceptable given the scope.
Run WhatsApp Business campaigns from any AI assistant: contacts, segments, and broadcasts.
WhatsApp CRM for AI agents: search contacts, read chats, manage the sales pipeline, send messages.
Give AI agents secure access to RevDesk calling, SMS, phone numbers, caller IDs, and usage.
Give your AI agents the tools to build, manage, and run automation workflows.
