Skip to main content
Glama
chezsmithy

Thunder Client License Manager MCP Server

by chezsmithy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Thunder Client License Manager MCP Server

An MCP (Model Context Protocol) server that provides tools for managing Thunder Client licenses through their API.

Features

  • Add licenses: Add Thunder Client licenses for specified email addresses

  • Get licenses: Retrieve license information with automatic pagination

  • Remove licenses: Remove Thunder Client licenses for specified email addresses

Related MCP server: Istek MCP Server

Requirements

  • Node.js 20+ (LTS)

  • TypeScript

  • Thunder Client API access

Installation

  1. Clone this repository

  2. Install dependencies:

    npm install

  3. Build the project:

    npm run build

Environment Variables

Before using the MCP server, you need to set the following environment variables:

  • TC_API_KEY: Your Thunder Client API key (sent as 'api-key' header)

  • TC_ACCOUNT_NUMBER: Your Thunder Client account number

  • TC_BASE_URL: (Optional) Base URL for Thunder Client API (defaults to 'https://www.thunderclient.com')

Example Environment Setup

export TC_API_KEY="your-api-key-here"
export TC_ACCOUNT_NUMBER="your-account-number"
export TC_BASE_URL="https://www.thunderclient.com"  # optional

MCP Configuration

Add the server to your MCP settings configuration:

For Cline/Claude Desktop

Add to your cline_mcp_settings.json or Claude Desktop configuration:

{
  "mcpServers": {
    "thunderclient-license-manager": {
      "command": "npx",
      "args": ["-y", "/path/to/thunderclient-license-manager-mcp"],
      "env": {
        "TC_API_KEY": "your-api-key-here",
        "TC_ACCOUNT_NUMBER": "your-account-number-here"
      }
    }
  }
}

For other MCP clients

Use the stdio transport with npx:

npx -y .

Available Tools

1. thunderclient_add_license

Add Thunder Client licenses for specified email addresses.

Parameters:

  • emails (required): Array of email addresses to add licenses for

Example:

{
  "emails": ["user1@example.com", "user2@example.com"]
}

2. thunderclient_get_licenses

Get Thunder Client licenses with smart pagination.

Parameters:

  • pageNumber (optional): Specific page to fetch. If omitted, fetches ALL pages automatically

Example - Get all licenses:

{}

Example - Get specific page:

{
  "pageNumber": 2
}

3. thunderclient_remove_license

Remove Thunder Client licenses for specified email addresses.

Parameters:

  • emails (required): Array of email addresses to remove licenses for

Example:

{
  "emails": ["user1@example.com", "user2@example.com"]
}

API Response Format

All tools return responses in the following format:

{
  "success": true/false,
  "data": { /* API response data */ },
  "message": "Success/error message",
  "error": "Error details (if success is false)"
}

Special Response for thunderclient_get_licenses without pageNumber

When fetching all pages, the response includes:

{
  "success": true,
  "data": {
    "licenses": [ /* Combined licenses from all pages */ ],
    "totalPages": 5,
    "totalCount": 150,
    "pagesFetched": 5
  },
  "message": "Retrieved 150 licenses across 5 page(s)"
}

Development

Scripts

  • npm run build: Compile TypeScript to JavaScript

  • npm run dev: Watch mode for development

  • npm start: Run the compiled server

Project Structure

src/
├── index.ts          # Main MCP server implementation
├── api-client.ts     # Thunder Client API wrapper
└── types.ts          # TypeScript type definitions

Error Handling

The server includes comprehensive error handling:

  • Environment variable validation

  • API request/response error handling

  • Input validation for required parameters

  • Proper MCP error codes and messages

License

MIT

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests if applicable

  5. Submit a pull request

Support

For issues related to the Thunder Client API, refer to their documentation. For MCP server issues, please create an issue in this repository.

Available Tools

3 tools
thunderclient_add_licenseC

Add Thunder Client licenses for specified email addresses

ParametersJSON Schema
NameRequiredDescriptionDefault
emailsYesArray of email addresses to add licenses for

TDQS

