Skip to main content
Glama
plutzilla

Omnisend MCP Server

getContact

Retrieve detailed contact information from the Omnisend marketing platform using a unique identifier to access customer data for management and tracking purposes.

Instructions

Retrieve detailed information about a specific contact by their unique identifier.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The handler function that executes the logic for the 'getContact' MCP tool. It calls the API helper, filters the contact data, formats it as JSON, and handles errors by returning text content.
    async (args) => {
      try {
        const response = await getContact(args.contactId);
        
        // Filter contact data to include only defined fields
        const filteredContact = filterContactFields(response);
        
        return {
          content: [
            { 
              type: "text", 
              text: JSON.stringify(filteredContact, null, 2) 
            }
          ]
        };
      } catch (error) {
        if (error instanceof Error) {
          return { content: [{ type: "text", text: `Error: ${error.message}` }] };
        }
        return { content: [{ type: "text", text: "An unknown error occurred" }] };
      }
    }
  • JSON Schema defining the input parameters for the getContact tool, which requires a single 'contactId' string.
    {
      additionalProperties: false,
      properties: {
        contactId: { description: "Contact ID", type: "string" }
      },
      required: ["contactId"],
      type: "object"
  • The server.tool call that registers the 'getContact' tool on the MCP server, including the tool name, description, input schema, and handler function.
    server.tool(
      "getContact",
      "Retrieve detailed information about a specific contact by their unique identifier.",
      {
        additionalProperties: false,
        properties: {
          contactId: { description: "Contact ID", type: "string" }
        },
        required: ["contactId"],
        type: "object"
      },
      async (args) => {
        try {
          const response = await getContact(args.contactId);
          
          // Filter contact data to include only defined fields
          const filteredContact = filterContactFields(response);
          
          return {
            content: [
              { 
                type: "text", 
                text: JSON.stringify(filteredContact, null, 2) 
              }
            ]
          };
        } catch (error) {
          if (error instanceof Error) {
            return { content: [{ type: "text", text: `Error: ${error.message}` }] };
          }
          return { content: [{ type: "text", text: "An unknown error occurred" }] };
        }
      }
    );
  • Helper function from api-resources that performs the actual Omnisend API GET request to fetch a contact by ID and returns the Contact object.
    export const getContact = async (contactId: string): Promise<Contact> => {
      try {
        const response = await omnisendApi.get<Contact>(`/contacts/${contactId}`);
        return response.data;
      } catch (error) {
        if (error instanceof Error) {
          throw new Error(`Error getting contact information: ${error.message}`);
        } else {
          throw new Error('Unknown error occurred when getting contact');
        }
      }
    };
  • Helper utility function that filters and selects specific fields from the raw contact data for safe exposure in tool responses.
    export const filterContactFields = (contact: any) => {
      return {
        contactID: contact.contactID,
        email: contact.email,
        phone: contact.phone,
        firstName: contact.firstName,
        lastName: contact.lastName,
        status: contact.status,
        tags: contact.tags,
        identifiers: contact.identifiers,
        createdAt: contact.createdAt,
        updatedAt: contact.updatedAt,
        // Include added fields
        country: contact.country,
        state: contact.state,
        city: contact.city,
        gender: contact.gender,
        birthdate: contact.birthdate
      };
    }; 
Behavior2/5

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 retrieval operation, implying read-only behavior, but doesn't mention authentication needs, rate limits, error conditions, or what 'detailed information' includes. The description is minimal and lacks behavioral context beyond the basic operation.

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 directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word contributing to understanding the operation.

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 retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential response formats, or error handling. Given the lack of structured data, the description should provide more context about the tool's behavior and outputs.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the mention of 'unique identifier' is contextual rather than parameter-specific. Baseline 4 is correct for zero-parameter tools.

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 verb ('Retrieve') and resource ('detailed information about a specific contact'), making the purpose understandable. It distinguishes from siblings like 'listContacts' by focusing on a single contact, but doesn't explicitly contrast with 'getCategory' or 'getProduct' which follow similar patterns.

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 when to use 'getContact' versus 'listContacts', or clarify that it requires a contact identifier (though implied by 'unique identifier'). No exclusions or prerequisites are stated.

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/plutzilla/omnisend-mcp'

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