Skip to main content
Glama

Metadata MCP Connector

Upload Contact List CSV and Create Contact List Audience

upload_contact_list_csv_audience

Upload a list of individual CONTACTS (people) as a Contact List CSV and create a CONTACT_LIST audience on the Metadata platform.

            ALSO KNOWN AS: "CSV Upload - Contacts", "Contacts List", "Contact List CSV", "CSV Contacts audience", "CSV Upload - Contacts List Audience".

            AUDIENCE TYPE: Contact List / CSV Upload - Contacts.
            This tool is ONLY for contact/people-level data (email, first name, last name, job title, etc.).
            Do NOT use this tool for company/account-level data (company names and websites) — use upload_account_list_csv_audience instead.

            This tool performs a two-step process:
            1. Generates a Contact List CSV file from the provided contact data and uploads it.
            2. Creates a CONTACT_LIST audience using the uploaded contact list file.

            WHEN TO USE:
            - "Create a CSV Upload - Contacts with the list"
            - "CSV Upload - Contacts"
            - "Create a contacts list audience"
            - "Upload these contacts as an audience"
            - "Create a contact list audience from these people"
            - "I have a list of emails and names, create an audience"
            - "Build a contact list audience"
            - "Upload contact list CSV"
            - When the data contains people-level fields: email, first name, last name, job title, company, country

            WHEN NOT TO USE:
            - When the user wants to upload company accounts (company name + website) — use upload_account_list_csv_audience.
            - When the data is account/company-level, not contact/people-level.

            WORKFLOW:
            1. Provide the audience name and an array of contact objects.
            2. The tool generates a CSV with the header: email,firstname,lastname,jobtitle,employeecompany,country,appleidfa,googleaid
            3. Uploads the CSV, then creates the CONTACT_LIST audience.

            CRITICAL — DATA MAPPING RULES (READ CAREFULLY BEFORE CALLING THIS TOOL):

            The "contacts" parameter is a JSON array of objects. Each object represents one contact/person
            and MUST use these exact field names:

              - "email"             → The contact's email address (REQUIRED per contact)
              - "firstname"         → The contact's first name
              - "lastname"          → The contact's last name
              - "jobtitle"          → The contact's job title / role
              - "employeecompany"   → The company the contact works at
              - "country"           → The contact's country
              - "appleidfa"         → Apple IDFA (advertising identifier), optional
              - "googleaid"         → Google Advertising ID, optional

            Example:
              [
                {
                  "email": "jane@metadata.io",
                  "firstname": "Jane",
                  "lastname": "Johnson",
                  "jobtitle": "Marketing Manager",
                  "employeecompany": "Metadata.io",
                  "country": "United States",
                  "appleidfa": "EA7583CD-A667-48BC-B806-42ECB2B48606",
                  "googleaid": ""
                },
                {
                  "email": "john@metadata.io",
                  "firstname": "John",
                  "lastname": "Johnson",
                  "jobtitle": "Marketing Manager",
                  "employeecompany": "Metadata.io",
                  "country": "United States",
                  "appleidfa": "",
                  "googleaid": "cdda802e-fb9c-47ad-9866-0794d394c912"
                }
              ]

            IF THE USER PROVIDES A FILE (CSV, XLSX, spreadsheet, or any tabular data):
              1. You MUST first read and inspect the file contents.
              2. Identify which columns map to: email, firstname, lastname, jobtitle, employeecompany, country, appleidfa, googleaid.
                 - The columns may NOT be literally named as above. They could be named:
                   "Email Address", "E-mail", "First Name", "First", "Last Name", "Surname",
                   "Job Title", "Title", "Role", "Position", "Company", "Organization", "Employer",
                   "Country", "Location", "Apple IDFA", "IDFA", "Google AID", "GAID", or any variation.
                 - Use your best judgment to map the correct columns to the expected field names.
                 - If ambiguous, ask the user to clarify which column maps to which field.
              3. Extract every row from the file and build the contacts array yourself,
                 mapping each column value to the correct field name.
              4. Do NOT pass raw file contents, column headers, or file paths — always transform into
                 the array-of-objects format described above.
              5. Skip rows where email is empty/missing (email is the minimum required field per contact).
              6. For any field not present in the source data, omit it or pass an empty string.
              7. If the file has no identifiable email column, ask the user which column contains emails.

            DO NOT:
              - Use the source file's column names as field names — always normalize to: email, firstname, lastname, jobtitle, employeecompany, country, appleidfa, googleaid.
              - Send the raw file path or file bytes — extract the data and build the array.
              - Confuse this with account/company uploads — this is for PEOPLE, not companies.

            TWO WAYS TO SUPPLY THE CONTACTS — provide EXACTLY ONE of:
              • `contacts`: an inline JSON array of contact objects. Use this for short ad-hoc lists you have already parsed into context.
              • `contacts_source_csv_url`: a public URL of a CSV file with header EXACTLY `email,firstname,lastname,jobtitle,employeecompany,country,appleidfa,googleaid` (case-insensitive, whitespace-trimmed). Use this WHENEVER THE USER ATTACHED A CSV to the chat — the URL is surfaced to you via `AudienceBrief.attached_file_urls`; pass it through verbatim. The MCP server downloads + validates + uploads the file without the rows ever travelling through your LLM context (essential for 100k+ row contact files).
            If both are provided, or neither, the tool errors with a clear message — pick one.

            CSV-URL HEADER RULES (when you choose the `contacts_source_csv_url` path):
              - First row of the CSV MUST be exactly `email,firstname,lastname,jobtitle,employeecompany,country,appleidfa,googleaid` (case-insensitive).
              - Rows with an empty email are dropped server-side before counting.
              - The 300–300,000 row limit is enforced on the post-filter count.
              - The server enforces a 50 MB cap on the downloaded file.

            PARAMETERS:
            - audience_name: Name for the new contact list audience (required)
            - contacts: Array of contact objects (optional, mutually exclusive with contacts_source_csv_url).
              At minimum each contact must have "email". All other fields are optional but recommended.
            - contacts_source_csv_url: URL of a contacts CSV with the canonical 8-column header (optional, mutually exclusive with contacts).

            RETURNS:
            - success: Whether the operation completed successfully
            - audience_name: The name of the created audience
            - audience_type: CONTACT_LIST
            - file_id: The ID of the uploaded contact list file
            - contacts_count: Number of contacts processed by the backend
            - contacts_provided: Number of contacts sent in the request

            IMPORTANT NOTES:
            - CONTACT LIMITS: Minimum 300 contacts, maximum 300,000 contacts.
            - Email is the minimum required field per contact — contacts without email are dropped.
            - The audience type created is CONTACT_LIST, distinct from Account List CSV (FIRMOGRAPHIC_INCLUDE).
            - appleidfa and googleaid are optional mobile advertising identifiers — leave empty if not available.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contactsNoInline array of contact objects (optional). Each object represents one person/contact with fields: email (required), firstname, lastname, jobtitle, employeecompany, country, appleidfa, googleaid. Minimum 300 contacts, maximum 300,000 contacts. MUTUALLY EXCLUSIVE with `contacts_source_csv_url` — provide exactly one.
