Skip to main content
Glama
kesslerio

Attio MCP Server

by kesslerio

discover-attributes

Read-onlyIdempotent

Find available attributes for Attio CRM resources including companies, people, lists, records, and tasks to understand data structure and available fields.

Instructions

Discover available attributes for any resource type

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoriesNoAttribute categories
resource_typeYesType of resource to operate on (companies, people, lists, records, tasks)

Implementation Reference

  • Core handler function that fetches and formats attributes for a given resource_type by querying the Attio /v2/objects/{slug}/attributes API endpoint.
    export async function handleDiscoverAttributes(
      client: HttpClient,
      params: {
        resource_type: ResourceType;
        categories?: string[];
      }
    ): Promise<ToolResult> {
      try {
        const { resource_type, categories } = params;
        const objectSlug = getObjectSlug(resource_type);
    
        const response = await client.get<
          AttioApiResponse<
            Array<{
              api_slug: string;
              title: string;
              type: string;
              is_required: boolean;
            }>
          >
        >(`/v2/objects/${objectSlug}/attributes`);
    
        let attributes = response.data.data;
    
        // Filter by categories if provided
        if (categories && categories.length > 0) {
          // This is a simplified filter - the actual API might have different category handling
          attributes = attributes.filter((attr) =>
            categories.some((cat) =>
              attr.type?.toLowerCase().includes(cat.toLowerCase())
            )
          );
        }
    
        if (attributes.length === 0) {
          return structuredResult([], `No attributes found for ${resource_type}`);
        }
    
        const lines = attributes.map((attr) => {
          const required = attr.is_required ? ' (required)' : '';
          return `- ${attr.api_slug}: ${attr.type}${required} - ${attr.title}`;
        });
    
        return structuredResult(
          attributes,
          `Attributes for ${resource_type}:\n${lines.join('\n')}`
        );
      } catch (error) {
        const { message, details } = extractErrorInfo(error);
        return errorResult(message || 'Failed to discover attributes', details);
      }
    }
  • JSON Schema and description definition for the records_discover_attributes tool, including input parameters and usage hints.
    export const discoverAttributesDefinition: ToolDefinition = {
      name: 'records_discover_attributes',
      description: formatDescription({
        capability:
          'Discover available attributes (standard/custom) for a resource, including their types',
        boundaries: 'alter schema or create fields',
        constraints:
          'Requires resource_type; optional categories selects subsets. Returns attribute types like text, select, actor-reference, record-reference, etc. Actor-reference fields (e.g., owner) require special filter handling.',
        recoveryHint:
          'Use this tool first to understand attribute types before filtering',
      }),
      inputSchema: {
        type: 'object',
        properties: {
          resource_type: RESOURCE_TYPE_SCHEMA,
          categories: {
            type: 'array',
            items: { type: 'string' },
            description:
              'Attribute categories to filter by (e.g., standard, custom)',
          },
        },
        required: ['resource_type'],
      },
      annotations: {
        readOnlyHint: true,
      },
    };
  • Dispatch registration mapping 'records_discover_attributes' tool name to the handleDiscoverAttributes implementation.
    records_discover_attributes: async (client, params) =>
      handleDiscoverAttributes(
        client,
        params as Parameters<typeof handleDiscoverAttributes>[1]
      ),
  • Tool alias registration mapping the queried name 'discover-attributes' to the canonical 'records_discover_attributes' tool.
    'discover-attributes': {
      target: 'records_discover_attributes',
      reason: 'Phase 1 search tool rename (#776)',
      since: SINCE_PHASE_1,
      removal: 'v1.x (TBD)',
  • Export registration of the discoverAttributesDefinition in the coreToolDefinitions registry.
    records_discover_attributes: discoverAttributesDefinition,
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, repeatable read operation. The description adds the scope of 'any resource type' and implies a cataloging function, which provides useful context beyond annotations. However, it doesn't describe behavioral details like response format, pagination, or error conditions that would be helpful for a discovery tool.

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 immediately conveys the core function. Every word earns its place with no redundancy or fluff. It's appropriately sized for a simple discovery tool and front-loads the essential information without unnecessary elaboration.

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?

For a read-only, idempotent discovery tool with good annotations and full schema coverage, the description is minimally adequate. However, without an output schema, the description doesn't explain what the discovery results look like (e.g., attribute names, types, metadata). Given the tool's purpose of revealing available attributes, more information about the return format would be beneficial for contextual 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 description coverage is 100%, so the schema fully documents both parameters. The description mentions 'resource type' which aligns with the schema's enum, but adds no additional semantic context about parameter usage, relationships, or constraints beyond what's already in the structured schema. With complete schema coverage, the baseline score of 3 is appropriate.

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 tool's purpose as discovering available attributes for resource types, using specific verbs ('discover') and resources ('attributes', 'resource type'). It distinguishes from siblings like 'get-attributes' by emphasizing discovery of what's available rather than retrieving specific attribute data. However, it doesn't explicitly contrast with 'get-attributes' in the description text itself.

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 doesn't mention sibling tools like 'get-attributes' or explain scenarios where discovering available attributes is preferable to directly retrieving attribute data. There's no context about prerequisites, timing, or exclusions for usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/kesslerio/attio-mcp-server'

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