Skip to main content
Glama
dragonkhoi

Ramp MCP

get_ramp_statements

Retrieve Ramp financial statements with date filtering and pagination options to access transaction data efficiently.

Instructions

Retrieve Ramp statements with optional date filtering and pagination.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
from_dateNoStart date in ISO format (YYYY-MM-DD)
to_dateNoEnd date in ISO format (YYYY-MM-DD)
startNoToken for pagination
page_sizeNoNumber of results per page

Implementation Reference

  • The core handler logic that builds the Ramp API URL with input parameters, authenticates using context.accessToken, fetches statements, handles HTTP errors, and returns the parsed JSON data.
    handler: async (input, context) => {
      // Build URL with query parameters
      const url = new URL("https://api.ramp.com/developer/v1/statements");
      
      // Add query parameters if provided
      Object.entries(input).forEach(([key, value]) => {
        if (value !== undefined) {
          url.searchParams.append(key, String(value));
        }
      });
    
      // Set up request options
      const options = {
        method: "GET",
        headers: {
          accept: "application/json",
          authorization: `Bearer ${context.accessToken}`,
        },
      };
    
      // Make the API request
      const response = await fetch(url.toString(), options);
    
      if (!response.ok) {
        const errorText = await response.text();
        throw new Error(
          `HTTP error! status: ${response.status} - ${errorText}`
        );
      }
    
      const data = await response.json();
      return data;
    },
  • Zod-based input schema defining optional parameters for date range filtering and pagination.
    inputSchema: {
      from_date: z.string().optional().describe("Start date in ISO format (YYYY-MM-DD)"),
      to_date: z.string().optional().describe("End date in ISO format (YYYY-MM-DD)"),
      start: z.string().optional().describe("Token for pagination"),
      page_size: z.number().optional().describe("Number of results per page")
    },
  • Tool definition and export using defineTool, specifying name, description, schema, and handler for the get_ramp_statements tool.
    export const GET_RAMP_STATEMENTS_TOOL = defineTool<any, RampContext>((z) => ({
      name: "get_ramp_statements",
      description: "Retrieve Ramp statements with optional date filtering and pagination.",
      inputSchema: {
        from_date: z.string().optional().describe("Start date in ISO format (YYYY-MM-DD)"),
        to_date: z.string().optional().describe("End date in ISO format (YYYY-MM-DD)"),
        start: z.string().optional().describe("Token for pagination"),
        page_size: z.number().optional().describe("Number of results per page")
      },
      handler: async (input, context) => {
        // Build URL with query parameters
        const url = new URL("https://api.ramp.com/developer/v1/statements");
        
        // Add query parameters if provided
        Object.entries(input).forEach(([key, value]) => {
          if (value !== undefined) {
            url.searchParams.append(key, String(value));
          }
        });
    
        // Set up request options
        const options = {
          method: "GET",
          headers: {
            accept: "application/json",
            authorization: `Bearer ${context.accessToken}`,
          },
        };
    
        // Make the API request
        const response = await fetch(url.toString(), options);
    
        if (!response.ok) {
          const errorText = await response.text();
          throw new Error(
            `HTTP error! status: ${response.status} - ${errorText}`
          );
        }
    
        const data = await response.json();
        return data;
      },
    })); 
  • src/index.ts:55-60 (registration)
    Final registration of the tool with the MCP server after applying context with access token.
    server.tool(
      statementsTool.name,
      statementsTool.description,
      statementsTool.inputSchema,
      statementsTool.handler
    );
  • Generic helper utility for defining MCP tools with type-safe Zod schemas, context injection, standardized error responses, and MCP CallToolResult formatting.
    export const defineTool = <TInputSchema extends z.ZodRawShape, TContext extends ToolContext = ToolContext>(
      cb: (zod: typeof z) => ToolDefinition<TInputSchema, TContext>
    ) => {
      const tool = cb(z);
    
      const wrappedHandler = async (
        input: InferToolHandlerInput<TInputSchema>,
        extra: RequestHandlerExtra,
        context: TContext
      ): Promise<CallToolResult> => {
        try {
          const result = await tool.handler(input, context);
          return {
            content: [
              {
                type: "text",
                text: JSON.stringify(result, null, 2),
              },
            ],
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text",
                text: `Error: ${error instanceof Error ? error.message : String(error)}`,
              },
            ],
            isError: true,
          };
        }
      };
    
      return {
        ...tool,
        handler: (input: InferToolHandlerInput<TInputSchema>, extra: RequestHandlerExtra) => 
          wrappedHandler(input, extra, {} as TContext),
        withContext: (context: TContext) => ({
          ...tool,
          handler: (input: InferToolHandlerInput<TInputSchema>, extra: RequestHandlerExtra) => 
            wrappedHandler(input, extra, context),
        }),
      };
    };
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'optional date filtering and pagination', which hints at querying behavior, but it doesn't cover critical aspects like rate limits, authentication needs, error handling, or what the return format looks like (e.g., list of statements, total count). This leaves significant gaps for a tool with no annotation support.

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 front-loads the core purpose and key features without any wasted words. It's appropriately sized for the tool's complexity, making it easy to parse quickly.

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?

Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and hints at functionality, but lacks details on behavioral traits, output format, and differentiation from siblings. This makes it minimally viable but with clear gaps that could hinder effective tool selection and invocation.

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?

The schema description coverage is 100%, with all parameters well-documented in the input schema (e.g., date formats, pagination details). The description adds value by summarizing the optional features ('date filtering and pagination'), but it doesn't provide additional semantic context beyond what the schema already specifies, such as default behaviors or constraints not in the schema.

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 'Ramp statements', making the purpose specific and understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_credit_card_transactions', which might retrieve similar financial data but for different resources, leaving some ambiguity about when to choose one over the other.

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 mentions 'optional date filtering and pagination', which implies some usage context, but it doesn't provide explicit guidance on when to use this tool versus the sibling 'get_credit_card_transactions' or any alternatives. No exclusions or specific scenarios are outlined, leaving the agent with minimal direction.

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/dragonkhoi/ramp-mcp'

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