C2.9/5.0
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 'Add Thunder Client licenses', implying a write operation, but doesn't cover permissions required, whether it's idempotent, rate limits, error handling, or what happens on success (e.g., confirmation details). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, clear sentence with no wasted words, directly stating the tool's function. It's appropriately sized and front-loaded, making it easy to understand at a glance without unnecessary elaboration.

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 tool is a mutation (adding licenses) with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral traits like side effects. For a tool that modifies state, more context is needed to ensure safe and correct usage, making this inadequate for its complexity.

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 the 'emails' parameter fully documented in the schema as an array of email addresses with a minimum of 1 item. The description adds no additional parameter semantics beyond implying the emails are for license assignment. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add value beyond 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 action ('Add') and resource ('Thunder Client licenses') with the target ('specified email addresses'), making the purpose evident. It distinguishes from sibling tools like 'thunderclient_get_licenses' (read) and 'thunderclient_remove_license' (delete), but doesn't explicitly differentiate beyond the verb. The specificity is good but lacks explicit sibling comparison.

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 'thunderclient_get_licenses' or 'thunderclient_remove_license'. It doesn't mention prerequisites, such as whether licenses are available or if users must exist, nor does it specify scenarios like bulk onboarding. Without such context, usage is implied but not clearly defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

thunderclient_get_licensesA

Get Thunder Client licenses. If pageNumber is not provided, fetches all pages automatically.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNumberNoSpecific page number to fetch (optional, fetches all pages if omitted)

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the automatic pagination behavior when pageNumber is not provided, which isn't obvious from the schema. However, it doesn't cover other aspects like rate limits, authentication needs, or response format, leaving 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 extremely concise—just two sentences—with zero wasted words. It front-loads the core purpose and efficiently explains the key behavioral nuance regarding pagination, making it easy for an agent 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 low complexity (1 optional parameter, no output schema, no annotations), the description is adequate but not complete. It covers the main functionality and pagination behavior but lacks details on output format, error handling, or integration with sibling tools, which could help an agent use it more effectively.

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%, so the schema already fully documents the single parameter (pageNumber). The description adds minimal value by restating that omitting pageNumber fetches all pages, which is already implied in the schema's description. This meets the baseline for high schema coverage without significant enhancement.

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 ('Get') and resource ('Thunder Client licenses'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'thunderclient_add_license' or 'thunderclient_remove_license' beyond implying this is a read operation versus their write operations.

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 the automatic fetching of all pages when pageNumber is omitted, which suggests when to use this parameter. However, it lacks explicit guidance on when to choose this tool over siblings or any prerequisites, leaving the agent to infer based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

thunderclient_remove_licenseC

Remove Thunder Client licenses for specified email addresses

ParametersJSON Schema
NameRequiredDescriptionDefault
emailsYesArray of email addresses to remove licenses for

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Remove') but doesn't clarify if this is destructive, requires admin permissions, has side effects (e.g., revoking access), or what happens on success/failure. This leaves critical behavioral traits unspecified for a mutation tool.

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 directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.

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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, leaving significant gaps in understanding how to invoke it correctly and interpret results.

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 the parameter 'emails' fully documented in the schema as an array of email addresses. The description adds no additional semantic context beyond implying the emails are targets for license removal, so it meets the baseline of 3 without compensating for gaps.

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 ('Remove') and resource ('Thunder Client licenses') with the target ('for specified email addresses'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'thunderclient_add_license' beyond the verb, missing a direct comparison that would elevate it to 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 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 'thunderclient_add_license' or 'thunderclient_get_licenses'. It lacks context about prerequisites, such as whether licenses must exist or if this is for revoking access, leaving the agent without usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedthunderclient_add_license
    • First observedthunderclient_get_licenses
    • First observedthunderclient_remove_license
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: add, get, and remove licenses. The actions (add, get, remove) are mutually exclusive and target the same resource (licenses), leaving no room for confusion or overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with the prefix 'thunderclient_' and use clear action verbs (add, get, remove) followed by the noun 'license'. There are no deviations in style or convention.

Tool Count4/5

Three tools are appropriate for a license manager, covering core CRUD operations (add, get, remove). It is slightly under-scoped as it lacks an update tool, but the count is reasonable for the domain.

Completeness4/5

The tool set covers the essential lifecycle of license management: create (add), read (get), and delete (remove). A minor gap exists with no update tool for modifying existing licenses, but agents can work around this by removing and re-adding.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Istek MCP Server

    istekapp
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Enables AI assistants to interact with Istek API Client for managing workspaces, collections, environments, variables, and request history. Allows natural language control of API development workflows including creating collections, adding requests, and managing environment configurations.
    -

  • Linear MCP Server

    timottowitz
    A
    license
    B
    quality
    D
    maintenance
    Enables interaction with Linear's API to manage issues, projects, and teams. Supports creating, updating, searching, and deleting issues, along with project management and team operations through API key authentication.
    13
    210 npm
    MIT