audience_nameYesName for the new contact list audience (required).
contacts_source_csv_urlNoPublic URL of a contacts CSV file with header EXACTLY `email,firstname,lastname,jobtitle,employeecompany,country,appleidfa,googleaid` (case-insensitive). The MCP server downloads, validates, and uploads the file. Use this when the user attached a CSV to the chat — the URL is surfaced via `AudienceBrief.attached_file_urls`. MUTUALLY EXCLUSIVE with `contacts`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already indicate it is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), so the description goes far beyond by disclosing the two-step process (generate/upload CSV then create audience), constraints (min 300, max 300,000 rows, 50 MB cap), server-side row dropping for empty emails, and precise data mapping rules. This is rich behavioral context not available in 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 structured with clear headers and front-loaded purpose, but it is very long (over 1000 words). Some repetition exists (e.g., the 'DO NOT' section repeats points from the mapping rules). Nonetheless, the complexity justifies much of the detail, and the organized sections make it navigable. It earns a 4, not 5, due to occasional redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the description covers all necessary aspects: usage intent, input methods, data transformation rules, limits, return fields (since there is no output schema), and error conditions (mutual exclusivity). It is comprehensive enough for an agent to call it correctly without external references.

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?

Schema description coverage is 100%, yet the description adds significant meaning: it details the exact field names and normalization requirements for the contacts array, explains the mutual exclusivity of the two parameters, and specifies the CSV header rules. For contacts_source_csv_url, it clarifies the exact header format and that the server handles download/validation, which is not evident from the schema alone.

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 states a clear, specific action: 'Upload a list of individual CONTACTS (people) as a Contact List CSV and create a CONTACT_LIST audience on the Metadata platform.' It distinguishes itself from the sibling upload_account_list_csv_audience by explicitly stating 'Do NOT use this tool for company/account-level data — use upload_account_list_csv_audience instead.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit 'WHEN TO USE' and 'WHEN NOT TO USE' sections, listing concrete user intents and the alternative tool for account-level data. It also provides detailed guidance on the two input methods (inline JSON vs. CSV URL) and when to choose each, including the case of attached CSV files.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources