How do I use MCP Platform Service?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Platform Service fetch reference data for statuses" 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.

MCP Platform Service

by Artemida1609

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

MCP Platform Service

A minimal Model Context Protocol (MCP) service for integration with external platforms. This service provides CRUD operations, reference data fetching, and authentication capabilities.

Features

✅ CRUD operations (Create, Read, Update, Delete) for entities
✅ Reference data fetching (statuses, priorities, categories, etc.)
✅ Authentication via API token (environment variable) or login tool
✅ Token refresh support
✅ MCP-compatible server implementation
✅ Ready to run via npx from GitHub

Related MCP server: MCP REST API Server

Prerequisites

Node.js 18.0.0 or higher
npm or yarn

Installation

Option 1: Run via npx (from GitHub)

npx github:Artemida1609/mcp-service

Option 2: Install locally

git clone https://github.com/Artemida1609/mcp-service.git
cd mcp-service
npm install

Environment Variables

The service supports the following environment variables:

Variable	Description	Required	Default
`API_TOKEN`	API token for authentication	No*	-
`API_BASE_URL`	Base URL of the external platform API	No	`https://api.example.com/v1`
`API_TIMEOUT`	Request timeout in milliseconds	No	`30000`
`ALLOW_LOGIN`	Enable login tool (true/false)	No	`true`

* API_TOKEN is required unless you use the login tool to authenticate.

Usage

Setting Environment Variables

Linux/macOS:

export API_TOKEN="your-api-token-here"
export API_BASE_URL="https://api.yourplatform.com/v1"

Windows (PowerShell):

$env:API_TOKEN="your-api-token-here"
$env:API_BASE_URL="https://api.yourplatform.com/v1"

Windows (CMD):

set API_TOKEN=your-api-token-here
set API_BASE_URL=https://api.yourplatform.com/v1

Running the Service

Via npx:

npx github:your-username/mcp-service

Locally:

npm start
# or
node index.js

The service runs as an MCP server on stdio and communicates via the Model Context Protocol.

MCP Server Integration

Claude Desktop Configuration

Add this to your Claude Desktop configuration file (claude_desktop_config.json):

macOS:

{
  "mcpServers": {
    "platform-service": {
      "command": "npx",
      "args": ["github:Artemida1609/mcp-service"],
      "env": {
        "API_TOKEN": "your-api-token-here",
        "API_BASE_URL": "https://api.yourplatform.com/v1"
      }
    }
  }
}

Windows:

{
  "mcpServers": {
    "platform-service": {
      "command": "npx.cmd",
      "args": ["github:Artemida1609/mcp-service"],
      "env": {
        "API_TOKEN": "your-api-token-here",
        "API_BASE_URL": "https://api.yourplatform.com/v1"
      }
    }
  }
}

Other MCP Clients

The service communicates via stdio using the MCP protocol. Configure your MCP client to:

Command: npx (or npx.cmd on Windows)
Args: ["github:Artemida1609/mcp-service"]
Environment variables as needed

Available Tools

CRUD Operations

`get_entity`

Retrieve a specific entity by ID and type.

Parameters:

entityId (string, required): The unique identifier of the entity
entityType (string, required): Type of entity (user, project, task, document)

Example:

{
  "entityId": "123",
  "entityType": "project"
}

`create_entity`

Create a new entity in the platform.

Parameters:

entityType (string, required): Type of entity to create
data (object, required): Entity data

Example:

{
  "entityType": "task",
  "data": {
    "title": "New Task",
    "description": "Task description",
    "status": "open"
  }
}

`update_entity`

Update an existing entity.

Parameters:

entityId (string, required): The unique identifier
entityType (string, required): Type of entity
data (object, required): Fields to update

Example:

{
  "entityId": "123",
  "entityType": "task",
  "data": {
    "status": "completed"
  }
}

`delete_entity`

Delete an entity from the platform.

Parameters:

entityId (string, required): The unique identifier
entityType (string, required): Type of entity

Example:

{
  "entityId": "123",
  "entityType": "task"
}

Reference Data

`get_reference`

Fetch reference data (statuses, priorities, categories, etc.).

Parameters:

referenceType (string, required): Type of reference (statuses, priorities, categories, tags, users)
filters (object, optional): Optional filters

Example:

{
  "referenceType": "statuses",
  "filters": {
    "active": true
  }
}

Authentication

`login`

Authenticate with username and password. Stores the token for subsequent requests.

Parameters:

username (string, required): Username
password (string, required): Password

Example:

{
  "username": "user@example.com",
  "password": "password123"
}

