Skip to main content
Glama
BorisSolomonia

RS.ge Waybill MCP Server

get_waybills

Retrieve waybills from the RS.ge tax system for a specific date range. Optionally filter results by buyer TIN to find relevant tax documents.

Instructions

Get waybills from RS.ge for a specific date range. Returns all waybills created within the specified dates. Can optionally filter by buyer TIN.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
start_dateYesStart date in YYYY-MM-DD format (e.g., "2025-10-17")
end_dateYesEnd date in YYYY-MM-DD format (e.g., "2025-10-20")
buyer_tinNoOptional: Filter by buyer TIN (tax identification number)

Implementation Reference

  • Core handler function that executes the get_waybills tool: validates input with Zod, calls SOAP client.getWaybillsV1, formats waybills into readable text response.
    export async function executeGetWaybills(
      client: RsWaybillSoapClient,
      input: unknown
    ): Promise<string> {
      const logger = getLogger();
    
      try {
        // Validate input
        const validated = GetWaybillsInputSchema.parse(input);
    
        logger.info('Getting waybills', {
          startDate: validated.start_date,
          endDate: validated.end_date,
          buyerTin: validated.buyer_tin,
        });
    
        // Call SOAP API
        const waybills = await client.getWaybillsV1(
          validated.start_date,
          validated.end_date,
          validated.buyer_tin
        );
    
        logger.info(`Retrieved ${waybills.length} waybills`);
    
        // Format response for Claude
        if (waybills.length === 0) {
          return `No waybills found for date range ${validated.start_date} to ${validated.end_date}` +
            (validated.buyer_tin ? ` with buyer TIN ${validated.buyer_tin}` : '');
        }
    
        let response = `Found ${waybills.length} waybill(s) for ${validated.start_date} to ${validated.end_date}\n\n`;
    
        waybills.forEach((wb, index) => {
          response += `${index + 1}. Waybill #${wb.ID}\n`;
          response += `   Type: ${wb.TYPE}\n`;
          response += `   Buyer: ${wb.BUYER_TIN}${wb.BUYER_NAME ? ` (${wb.BUYER_NAME})` : ''}\n`;
    
          if (wb.SELLER_TIN) {
            response += `   Seller: ${wb.SELLER_TIN}\n`;
          }
    
          response += `   Status: ${wb.STATUS}\n`;
          response += `   Amount: ${wb.FULL_AMOUNT}\n`;
          response += `   Date: ${wb.CREATE_DATE || wb.BEGIN_DATE}\n`;
    
          if (wb.CAR_NUMBER) {
            response += `   Car: ${wb.CAR_NUMBER}\n`;
          }
    
          if (wb.END_ADDRESS) {
            response += `   Delivery: ${wb.END_ADDRESS}\n`;
          }
    
          response += '\n';
        });
    
        return response;
    
      } catch (error) {
        logger.error('Error in get_waybills tool', { error });
        return formatErrorForUser(error);
      }
    }
  • MCP tool definition including name, description, and inputSchema for get_waybills (JSON Schema). Zod schema GetWaybillsInputSchema is above at lines 15-25.
    export const getWaybillsTool = {
      name: 'get_waybills',
      description:
        'Get waybills from RS.ge for a specific date range. Returns all waybills ' +
        'created within the specified dates. Can optionally filter by buyer TIN.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          start_date: {
            type: 'string',
            description: 'Start date in YYYY-MM-DD format (e.g., "2025-10-17")',
            pattern: '^\\d{4}-\\d{2}-\\d{2}$',
          },
          end_date: {
            type: 'string',
            description: 'End date in YYYY-MM-DD format (e.g., "2025-10-20")',
            pattern: '^\\d{4}-\\d{2}-\\d{2}$',
          },
          buyer_tin: {
            type: 'string',
            description: 'Optional: Filter by buyer TIN (tax identification number)',
          },
        },
        required: ['start_date', 'end_date'],
      },
    };
  • src/index.ts:113-118 (registration)
    Registration of getWaybillsTool in the MCP server's listTools handler, conditionally based on feature flag.
    const tools = [];
    
    // Add tools based on feature flags
    if (features.getWaybills) {
      tools.push(getWaybillsTool);
    }
  • src/index.ts:149-154 (registration)
    Dispatch/execution routing for 'get_waybills' tool in the MCP server's callTool handler.
    case 'get_waybills':
      if (!features.getWaybills) {
        throw new Error('get_waybills tool is disabled');
      }
      result = await executeGetWaybills(soapClient, args);
      break;
  • Supporting SOAP client method getWaybillsV1 called by the tool handler to perform the actual 'get_waybills' API operation.
    async getWaybillsV1(
      startDate?: string,
      endDate?: string,
      buyerTin?: string
    ): Promise<Waybill[]> {
      // Validate date range
      if (!startDate || !endDate) {
        throw new SoapApiError(
          'Start date and end date are required. ' +
          'RS.ge API requires date ranges to be specified.'
        );
      }
    
      // Create and validate date range
      const dateRange = DateRange.create(startDate, endDate);
      const apiDates = dateRange.toApiFormat();
    
      // Extract seller_un_id from credentials (e.g., "4053098841:405309884" -> "405309884")
      const sellerUnId = this.credentials.user.includes(':')
        ? this.credentials.user.split(':')[1]
        : '';
    
      this.logger.info(`Querying waybills: ${dateRange.toString()}`);
    
      const response = await this.callSoap<GetWaybillsResponse>('get_waybills', {
        su: this.credentials.user,
        sp: this.credentials.password,
        seller_un_id: sellerUnId,
        create_date_s: apiDates.start,
        create_date_e: apiDates.end,
        buyer_tin: buyerTin || '',
      });
    
      const waybills = normalizeToArray(response.WAYBILL_LIST?.WAYBILL).map(normalizeWaybill);
    
      this.logger.info(`Received ${waybills.length} waybills from API`);
    
      return waybills;
    }
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 what the tool returns ('all waybills created within the specified dates') but lacks details on permissions, rate limits, pagination, error handling, or response format. For a read operation with zero annotation coverage, this is a significant gap.

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 concise and front-loaded with two sentences that efficiently convey the core functionality and optional filtering. Every sentence earns its place without redundancy or unnecessary details.

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?

Given the complexity (a read operation with date range and optional filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't explain the return values, format, or behavioral aspects like pagination or errors, which are crucial for effective tool use.

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 the schema already documents all parameters thoroughly. The description adds marginal value by reiterating the optional filter for buyer TIN, but it doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 tool's purpose with a specific verb ('Get') and resource ('waybills from RS.ge'), and it specifies the scope ('for a specific date range'). However, it doesn't explicitly distinguish this tool from its siblings (e.g., get_waybill_types), which would require a 5.

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

Usage Guidelines3/5

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

The description implies usage by mentioning 'for a specific date range' and 'can optionally filter by buyer TIN', but it doesn't provide explicit guidance on when to use this tool versus alternatives like get_waybill_types or lookup_tin. 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/BorisSolomonia/MCPWaybill'

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