Twenty CRM MCP

by 0xfabrica

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct operation (create, get, list, search, update, soft-delete, restore, merge, group, find duplicates) with no overlap. Batch and single variants are clearly differentiated by name and description.
Naming Consistency5/5
All tools follow the consistent pattern 'twenty_<action>_<object?>' using snake_case and lowercase, with verbs like create, get, list, update, soft_delete, restore, merge, etc. No mixing of conventions.
Tool Count5/5
14 tools cover the CRM domain comprehensively without being excessive. Each tool serves a distinct purpose, and the count aligns well with a full-featured client.
Completeness4/5
Covers CRUD, batch operations, soft delete/restore, deduplication, merging, and grouping. Missing hard delete (intentionally omitted) and some advanced operations like export or analytics, but the core lifecycle is complete.
Average 3.6/5 across 14 of 14 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds 'without modifying CRM data' which is redundant and does not clarify behavior like what happens if duplicates are found (return type, format, pagination). No new insights beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence), which is generally good, but it lacks essential details that could be added without becoming verbose. It is not optimally structured for agent comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameters, and a description that implies inputs, the tool definition is critically incomplete. There is no way for an AI agent to know how to invoke this tool correctly (e.g., what to pass, what to expect). Other sibling tools have richer descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, yet the description mentions 'supplied record IDs or candidate data'. This is a direct contradiction. The description does not add meaning; it misleads about required inputs. Schema coverage is 100% (trivially) but description compensates negatively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool finds duplicates and is read-only, but it doesn't specify what constitutes duplicates (exact IDs vs fuzzy matching) or the scope (within a specific object type?). It moderately distinguishes from siblings like 'twenty_search_records' but not clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 other record tools (e.g., list, search, merge). The description says 'check supplied record IDs or candidate data' but the input schema has no parameters, creating confusion about how to supply data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds 'Read-only' which is consistent, but does not provide additional behavioral context beyond what annotations already convey. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence without any unnecessary words. It is front-loaded with the key action and immediately follows with the read-only qualifier. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description omits details about return format, error handling, and parameter nuances (e.g., depth, response_format). No output schema is provided, so the description should at least mention what the agent can expect as output. The openness of the tool (openWorldHint) also suggests more context about potential side effects or data freshness would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the input schema documents most parameters. The description does not add any parameter-specific meaning or context beyond what the schema already provides. Baseline of 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch one record by object name and UUID' and includes 'Read-only', which distinguishes it from write siblings like twenty_create_record or twenty_update_record. The verb 'fetch' and resource 'record' are specific, but it could be more explicit about when to use this tool versus twenty_list_records or twenty_search_records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool over alternatives such as twenty_list_records or twenty_search_records. It only describes the operation without context about when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. Description adds little beyond the schema: mentions batch size (1-50) but fails to disclose idempotency, atomicity, or error handling. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 7-word sentence is highly concise. However, it omits helpful structuring like usage tips or important constraints. Efficient but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should explain return value, especially for a batch operation. It also lacks coverage of error scenarios, partial failures, or idempotency. Given complexity of batch create, description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage). The description itself adds no extra meaning; it only restates the batch limit. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'create', resource 'records', and scope '1-50 in an allowed business object'. This distinguishes it from sibling tools like batch update or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that for single records one should use twenty_create_record, nor does it address batch size limits beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds behavioral details about filters, ordering, depth, and pagination, but these are limited and partially redundant with annotations. No contradictions, but the additional context is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 13 words, front-loaded with the core action and followed by key capabilities. No filler or redundant content. Efficiently communicates the tool's essence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and moderate annotations, the description covers the basic purpose but omits details like pagination parameters (ending_before, starting_after), response_format options, and return structure. Leaves several aspects unexplained, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, leaving half of parameters without schema descriptions. The description mentions 'filters, ordering, relation depth, and cursor pagination' which loosely cover filter, order_by, depth, and pagination parameters, but does not provide explicit semantics or details for individual parameters. Baseline is 3 given moderate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List records' and the resource 'any supported Twenty object', with specific features like filters, ordering, relation depth, and cursor pagination. It distinguishes from mutation siblings by noting it's read-only, but does not explicitly differentiate from twenty_search_records which may also list/search, preventing a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 twenty_search_records. Does not specify use cases, prerequisites, or when not to use it. The description lacks explicit context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds 'Read-only' which is redundant but confirms safety. It also mentions group_by syntax and optional aggregation, adding some behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It could be slightly more informative (e.g., mentioning alternatives) but is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (2 required) and no output schema, the description is very minimal. It lacks examples, syntax details, and guidance on usage patterns, which is inadequate for a complex grouping/aggregation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% (5 of 7 parameters described). The description itself does not add parameter-specific details beyond what the schema provides, meeting the baseline for coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Group and optionally aggregate), the resource (records), and the syntax (group_by syntax). It distinguishes from sibling tools like twenty_list_records by specifying grouping and aggregation capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only usage but does not explicitly compare with sibling tools or advise when to use this over a simple listing. More guidance would improve decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety: not read-only, not destructive, idempotent, open world. The description adds no extra behavioral context beyond 'restore soft-deleted records'. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. It is front-loaded and efficient, though the extreme brevity slightly detracts from completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch operation with 4 parameters and no output schema, the description lacks return value info, error behavior, or side effects. The filter mechanism and depth parameter are schema-documented but the description does not tie them together.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The tool description adds no parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Restore', the resource 'soft-deleted records', and the mechanism 'matching a required filter'. It distinguishes from siblings like the singular 'restore_record' and the opposite 'batch_soft_delete_records'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for restoring soft-deleted records with a filter but provides no explicit guidance on when to use this batch variant over the singular 'restore_record' or other siblings. No when-not-to-use or alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true, so the description does not need to repeat these. The description aligns with annotations by stating 'patch', which is a write operation. However, it adds no extra behavioral context such as error handling or what happens on missing records, which would be helpful given the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose without any extraneous words. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 the tool has moderate complexity (5 params, nested objects), the description could mention what the response contains (e.g., updated record or success confirmation). It adequately covers the action but leaves the return value unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (80%), with clear descriptions for most parameters (id, entity, depth, response_format). The description adds no parameter-specific details beyond what is in the schema, so its contribution is neutral. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Patch one record' with the verb 'patch' and resource 'one record', scoped by 'allowed business object' and 'UUID'. This distinguishes it from sibling tools like batch create/update and soft delete, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention batch operations for multiple records or other update strategies, leaving the agent to infer usage context from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior, but the description adds context that internal objects are read-only, which is a behavioral constraint. It is consistent with annotations and provides extra clarity without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the core purpose. It could benefit from a bit more structure, but it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, yet the description does not mention return values, error handling, or side effects. For a creation tool, missing details on what the response contains (e.g., the created record ID) makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 80% of parameters with descriptions. The description does not add any additional meaning beyond what is in the schema. Baseline 3 is appropriate as the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('one record in an allowed business object'), and implicitly distinguishes from batch or update tools. It also notes that internal/system objects are read-only, which helps differentiate permissible targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that internal/system objects are read-only, giving a when-not-to-use hint. However, it does not explicitly guide when to use this tool versus siblings like twenty_batch_create_records or twenty_update_record. The schema provides preferences for normal CRM objects, but the description itself lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare mutation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds no additional behavioral context such as cascading effects, authorization needs, or record state requirements beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence of 9 words. No wasted content, front-loaded with the key action and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restore operation with idempotent and non-destructive annotations, the description is nearly complete. Lacks mention that the record must be soft-deleted, but overall sufficient for the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 params described). The description barely adds meaning beyond the schema, only reiterating 'by object and UUID'. No additional detail for depth or response_format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'restore', resource 'record', and distinguishes it as restoring a single soft-deleted record by object and UUID, differentiating it from the sibling tool twenty_restore_records which handles batch restores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. The description implies usage for single record restoration, but does not mention scenarios like batch restore or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. Description adds 'targeted search' and 'filter syntax' but does not elaborate on other behaviors (e.g., pagination, response format). Adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with action and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description could explain return format or pagination. It only mentions 'search' and filter syntax. With 8 parameters and a complex filter, more context (e.g., result set handling) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 50% description coverage (4 of 8 params described). Description does not add parameter-specific details beyond the schema. Baseline of 3 is appropriate as schema provides some information but description fails to compensate for missing param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it's a read-only search using Twenty filter syntax. Explicitly distinguishes from 'list' by preferring search when criteria are known.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear usage preference over list when criteria are known. Lacks explicit when-not or alternative tools beyond list, but the guidance is useful and direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds valuable context: it never hard-deletes and is disabled without an environment variable. This provides behavioral transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences, front-loaded with the core purpose, followed by the key condition. Every word is necessary and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple soft-delete operation with 3 parameters and no output schema, the description adequately covers the function, safety guarantee, and activation requirement. It could mention response format or error handling, but is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameter details. While schema coverage is 67% (entity and response_format have descriptions), the description adds no additional meaning for parameters like id, which lacks schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'soft-delete' and the resource 'one record'. It explicitly distinguishes from hard-delete and mentions the enabling condition. This differentiates it from sibling tools like batch delete or restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use (soft-delete) and when not (hard-delete), and mentions the required environment variable. However, it does not explicitly compare to sibling tools like batch delete or restore, which are present in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=true, and idempotentHint=true, providing safety profile. The description adds no further behavioral context beyond 'Patch all records matching a filter'. It does not disclose potential side effects (e.g., irreversible changes) or behavior with large result sets. With annotations present, the description adds marginal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no wasted words. It front-loads the core purpose and is immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, 3 required, no output schema), the description covers the essential behavior: it patches all matching records. The missing output format details are compensated by the 'response_format' parameter description. Annotations fill safety gaps. Slight lack of detail on error handling or partial updates, but adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful guidance: filter syntax example ('name[ilike]:...'), entity preference note, and output format recommendation. This enhances understanding beyond the schema's basic definitions, warranting above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Batch-update Twenty CRM records' and description 'Patch all records matching a required filter in an allowed business object' clearly state the action (patch), resource (records in business object), and scope (all matching a filter). This distinguishes it from siblings like twenty_update_record (single record) and twenty_batch_create_records (create vs update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you need to update multiple records based on a filter. It contrasts with single-record update and batch create/delete via sibling context, but it does not explicitly state when not to use or recommend alternatives. The guidance is clear but lacks exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true; the description adds that TWENTY_ALLOW_DESTRUCTIVE must be set for actual merge, providing critical behavioral context beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Every sentence earns its place by conveying default behavior and required conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the destructive and complex nature. It lacks details on what merging entails, impact on records, preview behavior, and return values. Annotations provide some context, but more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so description must compensate. It effectively specifies required implicit parameters (dry_run, TWENTY_ALLOW_DESTRUCTIVE) that are not in the schema, adding essential meaning for invoking the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool previews or merges records, with a default preview mode. It distinguishes itself from sibling tools like create/update by specifying the merge action, but does not explicitly differentiate from 'twenty_find_duplicates' which may be related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: preview by default, actual merge requires dry_run=false and TWENTY_ALLOW_DESTRUCTIVE=true. It does not specify when not to use or list alternatives, but the context is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructiveHint=true, idempotentHint=true), description clarifies it's a soft-delete, never hard-deletes, and requires an env variable. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Front-loaded with purpose and key behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema info, but core behavior is fully covered. No mention of restore alternative among siblings, but adequate for a batch soft-delete tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value: for entity, suggests preferred objects; for filter, provides an example; for response_format, explains JSON vs markdown use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'soft-delete' on 'records', and adds the critical constraint 'Never hard-deletes'. Distinguishes from sibling tools like hard-delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions the prerequisite TWENTY_ALLOW_DESTRUCTIVE=true, implying when it's usable. Lacks explicit comparison to the singular soft_delete_record sibling, but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![twentycrm-mcp MCP server](https://glama.ai/mcp/servers/0xfabrica/twentycrm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/0xfabrica/twentycrm-mcp)

Score Badge

Copy to your README.md:

[![twentycrm-mcp MCP server](https://glama.ai/mcp/servers/0xfabrica/twentycrm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/0xfabrica/twentycrm-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0xfabrica/twentycrm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server