`refresh_token`

Refresh an expired access token.

Parameters:

refreshToken (string, required): The refresh token

Example:

{
  "refreshToken": "your-refresh-token-here"
}

API Endpoints

The service expects the external platform API to follow these conventions:

GET /entities/{entityType}/{entityId} - Get entity
POST /entities/{entityType} - Create entity
PUT /entities/{entityType}/{entityId} - Update entity
DELETE /entities/{entityType}/{entityId} - Delete entity
GET /reference/{referenceType} - Get reference data
POST /auth/login - Login
POST /auth/refresh - Refresh token

All requests require Bearer token authentication in the Authorization header.

Project Structure

mcp-service/
├── index.js          # Main MCP server entry point
├── config.js         # Configuration and environment variables
├── auth.js           # Authentication token management
├── api-client.js     # HTTP client for API requests
├── handlers.js       # Tool handler implementations
├── tools.js          # Tool definitions and descriptions
├── schemas.js        # Input schemas for tools
├── package.json      # Dependencies and metadata
├── .gitignore        # Git ignore rules
└── README.md         # This file

Development

Local Development

Clone the repository
Install dependencies: npm install
Set environment variables
Run: npm start

Testing

To test the service manually, you can use an MCP client or test the handlers directly:

import { handleGetEntity } from './handlers.js';

const result = await handleGetEntity({
  entityId: '123',
  entityType: 'project'
});
console.log(result);

Troubleshooting

"No authentication token available" Error

Ensure API_TOKEN is set in your environment, or
Use the login tool to authenticate first

"Request timeout" Error

Increase API_TIMEOUT environment variable
Check network connectivity
Verify API_BASE_URL is correct

Set ALLOW_LOGIN=true in your environment variables

Module Not Found Errors

Run npm install to install dependencies
Ensure Node.js version is 18.0.0 or higher

Customization

To adapt this service for your specific platform:

Update API_BASE_URL to your platform's API endpoint
Modify endpoint paths in handlers.js if your API uses different routes
Adjust entity types in schemas.js to match your platform's entities
Update reference types in get_reference handler
Modify authentication flow in handleLogin if your platform uses different auth mechanisms

License

MIT

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Support

For issues and questions, please open an issue on GitHub.

Available Tools

7 tools

create_entityB

Create a new entity in the external platform

ParametersJSON Schema

Name	Required	Description	Default
`data`	Yes	The entity data to create
`entityType`	Yes	The type of entity to create

TDQS

B3/5.0

Behavior2/5

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

With no annotations provided, the description must explain behavioral traits, but it only states 'Create a new entity'. It does not disclose side effects, idempotency, required permissions, or what happens upon success or failure. The agent gets no insight into the tool's behavior beyond the plain action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it is too terse and lacks useful information. While it wastes no words, it also fails to fill the minimal information needed for effective tool use.

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 has two parameters (one enum, one nested object) and no output schema, the description should provide additional context like expected return values, error handling, or authentication. It does not, leaving the agent underinformed for correct invocation.

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 coverage is 100% with descriptions for both parameters. The description adds no additional meaning beyond the schema, such as clarifying the structure of the 'data' object or providing examples. Baseline 3 is maintained because the schema already documents parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Create' and the resource 'new entity', which is distinct from sibling tools like 'delete_entity', 'get_entity', and 'update_entity'. It leaves no ambiguity about what the tool does.

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, such as prerequisites, authentication requirements, or when creation might fail. It gives no context about use cases or exclusions.

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

delete_entityC

Delete an entity from the external platform

ParametersJSON Schema

Name	Required	Description	Default
`entityId`	Yes	The unique identifier of the entity to delete
`entityType`	Yes	The type of entity

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 must disclose behavioral traits. It only states 'delete' without clarifying if the deletion is permanent, if it cascades to related data, or if any confirmation or permissions are needed. This is a significant omission for a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, very concise. No fluff. However, being too brief may omit necessary details for a destructive operation. For a simple delete, it is appropriately sized but could benefit from a brief behavior note.

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?

With no output schema, no annotations, and multiple sibling tools, the description is incomplete. It fails to explain return values (e.g., success/failure), error states, or prerequisites like authentication. Given the tool's destructive nature, more context is needed for safe usage.

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?

Input schema covers 100% of parameters with descriptions. The description does not add any additional meaning beyond what the schema provides (e.g., no clarification on what 'entityId' represents or how to obtain it). Baseline is 3 due to high schema coverage, and no extra value is added.

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?

