Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ExisOne MCP Server Generate a license for jane@example.com for MyProduct Pro"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that enables AI assistants like Claude to manage software licenses through natural language commands.
This MCP server connects Claude Desktop to the ExisOne software licensing platform. Once configured, you can manage licenses using natural language:
"List all my products" - View your product catalog
"Show me all licenses" - List all license keys
"Generate a license for customer@email.com for MyProduct" - Create new keys
"Get details for license XXXX-XXXX-XXXX-XXXX" - View specific license info
No more clicking through dashboards - just ask Claude.
Related MCP server: Automox MCP Server
git clone https://github.com/exisllc/exisone-mcp.git
cd exisone-mcp
npm install
npm run buildLog in to ExisOne
Go to Access Tokens in the sidebar
Click Create Token
Name it "MCP Server" and select permissions: generate, verify
Copy the token (format: exo_at_xxx_yyy) - shown only once!
Edit your Claude Desktop config file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows example:
{
"mcpServers": {
"exisone": {
"command": "node",
"args": ["C:\\Users\\YOURNAME\\exisone-mcp\\dist\\index.js"],
"env": {
"EXISONE_API_URL": "https://www.exisone.com",
"EXISONE_ACCESS_TOKEN": "exo_at_YOUR_PUBLIC_ID_YOUR_SECRET",
"EXISONE_TENANT_ID": "1"
}
}
}
}macOS/Linux example:
{
"mcpServers": {
"exisone": {
"command": "node",
"args": ["/Users/yourname/exisone-mcp/dist/index.js"],
"env": {
"EXISONE_API_URL": "https://www.exisone.com",
"EXISONE_ACCESS_TOKEN": "exo_at_YOUR_PUBLIC_ID_YOUR_SECRET",
"EXISONE_TENANT_ID": "1"
}
}
}
}Replace:
The path with the actual path where you cloned the repo (use \\ for Windows, / for macOS/Linux)
EXISONE_ACCESS_TOKEN with your actual token
EXISONE_TENANT_ID with your tenant ID (visible in dashboard settings)
Important: You must fully quit Claude Desktop - closing the window is not enough as it continues running in the background.
Windows: Right-click the Claude icon in the system tray → Quit, or use Task Manager to end the "Claude" process
macOS: Right-click the dock icon → Quit, or use Cmd+Q
Reopen Claude Desktop and go to Settings → Developer to verify the ExisOne server appears in the list.
Tool | Description | Parameters |
| List all products for your tenant | None |
| List licenses with optional filters |
|
| Generate a new activation key |
|
| Get detailed license information |
|
List products:
"What products do I have in ExisOne?"
Generate a license:
"Create a 30-day license for john@example.com for MyApp Pro"
Check a license:
"Show me the details for license ABCD-1234-EFGH-5678"
Filter licenses:
"List all active licenses for MyApp"
Environment Variable | Required | Description |
| Yes | API URL (must be HTTPS). Default: |
| Yes | Your API token in format |
| Yes | Your tenant identifier |
| No | Request timeout in ms (default: 30000) |
Token Security: Store your access token securely. Never commit it to version control.
HTTPS Required: The MCP server validates that the API URL uses HTTPS.
Permission Scope: The server inherits permissions from your access token. Only grant needed permissions.
Tenant Isolation: Each token is scoped to a specific tenant.
Claude Desktop runs in the background even after closing the window. You must fully quit it:
Windows: Open Task Manager (Ctrl+Shift+Esc), find "Claude" and click "End Task"
Alternative: Right-click the Claude icon in the system tray (bottom-right corner) → Quit
Then reopen Claude Desktop
Go to Settings → Developer to check if the server is listed
Verify your config file path is correct for your OS
Check that the path to dist/index.js is absolute and correct
Make sure Claude Desktop is fully quit (not running in background) before restarting
Check Claude Desktop logs for error messages
Make sure all three environment variables are set in your Claude config:
EXISONE_API_URL
EXISONE_ACCESS_TOKEN
EXISONE_TENANT_ID
Verify your access token is correct and not expired
Check that the token has the required permissions (generate, verify)
Ensure the tenant ID matches your account
# Install dependencies
npm install
# Build TypeScript
npm run build
# Watch mode for development
npm run dev
# Type check without building
npm run typecheckexisone-mcp/
├── src/
│ ├── index.ts # Entry point with stdio transport
│ ├── server.ts # MCP server setup
│ ├── config.ts # Environment configuration
│ ├── api/
│ │ ├── client.ts # HTTP client for ExisOne API
│ │ └── types.ts # TypeScript interfaces
│ └── tools/
│ ├── index.ts # Tool registry
│ ├── list-products.ts
│ ├── list-licenses.ts
│ ├── generate-license.ts
│ └── get-license.ts
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdCreate a new file in src/tools/ (e.g., deactivate-license.ts)
Define the tool schema with name, description, and inputSchema
Implement the handler function
Register in src/tools/index.ts
Example:
export const myTool = {
name: "my_tool",
description: "What the tool does",
inputSchema: {
type: "object" as const,
properties: {
param1: { type: "string", description: "..." }
},
required: ["param1"]
}
};
export async function handleMyTool(args, client) {
// Implementation
return { content: [{ type: "text", text: "Result" }] };
}MIT License - see LICENSE file for details.
Generate a new activation key for a product. The license key will be created and can be sent to the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Customer email address | ||
| planId | No | Optional plan ID to determine validity period and features | |
| productName | Yes | Name of the product to generate the license for (must match exactly) | |
| validityDays | No | Number of days the license is valid. If not specified, uses product default. Use 0 for perpetual. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects itself. It does state that a license key will be created, but it is vague about whether the tool sends an email to the customer, what permissions are required, or what the response contains. 'Can be sent to the customer' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the primary action and outcome, and does not repeat schema details or annotate siblings unnecessarily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the definition should clarify the return value and any automatic side effects. The 100% parameter coverage and clear purpose make it minimally viable, but the ambiguous email behavior and missing response description leave clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters adequately. The description adds no parameter-specific behavior beyond calling the result an activation key, which is sufficient to meet the baseline but does not go further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Generate') and a clear resource ('activation key for a product'). The use of 'new' and 'will be created' clearly separates this creation tool from the read-only siblings list_products, list_licenses, and get_license.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: generate a new license key when one is needed for a customer. However, there is no explicit guidance about when to use this tool instead of list_products, list_licenses, or get_license, and no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific license by its activation key, including activation history.
| Name | Required | Description | Default |
|---|---|---|---|
| activationKey | Yes | The activation key to look up (format: XXXX-XXXX-XXXX-XXXX) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of disclosing behavior. The word 'Get' signals a read-only operation, and 'including activation history' gives some insight into the response content. However, it does not address error behavior (e.g., invalid/unknown activation key), authentication requirements, or any other side-effect/limit details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded with the action and resource. There is no filler, and every clause adds useful information about what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter and no output schema, so the description should convey what is returned. It states 'detailed information' and specifically calls out 'activation history,' which gives some expectation, but it remains vague about the full response structure and how errors are signaled. The lack of annotations further increases the burden, making this only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes activationKey with type and format (XXXX-XXXX-XXXX-XXXX), so the parameter is well documented in structured form. The description only restates that the key is used to identify the license, adding no significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('detailed information about a specific license'), and the lookup mechanism ('by its activation key'). It also mentions the scope ('including activation history'), which distinguishes it from sibling tools like list_licenses (which presumably lists licenses) and generate_license (which creates them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for retrieving details about a single known license, but it does not explicitly state when to choose it over list_licenses or generate_license, nor does it provide any exclusion criteria. The usage context is reasonable but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all licenses, optionally filtered by product. Returns license keys, customer emails, activation status, and expiration dates.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | No | Optional product ID to filter licenses | |
| activeOnly | No | If true, only show active licenses (default: false) | |
| productName | No | Optional product name to filter licenses (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It clearly signals a read operation ('List') and discloses the returned fields: license keys, customer emails, activation status, and expiration dates. It does not mention pagination or auth, but nothing suggests mutation and the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the operation and filtering, the second states what is returned. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing return fields. All three optional parameters are covered by the schema. It omits pagination and error behavior, but for a simple list-with-filters tool the core context needed to call it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 productId, activeOnly, and productName. The description adds no meaningful parameter semantics beyond noting optional product filtering, which is already encoded in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), resource ('licenses'), and scope ('all'), then names the returned fields. The plural scope and optional product filter naturally distinguish this from get_license (single license) and generate_license (creation), even though siblings are not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a bulk-listing use case with optional product filtering, but it does not explicitly say when to prefer this over get_license or list_products. An agent must infer the routing from names and context rather than from clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all products for the current tenant. Returns product details including name, price, trial days, and license duration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It communicates a non-mutating list operation and names the returned fields, but it does not disclose pagination, ordering, authentication requirements, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The core action and scope come first, followed by the useful return-field summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description supplies the essential details: operation, tenant scope, and the returned product fields. It omits minor operational details like pagination, but nothing critical is missing for a simple list call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially complete and there is no parameter behavior to document. The description adds relevant implicit scoping via 'current tenant' without needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as listing products and scopes it to the current tenant. The resource noun 'products' visibly distinguishes it from the sibling license-related tools like list_licenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case through the verb and resource: call this when you need product details. However, it never explicitly states when not to use this tool or how it compares to the license-oriented sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0generate_licenseget_licenselist_licenseslist_productsScored across 4 tools
Each tool targets a clearly distinct action and resource: listing products, listing licenses, generating a new license, and fetching a single license by key. There is no meaningful overlap or ambiguity among the four tools.
All tool names follow a consistent verb_noun pattern in snake_case, such as list_products, list_licenses, generate_license, and get_license. The naming is predictable and easy for an agent to pattern-match.
Four tools is well-scoped for a focused license management server. Each tool represents a core operation, and the set does not feel padded or unnecessarily large.
The set covers listing products, listing licenses, generating licenses, and retrieving license details, which handles the primary issuance and lookup workflow. However, there are no update, revoke, or deactivation operations for licenses, leaving a notable lifecycle gap.
Connect AI assistants to Subotiz - Using Subotiz's external capabilities through natural language
Connect AI assistants to Subotiz - Using Subotiz's external capabilities through natural language
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Connect your AI assistant to Revensi OS agents, workflows, and business data.
