Loading ToolBench
High-performance Model Context Protocol server for Attio API integration with AI assistants
Attio MCP server has 6 tools with reasonable schema coverage but significant quality gaps. Tool names follow verb_noun convention (get*, post*, patch*) but lack clarity and consistency. Descriptions are present but largely consist of API documentation snippets without context for LLM tool selection. Input schemas are defined but parameters lack descriptions in many cases. No output schemas documented. Error handling is absent. The apply-tool-names.ts script shows an attempt to humanize names post-registration, but the primary tool definitions use abbreviated API-style names (getv2objects, postv2objects, getv2attributes, postv2attributes) that do not clearly convey intent. Parameter descriptions exist for some fields but are inconsistent across tools.
Lists all attributes defined on a specific object or list. Attributes are returned in the order that they are sorted by in the UI. Required scopes: `object_configuration:read`.
Lists all system-defined and user-defined objects in your workspace. Required scopes: `object_configuration:read`.
Gets a single object by its `object_id` or slug. Required scopes: `object_configuration:read`.
Updates a single object. The object to be updated is identified by its `object_id`. Required scopes: `object_configuration:read-write`.
Creates a new attribute on either an object or a list. To create an attribute on an object, you must also have the `object_configuration:read-write` scope. To create an attribute on a list, you must also have the `list_configuration:read-write` scope.
Tool names are cryptic and do not clearly convey action or domain. Names like 'getv2objects', 'postv2objectsbyobject', 'getv2attributes' follow REST API versioning conventions rather than clear action-first naming. LLMs cannot infer intent from 'v2' in the name. The apply-tool-names.ts script attempts to humanize names after registration, but this transformation is applied post-build and not evident in the source schema definitions provided.
Descriptions lack context for LLM tool selection. All descriptions consist solely of API documentation (scope requirements, parameter hints) with no explanation of WHEN to call the tool or WHY the LLM would select it over alternatives. For example, 'Creates a new custom object in your workspace. Required scopes: `object_configuration:read-write`.' does not explain the business purpose or typical use case.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Creates a new custom object in your workspace. Required scopes: `object_configuration:read-write`.
No output schemas documented. Callers cannot know what fields the response contains, making it impossible to plan multi-step tool sequences. For example, after calling 'postv2objects' (create object), what fields does the response include? Is there an object_id to pass to subsequent calls? Unknown output structure forces guessing and extra discovery calls.
Parameter descriptions are inconsistent and sometimes missing. The 'requestBody' parameter in postv2objects and patchv2objectsbyobject has a description ('The JSON request body') but the nested 'data' object and its properties (api_slug, singular_noun, plural_noun) have descriptions. However, top-level parameters like 'object' in getv2objectsbyobject ('A UUID or slug to identify the object') are sparse and lack format guidance. Parameter 'target' in getv2attributes and postv2attributes has an enum but no explanation of what 'objects' vs 'lists' means in the Attio domain.
No error handling or recovery guidance. If a tool fails (e.g., duplicate api_slug when creating an object, invalid target enum), there is no documentation of error categories, retryability, or user-facing recovery steps. An LLM will have no guidance on whether to retry, ask the user, or try a different approach.
Pagination parameters are named inconsistently and lack documentation. 'getv2attributes' accepts 'limit' and 'offset' parameters but provides no guidance on default values, maximum limits, or total count in the response. No mention of whether results are ordered, or what 'show_archived' parameter returns when true, are archived attributes filtered out by default? Incomplete pagination guidance prevents reliable iteration.
No tool annotations for readability or risk. Tools like 'patchv2objectsbyobject' and 'postv2attributes' modify state and are write operations, but there is no idempotent, destructive, or readonly hint in the tool registration. An LLM cannot determine which tools are safe to retry vs which may have side effects.
Parameter type clarity is inconsistent. The 'limit' and 'offset' parameters in 'getv2attributes' are typed as 'number' with no minimum/maximum bounds specified in descriptions. Should 'limit' be 1 - 100? 0 - 1000? Can offset exceed the total? Unbounded numeric parameters allow LLMs to pass absurd values.