Skip to main content
Glama
BorisSolomonia

RS.ge Waybill MCP Server

get_akciz_codes

Retrieve excise codes from the Georgian tax system for waybill processing. Filter results by search text to find specific codes.

Instructions

Get akciz (excise) codes from RS.ge system. Optionally filter by search text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
searchNoOptional search text to filter results

Implementation Reference

  • The core handler function that implements the get_akciz_codes tool logic: validates input, calls the SOAP client, formats results (limited to 20), handles errors.
    export async function executeGetAkcizCodes(
      client: RsWaybillSoapClient,
      input: unknown
    ): Promise<string> {
      const logger = getLogger();
    
      try {
        const validated = getAkcizCodesInputSchema.parse(input || {});
    
        logger.info('Getting akciz codes', { search: validated.search });
        const codes = await client.getAkcizCodes(validated.search);
    
        if (codes.length === 0) {
          return validated.search
            ? `No akciz codes found matching "${validated.search}"`
            : 'No akciz codes found';
        }
    
        let response = `Akciz Codes (${codes.length})`;
        if (validated.search) {
          response += ` matching "${validated.search}"`;
        }
        response += ':\n\n';
    
        codes.slice(0, 20).forEach((code: any) => {
          response += `- ${code.CODE}: ${code.NAME}`;
          if (code.DESCRIPTION) {
            response += ` - ${code.DESCRIPTION}`;
          }
          response += '\n';
        });
    
        if (codes.length > 20) {
          response += `\n... and ${codes.length - 20} more codes`;
        }
    
        return response;
    
      } catch (error) {
        logger.error('Error in get_akciz_codes tool', { error });
        return formatErrorForUser(error);
      }
    }
  • Zod schema for input validation in the get_akciz_codes handler.
    export const getAkcizCodesInputSchema = z.object({
      search: z.string()
        .optional()
        .describe('Optional search text to filter akciz codes'),
    });
  • src/index.ts:129-131 (registration)
    Registers the tool object in MCP listTools response if feature flag enabled.
    if (features.getAkcizCodes) {
      tools.push(getAkcizCodesTool);
    }
  • src/index.ts:177-182 (registration)
    Dispatches execution in MCP callTool handler, checks feature flag.
    case 'get_akciz_codes':
      if (!features.getAkcizCodes) {
        throw new Error('get_akciz_codes tool is disabled');
      }
      result = await executeGetAkcizCodes(soapClient, args);
      break;
  • Defines the MCP tool object including name, description, and input schema.
    export const getAkcizCodesTool = {
      name: 'get_akciz_codes',
      description:
        'Get akciz (excise) codes from RS.ge system. Optionally filter by search text.',
      inputSchema: {
        type: 'object' as const,
        properties: {
          search: {
            type: 'string',
            description: 'Optional search text to filter results',
          },
        },
        required: [],
      },
    };
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 states the tool 'Get[s] akciz (excise) codes,' implying a read-only operation, but doesn't disclose critical behavioral traits such as whether it requires authentication, rate limits, pagination, error handling, or what the return format looks like (e.g., list of objects). This leaves significant gaps for an AI agent to understand how to use it effectively.

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 appropriately sized and front-loaded: it starts with the core purpose and immediately follows with the optional filtering feature. Both sentences earn their place by providing essential information without redundancy or fluff, making it efficient and easy to parse.

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 lack of annotations and output schema, the description is incomplete for a tool with one parameter. It doesn't explain what the tool returns (e.g., structure of akciz codes, error responses), behavioral aspects like authentication needs, or how it differs from sibling tools. This leaves the AI agent with insufficient context to use the tool correctly beyond basic retrieval.

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 description adds minimal value beyond the input schema, which has 100% coverage. It mentions 'Optionally filter by search text,' aligning with the schema's 'search' parameter description ('Optional search text to filter results'). No additional semantic details (e.g., search syntax, case sensitivity) are provided. With high schema coverage, the baseline is 3, as the description doesn't compensate with extra insights.

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: 'Get akciz (excise) codes from RS.ge system.' It specifies the verb ('Get'), resource ('akciz codes'), and source ('RS.ge system'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_error_codes' or 'lookup_tin', which prevents a score of 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 provides implied usage guidance by mentioning 'Optionally filter by search text,' suggesting this tool is for retrieving codes with optional filtering. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'get_error_codes' or 'lookup_tin'), no exclusions, and no clear context for choosing among siblings, resulting in a moderate score.

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