Description states 'Delete an entity from the external platform', which clearly identifies the action (delete) and resource (entity). The input schema further specifies entity types, making purpose clear. However, it does not emphasize that deletion is permanent or irreversible, which could be implied. Sibling tools like create_entity and update_entity provide contrast, but the description does not explicitly differentiate them.

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?

No guidance on when to use this tool vs. alternatives (e.g., update_entity for soft deletion or get_reference for verification). No prerequisites like authentication or validation steps mentioned. The description offers no context for appropriate usage scenarios.

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

get_entityC

Retrieve a specific entity by ID and type from the external platform

ParametersJSON Schema

Name	Required	Description	Default
`entityId`	Yes	The unique identifier of the entity to retrieve
`entityType`	Yes	The type of entity (e.g., 'user', 'project', 'task')

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It implies a read-only operation but does not disclose authentication needs, rate limits, or error behavior (e.g., if entity not found).

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?

Single sentence, no wasted words. Information is front-loaded 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?

No output schema, and description does not explain the return value format or field structure. For a retrieval tool, this is a significant gap. Errors or edge cases are not mentioned.

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 coverage is 100% with clear descriptions for both parameters. The description adds no extra meaning beyond 'by ID and type', so baseline score applies.

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?

Description clearly states the action (retrieve) and the resource (entity by ID and type). It distinguishes from create/delete/update siblings, though lacks explicit differentiation from 'get_reference', which might require further clarification.

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?

No guidance on when to use this tool versus alternatives like get_reference. Does not mention prerequisites or scenarios where this tool is appropriate.

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

get_referenceB

Fetch reference data (statuses, priorities, categories, etc.) from the external platform

ParametersJSON Schema

Name	Required	Description	Default
`filters`	No	Optional filters to apply
`referenceType`	Yes	The type of reference data to fetch

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations available, the description carries the full burden. It implies a read-only operation but does not disclose any other behavioral traits such as side effects, authentication needs, or rate limits.

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 sentence of 13 words, front-loaded with the verb, and contains no unnecessary information.

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 low complexity and no output schema, the description covers the basic purpose and reference types but lacks details on return format and filtering behavior, which would be helpful for an agent.

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 coverage is 100%, so baseline is 3. The description adds minimal extra meaning by listing examples of reference types (statuses, priorities, categories) but does not explain the 'filters' parameter.

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 ('Fetch') and the resource ('reference data') with examples. However, it does not explicitly distinguish this from the sibling tool 'get_entity', which could cause confusion.

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?

No usage guidelines provided. The description does not indicate when to use this tool versus alternatives like 'get_entity', nor does it mention prerequisites or context.

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

loginA

Authenticate with the external platform using username and password. Returns an API token that can be used for subsequent requests.

ParametersJSON Schema

Name	Required	Description	Default
`password`	Yes	Password for authentication
`username`	Yes	Username for authentication

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must fully convey behavior. It mentions authentication and token return, but lacks details on side effects like session creation, token expiration, or security implications (e.g., credentials not stored). The description is minimal for a security-sensitive 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 clear sentence with no wasted words. It is appropriately front-loaded with the action verb 'Authenticate', making it efficient.

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?

With no output schema, the description correctly states it 'Returns an API token', which is essential. However, it does not elaborate on token format, expiry, or how to use it in subsequent requests. Given the sibling 'refresh_token', more detail on token lifecycle would improve completeness.

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 coverage is 100% with both parameters described. The description adds no extra meaning beyond restating 'username and password'. Since the schema already defines them adequately, the description provides no additional value for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Authenticate' and specific resource 'external platform using username and password', and explicitly mentions the outcome of returning an API token. It distinguishes well from sibling tools like create_entity, delete_entity, etc., as authentication is a distinct operation.

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 for initial authentication via 'can be used for subsequent requests', but does not explicitly state when to use this tool versus the sibling 'refresh_token'. No exclusions or alternatives are mentioned, leaving some ambiguity for an agent.

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

refresh_tokenB

Refresh an expired access token using a refresh token

ParametersJSON Schema

Name	Required	Description	Default
`refreshToken`	Yes	The refresh token to use for obtaining a new access token

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits like side effects (e.g., invalidation of old token), error conditions, or authentication requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise single sentence that is front-loaded with the core action. However, it could be slightly expanded without becoming verbose.

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 low complexity (1 parameter, no output schema), the description covers the fundamental purpose but lacks usage context and behavioral details, leaving it at minimum viable.

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 coverage is 100%, with the parameter 'refreshToken' already described. The description adds no additional semantic meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'refresh', the resource 'access token', and the mechanism 'using a refresh token'. It distinguishes from sibling tools like 'login' which handles initial authentication.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., 'login') or prerequisites such as token expiry or refresh token validity.

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

