Skip to main content
Glama
getmasv

masv

Official

get_packages

List team packages from MASV with pagination and filtering by status, name, sender, tags, creation and expiry dates, teamspaces, and extended storage.

Instructions

Get team packages. These are packages sent by MASV team users directly to MASV. It does not include packages sent to Portals. To get full list of packages you need to get both team packages and portal packages

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number of paginated response. First page is 1
limitNoNumber of records returned per page
sortNoSort results ascending (fieldname) or descending (-fieldname)
statusNoSelect packages with status. New - package is currently uploading and not ready for view/download yet, finalized - package was uploaded and is ready for download, view, or transfer to another storage destination, expired and archived means that package was deleted and files are not available anymore
nameNoFilter packages by name
senderNoFilter packages by sender email
tagsNoFilter packages by tag id. If any of provided tag ids match package will be returned
created_at_startNoRetrieve records that were created after (YYYY-MM-DDTHH:mm:SS)
created_at_endNoRetrieve records that were created before (YYYY-MM-DDTHH:mm:SS)
teamspacesNoRetrieve records where teamspace id is equal to one of these values
expiry_startNoRetrieve records that expire after (YYYY-MM-DDTHH:mm:SS)
expiry_endNoRetrieve records that expire before (YYYY-MM-DDTHH:mm:SS)
extra_storageNoIf true, will only include packages which will or have already incurred extended storage costs

Implementation Reference

  • The core handler function for the get_packages tool. Makes a GET request to the MASV API endpoint `/v1.1/teams/{teamId}/packages` with query parameters for filtering and pagination.
    async function getPackages({ page, ...params }: GetPackagesParams) {
      const url = new URL(`${MASV_BASE_URL}/v1.1/teams/${MASV_TEAM_ID}/packages`);
    
      Object.entries(params).forEach(([key, value]) => {
        if (value !== undefined) {
          url.searchParams.append(key, String(value));
        }
      });
    
      const headers = {
        "content-type": "application/json",
        "x-api-key": MASV_API_KEY,
      };
    
      const r = await fetch(url.toString(), { headers });
      const data = await r.json();
    
      return data;
    }
  • Zod schema defining the input parameters for get_packages, with fields for pagination (page, limit), sorting, status filtering, name, sender, tags, date ranges, teamspaces, and extra_storage flag.
    const GetPackagesSchema = z.object({
      page: z
        .number()
        .min(1)
        .describe("Page number of paginated response. First page is 1")
        .optional(),
      limit: z
        .number()
        .min(1)
        .max(100)
        .describe("Number of records returned per page")
        .optional(),
      sort: z
        .string()
        .describe("Sort results ascending (fieldname) or descending (-fieldname)")
        .optional(),
      status: z
        .array(z.enum(["new", "finalized", "expired", "archived"]))
        .describe(
          "Select packages with status. New - package is currently uploading and not ready for view/download yet, finalized - package was uploaded and is ready for download, view, or transfer to another storage destination, expired and archived means that package was deleted and files are not available anymore",
        )
        .optional(),
      name: z.string().describe("Filter packages by name").optional(),
      sender: z.string().describe("Filter packages by sender email").optional(),
      tags: z
        .array(z.string())
        .describe(
          "Filter packages by tag id. If any of provided tag ids match package will be returned",
        )
        .optional(),
      created_at_start: z
        .string()
        .describe("Retrieve records that were created after (YYYY-MM-DDTHH:mm:SS)")
        .optional(),
      created_at_end: z
        .string()
        .describe("Retrieve records that were created before (YYYY-MM-DDTHH:mm:SS)")
        .optional(),
      teamspaces: z
        .array(z.string())
        .describe(
          "Retrieve records where teamspace id is equal to one of these values",
        )
        .optional(),
      expiry_start: z
        .string()
        .describe("Retrieve records that expire after (YYYY-MM-DDTHH:mm:SS)")
        .optional(),
      expiry_end: z
        .string()
        .describe("Retrieve records that expire before (YYYY-MM-DDTHH:mm:SS)")
        .optional(),
      extra_storage: z
        .boolean()
        .describe(
          "If true, will only include packages which will or have already incurred extended storage costs",
        )
        .optional(),
    });
  • src/index.ts:68-83 (registration)
    Registration of the 'get_packages' tool with the MCP server, binding the schema and handler into the tool system.
    server.registerTool(
      "get_packages",
      {
        description:
          "Get team packages. These are packages sent by MASV team users directly to MASV. It does not include packages sent to Portals. To get full list of packages you need to get both team packages and portal packages",
        inputSchema: GetPackagesSchema.shape,
      },
      async (args) => {
        try {
          const data = await getPackages(args);
    
          return mcpOk(data);
        } catch (error) {
          return mcpError(error);
        }
      },
  • Environment helper providing MASV_BASE_URL, MASV_TEAM_ID, and MASV_API_KEY used by the getPackages handler to construct the API request.
    export const MASV_BASE_URL = process.env.MASV_BASE_URL || "https://api.massive.app";
    export const MASV_TEAM_ID = process.env.MASV_TEAM_ID;
    export const MASV_API_KEY = process.env.MASV_API_KEY;
    export const MASV_ALLOW_DELETE = process.env.MASV_ALLOW_DELETE === "true";
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool excludes portal packages, which is a key behavioral trait. However, it does not mention pagination behavior, rate limits, or authentication requirements, though the name implies 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 the core purpose. Every sentence adds value with no wasted words.

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 13 parameters and no output schema, the description is minimal. It explains the scope and the need to combine with portal packages, but does not provide any hints on return format, error cases, or pagination behavior. Schema covers filters well, but overall context is just adequate.

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 baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides.

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 clearly states the tool gets 'team packages' and defines them as packages sent by MASV team users directly to MASV. It distinguishes from portal packages, which are listed as a sibling tool (get_portal_packages).

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 explicitly tells the agent when to use this tool vs alternatives: 'To get full list of packages you need to get both team packages and portal packages', indicating that get_packages alone is insufficient and must be combined with the sibling 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/getmasv/masv-mcp-server'

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