Skip to main content
Glama
stier1ba

LicenseSpring MCP Server

by stier1ba

Deactivate License Offline

deactivate_offline

Deactivate a license for offline use by specifying the license key, hardware ID, and product code. Supports secure license management with LicenseSpring MCP Server.

Instructions

Deactivate a license for offline use with hardware ID and product code

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hardware_idYes
license_keyYes
productYes

Implementation Reference

  • The main handler function for the 'deactivate_offline' tool. It takes license_key, hardware_id, and product as input, constructs a requestData object, makes a POST request to the LicenseSpring API endpoint '/api/v4/deactivate_offline', and returns the JSON response or an error message.
    }, async ({ license_key, hardware_id, product }) => {
      try {
        const requestData = {
          license_key,
          hardware_id,
          product,
        };
        const response = await apiClient.post('/api/v4/deactivate_offline', requestData);
    
        return {
          content: [{
            type: 'text',
            text: JSON.stringify(response.data, null, 2),
          }],
        };
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: `Error deactivating license offline: ${handleApiError(error)}`,
          }],
          isError: true,
        };
      }
    });
  • Inline Zod schema defining the input parameters for the deactivate_offline tool.
    inputSchema: {
      license_key: z.string().min(1, 'License key is required'),
      hardware_id: z.string().min(1, 'Hardware ID is required'),
      product: z.string().min(1, 'Product code is required'),
    },
  • The server.registerTool call that registers the 'deactivate_offline' tool, including title, description, inputSchema, and inline handler function.
    server.registerTool('deactivate_offline', {
      title: 'Deactivate License Offline',
      description: 'Deactivate a license for offline use with hardware ID and product code',
      inputSchema: {
        license_key: z.string().min(1, 'License key is required'),
        hardware_id: z.string().min(1, 'Hardware ID is required'),
        product: z.string().min(1, 'Product code is required'),
      },
    }, async ({ license_key, hardware_id, product }) => {
      try {
        const requestData = {
          license_key,
          hardware_id,
          product,
        };
        const response = await apiClient.post('/api/v4/deactivate_offline', requestData);
    
        return {
          content: [{
            type: 'text',
            text: JSON.stringify(response.data, null, 2),
          }],
        };
      } catch (error) {
        return {
          content: [{
            type: 'text',
            text: `Error deactivating license offline: ${handleApiError(error)}`,
          }],
          isError: true,
        };
      }
    });
  • TypeScript interface defining the request shape for deactivate_offline, matching the inputSchema used in the tool registration.
    export interface DeactivateOfflineRequest {
      license_key: string;
      hardware_id: string;
      product: string;
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It implies a mutation ('deactivate') but doesn't specify whether this is reversible, requires specific permissions, has side effects, or returns any confirmation. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

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 states the core purpose without unnecessary words. It's appropriately sized for a tool with three parameters and no complex behavioral nuances to explain.

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?

For a mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain what happens after deactivation, error conditions, or how this differs from other deactivation methods. The agent lacks sufficient context to use this tool confidently.

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 mentions 'hardware ID and product code' which partially maps to two of the three parameters (hardware_id and product), but doesn't mention 'license_key'. With 0% schema description coverage and three required parameters, the description adds some value but doesn't fully compensate for the coverage gap, especially since license_key remains undocumented.

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 action ('deactivate') and resource ('a license for offline use'), making the purpose understandable. It distinguishes from sibling tools like 'deactivate_license' by specifying 'offline' context. However, it doesn't explicitly contrast with 'activate_offline' or other siblings beyond the verb difference.

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 provides no guidance on when to use this tool versus alternatives like 'deactivate_license' or 'activate_offline'. It mentions 'offline use' but doesn't explain scenarios where offline deactivation is preferred over online methods or prerequisites for using this 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

Related 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/stier1ba/licensespring-mcp'

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