Skip to main content
Glama

marketo_get_emails

Retrieve Marketo email assets with pagination and status filtering. Get subject line, from address, and folder metadata for approved or draft emails.

Instructions

List email assets in Marketo. Supports pagination via maxReturn/offset and filtering by status (approved/draft). Returns email metadata including subject line, from address, and folder.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
maxReturnNoMax emails to return (1-200, default 20)
offsetNoPagination offset
statusNoFilter by approval status

Implementation Reference

  • Handler function for marketo_get_emails tool. Builds query params (maxReturn, offset, status) and makes a GET request to the Marketo Asset API /rest/asset/v1/emails.json endpoint. Returns email metadata or an error.
      async (args) => {
        try {
          const params: Record<string, unknown> = {};
          if (args.maxReturn) params.maxReturn = args.maxReturn;
          if (args.offset) params.offset = args.offset;
          if (args.status) params.status = args.status;
          return ok(await makeRequest("/rest/asset/v1/emails.json", "GET", params));
        } catch (e) { return err(e); }
      }
    );
  • Zod schema for marketo_get_emails input parameters: maxReturn (number), offset (number), status (enum: approved|draft), all optional.
    {
      maxReturn: z.number().optional().describe("Max emails to return (1-200, default 20)"),
      offset: z.number().optional().describe("Pagination offset"),
      status: z.enum(["approved", "draft"]).optional().describe("Filter by approval status"),
    },
  • Registration of the marketo_get_emails tool on the MCP server with its name and description.
    server.tool(
      "marketo_get_emails",
      "List email assets in Marketo. Supports pagination via maxReturn/offset and filtering by status (approved/draft). Returns email metadata including subject line, from address, and folder.",
  • Helper makeRequest function used by the handler to perform authenticated HTTP requests to the Marketo API. Handles token injection, query params for GET, body for POST, and Marketo error extraction.
    export async function makeRequest<T = unknown>(
      endpoint: string,
      method: Method = "GET",
      data?: unknown,
      contentType?: string,
    ): Promise<T> {
      const token = await getAccessToken();
      const config: AxiosRequestConfig = {
        url: `${MARKETO_BASE_URL}${endpoint}`,
        method,
        headers: {
          Authorization: `Bearer ${token}`,
          ...(contentType ? { "Content-Type": contentType } : {}),
        },
        ...(data && method !== "GET" ? { data } : {}),
        ...(data && method === "GET" ? { params: data } : {}),
      };
    
      const res = await axios(config);
      const body = res.data;
    
      // Marketo REST API returns errors inside the response body
      if (body?.errors?.length) {
        const e = body.errors[0];
        throw new MarketoError(`${e.code}: ${e.message}`, res.status);
      }
    
      return body as T;
    }
  • Auth helper that obtains and caches a Marketo OAuth2 token using client credentials, used by makeRequest.
    export async function getAccessToken(): Promise<string> {
      const now = Date.now();
      if (cachedToken && now < tokenExpiresAt) {
        return cachedToken;
      }
    
      const url = `${MARKETO_BASE_URL}/identity/oauth/token`;
      const res = await axios.get(url, {
        params: {
          grant_type: "client_credentials",
          client_id: MARKETO_CLIENT_ID,
          client_secret: MARKETO_CLIENT_SECRET,
        },
      });
    
      const { access_token, expires_in } = res.data;
      cachedToken = access_token;
      // Refresh 60s before actual expiry
      tokenExpiresAt = now + (expires_in - 60) * 1000;
      return access_token;
    }
Behavior4/5

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

No annotations, so description bears full burden. It discloses pagination support, filtering behavior, and return content (subject, from, folder). Could mention ordering or default behavior, but overall transparent for a read 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?

Two sentences, front-loaded with purpose, followed by key details. No unnecessary words.

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?

For a simple list tool with no output schema, the description covers purpose, parameters, and return content (metadata fields). Complete and sufficient.

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 100% of parameters with descriptions. Description adds context for pagination and status filtering, but does not significantly supplement schema beyond that. 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 'List email assets in Marketo' with specific verb and resource. It distinguishes from sibling tools like those for leads, programs, or forms.

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 explicit guidance on pagination (maxReturn/offset) and filtering by status (approved/draft), which helps the agent know when to use these parameters. No explicit when-not-to-use, but adequate for a listing tool.

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/ZLeventer/marketo-mcp-server'

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