The Custify MCP Server connects AI tools to Custify customer success data, enabling you to query, analyze, and act on accounts, contacts, health scores, tasks, and more.
Account Management
List and filter accounts using a powerful filter system (by churn status, health score, signup date, CSM, segments, etc.)
Get full details for a specific account by ID, or search by name/domain
Discover all available account/contact fields and their types for filtering
Contact Management
List all contacts associated with an account
Get full details for a specific contact by ID
Health & Usage Insights
Retrieve health scores (global and individual breakdowns) for an account
Get product usage/event data filtered by event name and date range
Access historical health score trends over time
Alerts & Segments
Fetch alerts/signals for a specific account
Determine which segments an account belongs to
Task Management
List and filter tasks (by assignee, account, status, priority, due date, tags, etc.)
Get full details for a specific task
Resolve tag names to IDs and discover assignee/account/creator IDs
Write Operations
Create notes on an account's timeline
Create and assign tasks to CSMs with priority and due dates
Trigger manually-started playbooks on specific accounts
Update custom attribute fields on accounts or contacts
Read-Only Resources
View all segment, playbook, and health score definitions (names, IDs, thresholds, types)
Click on "Install 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., "@Custify MCP Server Show me all accounts with a health score below 50"
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.
Connect AI tools to your Custify customer success data via the Model Context Protocol.
Query accounts, health scores, usage data, and more — or create notes, tasks, and trigger playbooks — all from within Claude, Cursor, VS Code, or any MCP-compatible AI tool.
Get up and running in under 2 minutes.
Go to Custify Settings > Developer > API Access and create or copy your API key.
npx @custify/mcp-serverSee the Configuration section below for your specific tool.
Ask your AI assistant:
How many churned accounts do I have?Related MCP server: Planhat MCP
Add the following to your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"custify": {
"command": "npx",
"args": ["-y", "@custify/mcp-server"],
"env": {
"CUSTIFY_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop after saving.
Open Settings > MCP
Click Add new MCP server
Use the following configuration:
Name: custify
Command: npx -y @custify/mcp-server
Environment Variables: CUSTIFY_API_KEY=your-api-key-here
Add to your .vscode/mcp.json in your workspace root:
{
"servers": {
"custify": {
"command": "npx",
"args": ["-y", "@custify/mcp-server"],
"env": {
"CUSTIFY_API_KEY": "your-api-key-here"
}
}
}
}claude mcp add custify -- npx -y @custify/mcp-server \
--env CUSTIFY_API_KEY=your-api-key-hereChatGPT requires an HTTP-based MCP server. Deploy with Docker:
docker run -d \
-p 3000:3000 \
-e CUSTIFY_API_KEY=your-api-key-here \
ghcr.io/custifyofficial/custify-mcp:latestThen configure ChatGPT to connect to your server's URL:
https://your-server.example.com/mcpThe Custify MCP server supports two transports:
STDIO (default): Run npx @custify/mcp-server with the CUSTIFY_API_KEY environment variable set.
Streamable HTTP: Set MCP_TRANSPORT=streamable-http and the server will listen on port 3000 (configurable via PORT). The MCP endpoint is /mcp.
Refer to your MCP client's documentation for how to configure an MCP server using either transport.
Tool | Type | Description |
| Read | List and filter accounts using tag IDs or Custify's advanced filter system |
| Read | Get full details for a specific account by ID |
| Read | Search accounts by name or domain |
| Read | Discover all available fields and their types for filtering |
list_accounts supports tag_ids for simple tag filtering and Custify's full filter system for advanced fields. Use list_tags with category: "company" to resolve account tag names to IDs. Use list_attributes with entity_type: "account" to discover available fields.
Tag filters use this backend format when passed manually through filters:
{
"fieldName": "tags",
"fieldType": "Tag",
"filterType": "is_any_of",
"filterValue": ["<company_tag_id>"]
}Supported tag filterType values are is_any_of, is_all_of, is_none_of, is_unknown, and any_value. For ID-based tag filters, filterValue must be a non-empty array of tag IDs.
Filter examples:
What you want | Filter object |
Churned accounts |
|
Name contains "acme" |
|
Has any listed account tag |
|
Has all listed account tags |
|
Has none of the listed account tags |
|
Health score > 50 |
|
Signed up after a date |
|
In a specific segment |
|
Has any CSM assigned |
|
Available filter types by field type:
Field Type | Filter Types |
Boolean |
|
Number |
|
String |
|
Date |
|
Dropdown |
|
Segment |
|
Tag |
|
User |
|
Currency |
|
Tool | Type | Description |
| Read | List and filter contacts across all accounts using tag IDs or Custify filters |
| Read | List contacts/people linked to one account |
| Read | Get full contact details by ID |
list_contacts is the contact equivalent of list_accounts. Use tag_ids with people tags for simple tag filtering, or pass advanced Custify filters. Use list_tags with category: "people" to resolve contact tag names to IDs. Use list_attributes with entity_type: "contact" to discover available contact fields.
Contact filter examples:
What you want | Parameters |
Contacts tagged "champion" |
|
Contacts with no listed tags |
|
Email contains a domain |
|
Contacts linked to an account |
|
Tool | Type | Description |
| Read | Get all health scores for an account, with score names and values |
| Read | Get product usage and event data for an account |
| Read | Get health score values over time for trend analysis |
Tool | Type | Description |
| Read | Get alerts/signals for an account |
| Read | Get which segments an account belongs to |
Tool | Type | Description |
| Read | Query tasks across all accounts with filters and pagination |
| Read | Get full details for a specific task by ID |
| Write | Mark a task as |
| Read | Discover assignee, account, and creator IDs (with names) currently used on tasks |
| Read | Resolve human-readable tag names to tag IDs. Use |
list_tasks uses flat, ergonomic parameters. Filters combine with AND. To resolve a tag name like "onboarding follow up" to an ID, call list_tags with category: "task". To resolve an assignee name, call list_task_filter_values (returns user IDs with names).
Filter examples:
What you want | Parameters |
My open tasks due today |
|
Overdue tasks for an account |
|
All tasks tagged "onboarding follow up" |
|
High-priority tasks due this week |
|
Tasks due in a custom date range |
|
Tasks assigned to a CSM, sorted by due date |
|
Available status filter values:
Status | Meaning |
| Status is open and not snoozed |
| Task completed |
| Marked as not relevant |
| Open and |
| Open and (no |
| Open and |
update_task_status only writes persisted task statuses: open, done, and not_relevant. Use list_tasks first to find the internal task_id, then call update_task_status with the new status.
Available due shortcuts: past_due, today, this_week, this_month, later. For custom ranges, supply both due_after and due_before (ISO dates). The due shortcut and the date-range pair are mutually exclusive — passing only one bound of the range is ignored.
Tool | Type | Description |
| Read | List timeline notes for an account, a contact, or across all accounts |
| Read | List past and upcoming meetings for an account or across all accounts |
list_notes returns notes most recent first (sticky notes first when scoped to a single account or contact). Scope with account_id or contact_id (Custify internal IDs), or omit both to list notes across all accounts. Note text is HTML and includes notes added manually, generated by Playbooks, or imported from integrations (see the source field, e.g. salesforce). Use create_note to add a note.
list_meetings returns meetings imported from Gmail/Outlook calendars, HubSpot, or created via the API — past and upcoming. Scope with account_id (Custify internal company ID), or omit it to list meetings across all accounts. Each meeting includes the organizer, participants (matched to Custify contacts where possible), start/end times, and duration. Both tools paginate with limit (max 50) and offset.
Tool | Type | Description |
| Read | Get customer objectives for a specific account, using either the Custify account ID or your external |
get_account_objectives accepts account_id (Custify internal company ID) or external_account_id (your company_id). It supports pagination, sorting, and Custify filter objects for fields such as objectiveStatus, importance, risk, and dueAt.
Tool | Type | Description |
| Write | Add a note to an account's timeline |
| Write | Create a task assigned to a CSM |
| Write | Trigger a manually-started playbook on an account |
| Write | Update custom attribute values on an account or contact |
| Write | Add an existing tag to one or more accounts or contacts |
| Write | Remove an existing tag from one or more accounts or contacts |
Tag actions accept entity_type: "account" or entity_type: "contact", an array of Custify internal entity_ids, and a tag_id. Use list_tags or the custify://tags resource first to resolve tag names to IDs.
Resources provide read-only context that AI agents can use to understand your Custify workspace:
Resource | URI | Description |
Segments |
| All segment definitions with names and IDs |
Playbooks |
| All playbook definitions with names, types, and IDs |
Health Score Definitions |
| All health score configs with names, thresholds, and IDs |
Calculated Metrics |
| All calculated metric definitions for companies and people |
Lifecycles |
| All lifecycle definitions with goals and task templates |
Tags |
| All tags grouped by category |
Here are real-world examples of what you can ask your AI assistant once connected:
"How many churned accounts do I have?" Uses
list_accountswith a churned filter to count accounts where churned = true.
"Show me all accounts with a health score below 30" Uses
list_attributesto find the health score field name, thenlist_accountswith a Number filter.
"Find all accounts managed by jane@company.com" Uses
list_accountswith a User filter on the CSM field.
"Which accounts signed up this quarter?" Uses
list_accountswith a Date filter:filterType: "this_quarter"onsigned_up_at.
"Show accounts tagged renewal risk" Uses
list_tagswithcategory: "company"to resolve the tag ID, thenlist_accountswithtag_ids.
"Show contacts tagged champion" Uses
list_tagswithcategory: "people"to resolve the tag ID, thenlist_contactswithtag_ids.
"Find contacts with example.com email addresses" Uses
list_contactswith a String filter on
"Give me a full summary of Acme Corp" Uses
search_accountsto find Acme, thenget_account,get_health_scores,get_contacts,get_usage_data, andget_segment_membershipto build a comprehensive briefing.
"What segments is Acme Corp in?" Uses
search_accountsto find the account ID, thenget_segment_membership.
"Show me the health score trend for Acme Corp over the last month" Uses
get_health_scoresto find score IDs, thenget_usage_trendsfor historical values.
"What's on my plate today?" Uses
list_taskswithassignee_id(your user ID) anddue: "today"to pull a daily task list.
"Show me all overdue tasks tagged 'onboarding follow up' assigned to Jane" Uses
list_tagswithcategory: "task"to resolve the tag name to an ID,list_task_filter_valuesto resolve Jane's user ID, thenlist_taskswithtag_ids,assignee_id, andstatus: "overdue".
"What's open for Acme Corp?" Uses
search_accountsto find the account ID, thenlist_taskswithaccount_idandstatus: "open".
"Mark the onboarding review task as done" Uses
list_tasksto find the matching task ID, thenupdate_task_statuswithstatus: "done". Usestatus: "open"to reopen a task orstatus: "not_relevant"to mark it as not relevant.
"What objectives are open for Acme Corp?" Uses
search_accountsto find the account ID, thenget_account_objectives.
"Create a follow-up task for Acme Corp: Review onboarding progress, due next Friday" Uses
search_accountsto find Acme, thencreate_taskwith title, due date, and account ID.
"Add a note to Acme Corp: Spoke with VP of Engineering about API latency concerns" Uses
search_accountsthencreate_notewith the note body.
"Run the renewal prep playbook for Acme Corp" Uses the
playbooksresource to find the playbook ID,search_accountsfor the account, thenrun_playbook.
"Tag Acme Corp as renewal risk" Uses
search_accountsto find the account ID,list_tagsorcustify://tagsto find the tag ID, thenadd_tag_to_entities.
"What fields can I filter accounts by?" Uses
list_attributesto return all available fields with their names and types.
"What segments do we have?" Reads the
custify://segmentsresource.
"What playbooks are available?" Reads the
custify://playbooksresource.
"What calculated metrics and lifecycle stages do we have?" Reads the
custify://calculated-metricsandcustify://lifecyclesresources.
"What tags can I use on accounts and contacts?" Reads the
custify://tagsresource.
Variable | Required | Default | Description |
| Yes | - | Your Custify API key |
| No |
| Custom API base URL (for different clusters) |
| No |
| Transport mode: |
| No |
| HTTP server port (only used with |
Run the server as a Docker container for HTTP-based MCP clients:
docker run -d \
--name custify-mcp \
-p 3000:3000 \
-e CUSTIFY_API_KEY=your-api-key-here \
ghcr.io/custifyofficial/custify-mcp:latestThe MCP endpoint will be available at http://localhost:3000/mcp and a health check endpoint at http://localhost:3000/health.
Data flow: Your AI tool communicates with the Custify MCP server, which then makes authenticated API calls to the Custify REST API. No data is stored by the MCP server itself.
API key handling: Your CUSTIFY_API_KEY is read from environment variables and is never logged, cached, or exposed through MCP responses. When using STDIO transport, the key stays within your local process. When using HTTP transport, ensure your deployment is behind TLS.
Permissions: The MCP server inherits the permissions of your API key. Use a key scoped to the minimum access level your workflows require. Read-only keys will work for all read tools; write tools require a key with write permissions.
No telemetry: The server does not collect analytics or send data to any third party.
"Error: CUSTIFY_API_KEY environment variable is required"
Make sure the CUSTIFY_API_KEY environment variable is set in your MCP client configuration. Double-check for typos and ensure there are no extra spaces.
Server not connecting in Claude Desktop
Verify the config file path is correct for your OS.
Ensure you have restarted Claude Desktop after editing the configuration.
Check that npx is available in your system PATH.
Authentication errors (401) Your API key may be invalid or expired. Generate a new key from Custify Settings > Developer > API Access.
Permission errors (403) The endpoint may not be available for API key access. Check that your Custify account has the required permissions.
Timeout or connection errors
If using HTTP transport, verify the server is running and accessible. Check that the PORT environment variable matches your deployment configuration. For STDIO transport, ensure no firewall or proxy is blocking local process communication.
Different Custify cluster?
If your Custify instance is on a different cluster (e.g., EU), set CUSTIFY_API_URL to your cluster's API URL.
Docker container exits immediately
Check the container logs with docker logs custify-mcp. The most common cause is a missing CUSTIFY_API_KEY environment variable.
Contributions are welcome! To get started:
git clone https://github.com/CustifyOfficial/custify-mcp.git
cd custify-mcp-server
npm install
npm run devFork the repository
Create a feature branch: git checkout -b feature/my-feature
Make your changes and add tests
Run the test suite: npm test
Submit a pull request
Please open an issue first if you plan a significant change.
MIT - see LICENSE for details.
Create a note on a Custify account.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID | |
| body | Yes | The note content/body text | |
| subject | No | Optional note subject |
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. While 'Create' implies a write/mutation operation, it doesn't specify permissions required, whether notes are editable/deletable, rate limits, or what happens on success/failure. The description is minimal and lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple creation tool and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'note' represents in Custify's context, what happens after creation, or provide any error handling context. The agent would need to guess about important behavioral aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific context beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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 a note') and target resource ('on a Custify account'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'create_task' or explain what distinguishes notes from other entities in the system.
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 'create_task' or other sibling tools. It doesn't mention prerequisites, typical use cases, or any context about when note creation is appropriate versus other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a task associated with a Custify account. Note: assignee_id must be a Custify user ObjectId (not an email address).
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID | |
| title | Yes | Task title | |
| description | No | Task description | |
| due_date | No | Due date in ISO format (e.g. 2024-12-31) | |
| assignee_id | No | Custify user ID to assign the task to (must be a valid user ObjectId, not an email) | |
| priority | No | Task priority (default: medium) | medium |
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 mentions a constraint about 'assignee_id' but fails to describe critical aspects like authentication requirements, rate limits, error handling, or what happens upon creation (e.g., returns a task ID). This is inadequate 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 appropriately sized with two sentences: one stating the purpose and another providing a specific parameter note. It's front-loaded with the core function, though the second sentence could be integrated more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a creation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, return values, error cases, and usage context, making it incomplete for effective agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by clarifying the 'assignee_id' constraint (ObjectId vs. email), but doesn't provide additional semantic context beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a task') and the resource ('associated with a Custify account'), which provides a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'create_note' or other creation tools, missing explicit differentiation.
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 'create_note' or other sibling tools. It lacks context about prerequisites, appropriate scenarios, or exclusions, offering only a basic functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Custify account/company by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a 'get' operation, implying read-only behavior, but doesn't address authentication requirements, rate limits, error conditions, or what 'detailed information' specifically includes. The description is minimal and lacks context about the tool's operational characteristics.
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 directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple lookup tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no annotations and no output schema, the description is insufficient. It doesn't explain what 'detailed information' includes, how results are structured, or any behavioral constraints. Given the lack of structured metadata, the description should provide more context about the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'account_id' fully documented in the schema. The description adds no additional semantic context about the parameter beyond what's already in the schema, so it meets the baseline score of 3 for adequate but not additive documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the resource ('specific Custify account/company by ID'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'list_accounts' or 'search_accounts' beyond the singular vs. plural distinction.
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_accounts' or 'search_accounts'. It doesn't mention prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage patterns 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.
[V1 LIMITATION: This tool may not work as expected — the underlying alerts API has limited support. Out of scope for the current version.] Get alerts/signals from Custify for a specific account, optionally filtered by status.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID to get alerts for | |
| status | No | Filter by alert status | |
| limit | No | Number of results (1-100, default 25) | |
| offset | No | Pagination offset (default 0) |
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 adds important context about API limitations ('may not work as expected — the underlying alerts API has limited support'), which is valuable behavioral information. However, it doesn't describe response format, error handling, authentication requirements, rate limits, or whether this is a read-only 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 front-loaded with a version limitation warning that may distract from the core functionality. The main purpose statement is clear but could be more concise. The two-sentence structure is reasonable, but the warning takes up significant space relative to the functional description.
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 and no output schema, the description provides basic functionality but lacks important context. It mentions API limitations (helpful) but doesn't describe what the tool returns, error conditions, or authentication requirements. For a tool with 4 parameters and no structured output documentation, this leaves significant gaps in understanding how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all 4 parameters. The description mentions 'optionally filtered by status' which aligns with the 'status' parameter in the schema, but adds no additional semantic context beyond what's already in the parameter descriptions. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get alerts/signals from Custify for a specific account, optionally filtered by status.' It specifies the verb ('Get'), resource ('alerts/signals'), and scope ('for a specific account'), but doesn't explicitly differentiate from sibling tools like 'get_account' or 'get_contacts' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions optional filtering by status, it doesn't explain when to use this tool over other sibling tools like 'get_account' or 'search_accounts' for alert-related queries. The version limitation note is a warning, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific Custify contact by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | The Custify contact/customer ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.
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 front-loads the core purpose ('Get detailed information about a specific Custify contact by ID'). There is no wasted verbiage or redundancy, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks context on behavioral traits (e.g., read-only nature, error cases) and doesn't explain what 'detailed information' entails in the return value. Without annotations or an output schema, the description should provide more guidance on what to expect from the tool's operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'contact_id' documented as 'The Custify contact/customer ID'. The description adds no additional meaning beyond this, such as format examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param info in the description, which applies here.
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 ('detailed information about a specific Custify contact'), making the purpose unambiguous. It distinguishes this tool from siblings like 'get_contacts' (plural) by specifying retrieval of a single contact by ID. However, it doesn't explicitly contrast with other sibling tools that might also retrieve contact-related data, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a contact ID), exclusions, or comparisons to siblings like 'get_contacts' (which likely lists multiple contacts) or 'search_accounts' (which might involve contacts indirectly). Without such context, an agent 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.
Get contacts/people associated with a Custify account.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID | |
| limit | No | Number of results (1-100, default 25) | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get contacts/people,' implying a read-only operation, but doesn't specify if it's paginated (though parameters suggest it), what the output format is, rate limits, authentication needs, or error conditions. For a tool with no annotations, this leaves significant gaps in understanding its 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. There's no wasted verbiage, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and 3 parameters, the description is incomplete. It lacks details on behavioral traits (e.g., pagination, error handling), output format, and usage context. While the schema covers parameters well, the overall context for safe and effective use by an AI agent is insufficient, especially for a read operation that might involve multiple results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for 'account_id', 'limit', and 'offset'. The description adds no additional meaning beyond the schema, such as explaining what 'contacts/people' entails or how parameters interact. Since the schema is comprehensive, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 the resource 'contacts/people associated with a Custify account.' It distinguishes from siblings like 'get_contact' (singular) and 'get_account' by specifying it retrieves multiple contacts linked to an account. However, it doesn't explicitly contrast with other list-like tools (e.g., 'list_accounts'), making it a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'get_contacts' over 'get_contact' (singular), 'search_accounts', or other sibling tools. There's no context about prerequisites, such as needing an account ID, or exclusions, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get health scores for a specific Custify account, including global and individual score breakdowns.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a 'Get' operation, implying read-only, but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what format the health scores are returned in. The description adds minimal context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and includes only essential details about what's included, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple single-parameter input, the description is minimally adequate. It covers the purpose but lacks behavioral details like return format or error handling. For a read-only tool with low complexity, it's passable but leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single parameter 'account_id'. The description adds no additional parameter semantics beyond implying it's for a 'specific Custify account,' which aligns with the schema. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 health scores') and target resource ('for a specific Custify account'), with additional detail about what's included ('global and individual score breakdowns'). It distinguishes from siblings like get_account or get_usage_data by focusing specifically on health scores, though it doesn't explicitly contrast them.
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. While it specifies 'for a specific Custify account,' it doesn't mention prerequisites, when-not scenarios, or direct comparisons to siblings like get_account or get_usage_data that might provide related information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all segments that a specific Custify account belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't clarify aspects like whether it requires authentication, has rate limits, returns paginated results, or what happens if the account ID is invalid. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It front-loads the core purpose efficiently, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return value looks like (e.g., a list of segment names or objects), error conditions, or behavioral traits like idempotency. For a tool with no structured output documentation, the description should provide more context to guide the 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 input schema already fully documents the single parameter 'account_id'. The description adds no additional semantic context beyond implying it's used to identify the account, which the schema's description ('The Custify company/account ID') already covers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all segments that a specific Custify account belongs to'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_account' or 'search_accounts', which might also retrieve account-related data but with different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid account ID, or compare it to siblings like 'get_account' (which might retrieve general account info) or 'list_accounts' (which lists multiple accounts). This leaves 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.
Get usage/event data for a Custify account, optionally filtered by event name and date range.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | The Custify company/account ID | |
| event_name | No | Filter by specific event name | |
| start_date | No | Start date in ISO format (e.g. 2024-01-01) | |
| end_date | No | End date in ISO format (e.g. 2024-12-31) | |
| type | No | Type of usage data to retrieve (default: eventFrequency) | eventFrequency |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about authentication requirements, rate limits, pagination, error handling, or what the output looks like. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding its operational characteristics.
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 front-loads the core purpose ('Get usage/event data') and mentions key optional filters. There's no wasted verbiage, though it could potentially be structured to separate purpose from filtering details more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a data retrieval tool with 5 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what 'usage/event data' entails, how results are formatted, whether there are limitations on date ranges, or authentication requirements. For a tool that likely returns structured data, more context is needed to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description mentions optional filtering by event name and date range, which aligns with the schema but doesn't add meaningful semantic context beyond what's already in the parameter descriptions. The baseline of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get usage/event data for a Custify account' with optional filtering by event name and date range. It specifies the verb ('Get') and resource ('usage/event data'), but doesn't explicitly differentiate from sibling tools like 'get_usage_trends' which might provide similar data in a different format or 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 provides no guidance on when to use this tool versus alternatives. It mentions optional filtering but doesn't compare it to sibling tools like 'get_usage_trends' or explain scenarios where one would be preferred over the other. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get historical health score values/trends over time for a specific health score metric. Optionally filter by account.
| Name | Required | Description | Default |
|---|---|---|---|
| health_score_id | Yes | The health score definition ID | |
| account_id | No | Filter by specific Custify company/account ID | |
| limit | No | Number of data points to return (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves historical data with optional filtering, but doesn't cover critical aspects like rate limits, authentication requirements, data format, pagination, or error handling. For a tool with no annotations, this leaves significant gaps in understanding its 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, efficient sentence that front-loads the core purpose ('Get historical health score values/trends over time') and includes key details (specific metric, optional filtering). There is no wasted language, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is moderately complete for a read-only tool with full parameter documentation. It covers the purpose and basic usage but lacks details on behavioral traits (e.g., response format, limits) that would be crucial for an agent to use it effectively. It's adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (health_score_id, account_id, limit) with clear descriptions. The description adds minimal value beyond implying the tool focuses on historical trends and optional account filtering, but doesn't provide additional syntax or format details. This meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get historical health score values/trends over time') and resource ('for a specific health score metric'), with optional filtering by account. It distinguishes from siblings like 'get_health_scores' (likely current scores) and 'get_usage_data' (different data type), though not explicitly named. However, it lacks explicit sibling differentiation, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical trends of health scores, with optional account filtering. It doesn't explicitly state when to use this tool versus alternatives like 'get_health_scores' (which might provide current scores) or 'get_usage_data' (which might be for different metrics). No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Custify accounts/companies with optional filters. Filters use Custify's filter format: each filter is an object with fieldName, fieldType, filterType, and filterValue. Use the list_attributes tool to discover available fields and their types. Common examples:
Churned accounts: {"fieldName":"churned","fieldType":"Boolean","filterType":"true"}
Name contains: {"fieldName":"name","fieldType":"String","filterType":"contains","filterValue":"acme"}
Health score > 50: {"fieldName":"metrics.health_scores.","fieldType":"Number","filterType":"greater","filterValue":"50"}
In segment: {"fieldName":"metrics.health_scores.","fieldType":"Segment","filterType":"is_any_of","filterValue":[""]}
| Name | Required | Description | Default |
|---|---|---|---|
| filters | No | Array of filter objects. Use list_attributes to discover available fields. | |
| sorting_field | No | Field name to sort by (e.g. "name", "signed_up_at", "metrics.health_scores.<id>") | |
| sorting_direction | No | Sort direction (default: desc) | |
| limit | No | Number of results (1-100, default 25) | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds some behavioral context by detailing the filter format and providing examples, but it does not disclose key traits like whether this is a read-only operation, pagination behavior beyond limit/offset, rate limits, or authentication needs. The description compensates partially but leaves gaps for a tool with 5 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?
The description is appropriately sized and front-loaded, starting with the core purpose. The filter examples are detailed but necessary for clarity. It avoids redundancy, though the filter format explanation could be slightly more streamlined. Overall, most sentences earn their place in aiding tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no annotations, no output schema), the description is moderately complete. It covers filter usage well but lacks details on behavioral aspects like read/write nature, error handling, or output format. Without annotations or output schema, more context on what the tool returns or its operational constraints 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 value by explaining the filter format with examples and referencing 'list_attributes' for field discovery, which enhances understanding beyond the schema's technical definitions. However, it does not provide additional semantics for other parameters like sorting or pagination.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List Custify accounts/companies with optional filters.' It specifies the resource (accounts/companies) and verb (list), and distinguishes it from siblings like 'search_accounts' by emphasizing the filter format and referencing 'list_attributes' for field discovery, making it specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by explaining the filter format and referencing 'list_attributes' to discover fields. It implies when to use this tool (for listing with structured filters) but does not explicitly state when not to use it or name alternatives like 'search_accounts' from the sibling list, which could enhance guidance further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available company/account attributes that can be used for filtering and sorting. Returns field names, display names, and field types. Use this to discover which fields are available before building filters for list_accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | No | Entity type to get attributes for (default: account) | account |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format ('field names, display names, and field types') and the tool's read-only, non-destructive nature through context, but lacks details on permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage context, all in two efficient sentences with zero wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description is mostly complete, covering purpose, usage, and return values. However, it could benefit from mentioning any limitations (e.g., pagination) or authentication requirements to be fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain the implications of choosing 'account' vs. 'contact'), but doesn't detract from the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('List all available company/account attributes') and resources ('attributes'), and explicitly distinguishes it from sibling tools by mentioning its preparatory role for 'list_accounts' and 'filtering and sorting'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool ('before building filters for list_accounts') and distinguishes it from alternatives by implying it's for discovery rather than direct data retrieval, unlike siblings like 'list_accounts' or 'search_accounts'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a manually-started Custify playbook on a specific account. Only playbooks with trigger type "manually started" can be triggered via the API; segment-based and event-based playbooks run automatically and cannot be triggered this way.
| Name | Required | Description | Default |
|---|---|---|---|
| playbook_id | Yes | The Custify playbook ID | |
| account_id | Yes | The Custify company/account ID to run the playbook on |
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 effectively describes the tool's trigger mechanism constraints and API limitations, though it doesn't mention potential side effects, rate limits, authentication requirements, or what happens after triggering (e.g., asynchronous execution, notifications).
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 perfectly concise with two sentences that each earn their place: the first states the core purpose, the second provides critical usage constraints. There is zero wasted text and it's front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (triggering automated workflows), no annotations, and no output schema, the description does an excellent job covering purpose and constraints. However, it doesn't describe what happens after triggering (success/failure indicators, response format, or execution behavior), leaving some gaps 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 description coverage is 100%, providing clear documentation for both parameters. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline score of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Trigger a manually-started Custify playbook') on a specific resource ('on a specific account'), distinguishing it from all sibling tools which involve creating, getting, listing, updating, or searching data rather than triggering automated workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Only playbooks with trigger type "manually started" can be triggered via the API') and when not to use it ('segment-based and event-based playbooks run automatically and cannot be triggered this way'), providing clear alternatives and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Custify accounts/companies by name or domain.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query to match against account names and domains | |
| limit | No | Max results to return (1-100, default 25) |
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 what the tool does (searching), but doesn't mention whether this is a read-only operation, what permissions are required, whether results are paginated, or what format the results take. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple search tool and front-loads the core functionality. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the search returns (account objects? minimal data?), how results are ordered, or whether there are limitations like partial matches. For a search tool that likely returns structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description mentions searching 'by name or domain' which aligns with the query parameter's purpose, but adds no additional semantic context beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching Custify accounts/companies by name or domain. It specifies the verb 'search' and resource 'accounts/companies', but doesn't explicitly differentiate from sibling 'list_accounts' which might serve a similar listing function without search capabilities.
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. There's no mention of sibling tools like 'list_accounts' or 'get_account', nor any context about when search is preferred over direct retrieval. The agent 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.
Update custom attribute fields on a Custify account or contact.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_type | Yes | Type of entity to update | |
| entity_id | Yes | The entity ID (company ID or contact ID) | |
| fields | Yes | Key-value pairs of custom fields to set |
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 states this is an update operation (implying mutation) but doesn't mention permission requirements, whether changes are reversible, rate limits, error conditions, or what happens to existing fields not included in the update. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with good schema documentation and no complex behavioral nuances to explain.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (success confirmation? updated object? error details?), doesn't mention side effects, and provides no context about the update operation's behavior beyond the basic purpose statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain field naming conventions, validation rules, or provide examples of the 'fields' object structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and target ('custom attribute fields on a Custify account or contact'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'list_attributes' or 'get_account', but the verb+resource combination is specific enough for basic understanding.
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_attributes' (which might show existing custom fields) or 'run_playbook' (which might automate updates). There's no mention of prerequisites, constraints, or typical use cases beyond the basic operation.
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. Dates show when Glama detected each change.
v1.0.0create_notecreate_taskget_accountget_alertsget_contactget_contactsget_health_scoresget_segment_membershipget_usage_dataget_usage_trendslist_accountslist_attributesrun_playbooksearch_accountsupdate_custom_fieldsMost tools have distinct purposes targeting specific Custify resources like accounts, contacts, notes, tasks, alerts, health scores, segments, usage data, and playbooks. However, list_accounts and search_accounts have some functional overlap in retrieving accounts, though list_accounts offers richer filtering while search_accounts is simpler by name/domain.
Tool names follow a highly consistent verb_noun pattern throughout, such as create_note, get_account, list_attributes, run_playbook, and update_custom_fields. All tools use snake_case with clear, predictable naming conventions.
With 15 tools, this server is well-scoped for managing a Custify CRM platform. It covers core operations like account/contact management, data retrieval, and automation without being overwhelming or sparse.
The toolset provides strong coverage for account and contact management, including CRUD-like operations (e.g., get, list, update, create notes/tasks) and advanced features like health scores, segments, and playbooks. Minor gaps include no direct delete operations and limited alert functionality as noted, but agents can handle most workflows effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your AI copilot for customer onboarding — projects, KPIs, tasks, and safe writes.
Connect AI to your Attio CRM. Manage contacts, companies, deals, and sales pipelines. Create tasks…
Operate the Plixana CRM from any AI: contacts, deals, quotes, WhatsApp and metrics.
Connect AI tools to Weav customer service. Search conversations, reply, and manage knowledge.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CustifyOfficial/custify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