update_entityC

Update an existing entity in the external platform

ParametersJSON Schema

Name	Required	Description
`data`	Yes	The fields to update
`entityId`	Yes	The unique identifier of the entity to update
`entityType`	Yes	The type of entity

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description should explain behavioral traits (e.g., partial vs full update, error behavior, permissions). It only says 'Update an existing entity', leaving the agent guessing about important details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely short but under-specified. While one sentence is concise, it lacks critical information, making it inadequate rather than efficiently informative.

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?

No output schema and no annotation support. The description fails to cover return values, error handling, or side effects, leaving major gaps for a mutation tool.

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 has 100% description coverage, so parameters are documented. The description adds no extra meaning beyond the schema, meeting the baseline for a 3.

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 ('Update') and the resource ('existing entity'), making it unambiguous. However, it does not differentiate from sibling tools like create_entity or delete_entity, missing an opportunity to clarify scope.

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?

No guidance on when to use this tool vs alternatives. For example, it doesn't explain when to update vs delete and recreate, or any prerequisites like authentication state.

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.

7 tool updatesv1.0.0Jul 6, 2026
- First observedcreate_entity
- First observeddelete_entity
- First observedget_entity
- First observedget_reference
- First observedlogin
- First observedrefresh_token
- First observedupdate_entity

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Scored 2026-07-06 12:40 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: authentication (login, refresh_token), CRUD for entities (create_entity, delete_entity, get_entity, update_entity), and reference data (get_reference). There is no overlap or ambiguity.

Naming Consistency5/5

All tools use snake_case with a verb_noun pattern (create_entity, get_entity, refresh_token), except login which is a single verb. This minor deviation is still predictable and consistent with the overall style.

Tool Count5/5

With 7 tools, the set is well-scoped for a platform service covering authentication, CRUD, and reference data. It is neither too sparse nor overwhelming.

Completeness3/5

The set covers CRUD for entities and authentication, but lacks a list/search tool for entities, which is a notable gap. Agents cannot retrieve multiple entities without knowing IDs, limiting workflow efficiency.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42
l0-py-blocks-mcp A
io.github.SELISEdigitalplatforms
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
Cloud Platforms Developer Tools App Automation
362
ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
console-mcp-server
io.github.mia-platform
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
Cloud Platforms Developer Tools App Automation
23

Related MCP Servers

OpsLevel MCPofficial
Developer Tools Observability Monitoring
OpsLevel
A
license
Not graded
quality
C
maintenance
Model Context Protocol (MCP) server for OpsLevel
Updated 2 months ago (2026-07-10 16:15 UTC)
12
MIT
MCP REST API Server
Developer Tools Code Execution
vinaykp
F
license
Not graded
quality
D
maintenance
A server implementation of the Model Context Protocol (MCP) that provides REST API endpoints for managing and interacting with MCP resources.
Updated a year ago (2025-06-01 03:08 UTC)
-
MCP Reference Server
Developer Tools Documentation Access
chrishayuk
A
license
Not graded
quality
D
maintenance
A comprehensive reference implementation demonstrating all features of the Model Context Protocol (MCP) specification, serving as documentation, learning resource, and testing tool for MCP implementations.
Updated 9 months ago (2025-11-27 00:51 UTC)
1
MIT
Apideck MCPofficial
Cloud Platforms CRM File Systems
apideck-libraries
A
license
A
quality
A
maintenance
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Updated a month ago (2026-08-10 08:18 UTC)
4
223
17
MIT

MCP Platform Service

Features

Prerequisites

Installation

Option 1: Run via npx (from GitHub)

Option 2: Install locally

Environment Variables

Usage

Setting Environment Variables

Running the Service

MCP Server Integration

Claude Desktop Configuration

Other MCP Clients

Available Tools

CRUD Operations

get_entity

create_entity

update_entity

delete_entity

Reference Data

get_reference

Authentication

login

refresh_token

API Endpoints

Project Structure

Development

Local Development

Testing

Troubleshooting

"No authentication token available" Error

"Request timeout" Error

Login Tool Disabled

Module Not Found Errors

Customization

License

Contributing

Support

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

OpsLevel MCPofficial

Apideck MCPofficial

`get_entity`

`create_entity`

`update_entity`

`delete_entity`

`get_reference`

`login`

`refresh_token`