Skip to main content
Glama
dexoryn

Pump.fun MCP Server

by dexoryn
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pumpfun-mcp

A Model Context Protocol (MCP) server for interacting with the Pump.fun platform on Solana. This server enables AI assistants to create, buy, and sell tokens on the Pump.fun platform.

Usage

https://github.com/user-attachments/assets/0b0f1f6f-6ea6-4ca8-92a8-b4cc895814e4

To use this server with Claude or other MCP-compatible AI assistants, add the following configuration to your MCP client:

If you're on MacOS and want to run this in Claude Desktop, in your ~/Library/Application \Support/Claude/claude_desktop_config.json file, write the following:

{
  "mcpServers": {
    "pumpfun": {
      "command": "node",
      "args": ["/Users/noahsolomon/Desktop/pumpfun-mcp/build/index.js"], // note this should be YOUR absolute path to index.js, not mine.
      "env": {
        "HELIUS_RPC_URL": "https://your-helius-rpc-url.com"
      }
    }
  }
}

Replace https://your-helius-rpc-url.com with your Helius RPC URL.

Related MCP server: RefundYourSOL

Installation

  1. Clone this repository:

    git clone https://github.com/noahgsolomon/pumpfun-mcp.git
cd pumpfun-mcp

  2. Install dependencies:

    npm install

  3. Create a .env file with your Solana RPC URL:

    HELIUS_RPC_URL=https://your-helius-rpc-url.com

    You can get a free RPC URL from Helius.

    To use an existing Solana wallet, add your private key to the .env file:

    PRIVATE_KEY=your-base58-encoded-private-key

    Then run the conversion script to create a keypair file:

    node convert-key.js

    This will create a default.json file in the .keys folder with your keypair.

  4. Build the project:

    npm run build

  5. Run the MCP server:

    node build/index.js

Components

Tools

  • get-token-info

    • Get information about a Pump.fun token

    • Input parameters:

      • tokenAddress (string, required): The token's mint address

  • create-token

    • Create a new Pump.fun token

    • Input parameters:

      • name (string, required): Token name

      • symbol (string, required): Token symbol

      • description (string, required): Token description

      • imageUrl (string, optional): Path to local image file

      • initialBuyAmount (number, required): Initial buy amount in SOL (min 0.0001)

      • accountName (string, optional): Name of the account to use (defaults to "default")

  • buy-token

    • Buy a Pump.fun token

    • Input parameters:

      • tokenAddress (string, required): The token's mint address

      • buyAmount (number, required): Amount to buy in SOL (min 0.0001)

      • accountName (string, optional): Name of the account to use (defaults to "default")

      • slippageBasisPoints (number, optional): Slippage tolerance in basis points (defaults to 100)

  • sell-token

    • Sell a Pump.fun token

    • Input parameters:

      • tokenAddress (string, required): The token's mint address

      • sellAmount (number, required): Amount of tokens to sell (use 0 to sell all)

      • accountName (string, optional): Name of the account to use (defaults to "default")

      • slippageBasisPoints (number, optional): Slippage tolerance in basis points (defaults to 100)

  • list-accounts

    • List all accounts in the keys folder

    • No input parameters required

  • get-account-balance

    • Get the SOL and token balances for an account

    • Input parameters:

      • accountName (string, optional): Name of the account to check (defaults to "default")

      • tokenAddress (string, optional): Token address to check balance for

Account Management

The MCP automatically creates and manages Solana keypairs in the .keys folder. Each keypair is stored as a JSON file with the account name as the filename.

When creating a token, the mint keypair is also saved in the .keys folder with the prefix mint-.

To use the MCP with your own account, you need to:

  1. Add your private key to the .env file and run node convert-key.js

  2. Have sufficient SOL in that wallet

Standalone Scripts

The project includes several standalone scripts that can be run directly:

  • Get Token Info: node build/get-token-info.js <token_address>

  • Create Token: node build/create-token.js <name> <symbol> <description> <initial_buy_amount> [account_name] [image_url]

  • Buy Token: node build/buy-token.js <token_address> <buy_amount_sol> [account_name] [slippage_basis_points]

  • Sell Token: node build/sell-token.js <token_address> <sell_amount> [account_name] [slippage_basis_points]

  • List Accounts: node build/list-accounts.js

  • Get Account Balance: node build/get-token-balance.js <account_name> [token_address]

Important Notes

  • Security: The keypairs are stored unencrypted in the .keys folder. Make sure to secure this folder appropriately.

  • Fees: All transactions on Solana require SOL for transaction fees. Make sure your accounts have enough SOL.

  • Slippage: The default slippage tolerance is 1% (100 basis points). You can adjust this for each transaction.

  • Images: When creating tokens with images, you must provide a local file path to the image. Remote URLs are not supported.

Development

Project Structure

  • src/index.ts: Main MCP server entry point

  • src/get-token-info.ts: Token information retrieval

  • src/create-token.ts: Token creation functionality

  • src/buy-token.ts: Token buying functionality

  • src/sell-token.ts: Token selling functionality

  • src/list-accounts.ts: Account listing functionality

  • src/get-token-balance.ts: Account balance checking

  • src/utils.ts: Shared utility functions

  • convert-key.js: Utility to convert a base58 private key to a keypair JSON file

Building

npm run build

Available Tools

6 tools
buy-tokenC

Buy a Pump.fun token

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenAddressYesThe token's mint address
buyAmountYesAmount to buy in SOL
accountNameNoName of the account to usedefault
slippageBasisPointsNoSlippage tolerance in basis points (1% = 100)

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits like required permissions, transaction costs, rate limits, or what happens on failure. 'Buy' implies a financial transaction, but critical details like confirmation steps or irreversible effects are missing.

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 with zero waste, front-loading the core action. It's appropriately sized for the tool's complexity, making it easy 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 no annotations, no output schema, and a financial transaction tool with 4 parameters, the description is incomplete. It lacks essential context like return values, error handling, or behavioral nuances, leaving significant gaps for safe and effective use.

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 description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying token purchase, which aligns with schema but doesn't enhance understanding of parameter interactions or usage context.

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 ('buy') and resource ('a Pump.fun token'), providing specific purpose. However, it doesn't differentiate from sibling 'sell-token' beyond the verb direction, missing explicit distinction about when each is appropriate.

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 'sell-token' or 'create-token' is provided. The description assumes context but offers no explicit usage context, prerequisites, or exclusions.

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

create-tokenC

Create a new Pump.fun token

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesToken name
symbolYesToken symbol
descriptionYesToken description
imageUrlNoURL to token image (optional)
initialBuyAmountYesInitial buy amount in SOL
accountNameNoName of the account to use (will be created if it doesn't exist)default

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 full burden but offers minimal behavioral insight. 'Create' implies a write operation, but it doesn't disclose critical traits like authentication requirements, cost implications (SOL usage), whether the token becomes immediately tradable, or potential rate limits. The description fails to compensate for the lack of annotations.

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 comprehensive schema documentation and gets straight to the point with zero wasted content.

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 token creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., token address returned, initialization state), doesn't mention SOL cost implications from 'initialBuyAmount', and provides no context about the creation process. The schema covers parameters well, but behavioral and outcome aspects are missing.

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 description coverage is 100%, providing good documentation for all parameters. The description adds no parameter-specific information beyond what's in the schema. This meets the baseline of 3 since the schema adequately covers parameter meanings, but the description doesn't enhance understanding of how parameters interact or their business significance.

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 ('Create') and resource ('new Pump.fun token'), making the purpose immediately understandable. It distinguishes from siblings like 'buy-token' or 'sell-token' by focusing on creation rather than trading operations. However, it doesn't specify what 'create' entails in this context (e.g., minting, deployment).

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. It doesn't mention prerequisites (e.g., needing an account), differentiate from similar tools like 'get-token-info', or indicate when creation is appropriate versus buying existing tokens. The agent must infer usage from context alone.

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

get-account-balanceC

Get the SOL and token balances for an account

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNameNoName of the account to checkdefault
tokenAddressNoOptional token address to check balance 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 what the tool does but lacks critical behavioral details such as whether this is a read-only operation (implied but not explicit), potential rate limits, authentication requirements, or error conditions. This is a significant gap for a tool that likely interacts with financial data.

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 any fluff. 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 the complexity of financial balance retrieval, no annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., balance values, formats), potential side effects, or error handling. This leaves the agent with insufficient context for reliable tool 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?

The schema description coverage is 100%, so the schema already documents both parameters ('accountName' and 'tokenAddress') with clear descriptions. The description adds no additional semantic context beyond implying balance retrieval for SOL and tokens, which aligns with the schema but doesn't provide extra value like parameter interactions or examples.

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 ('Get') and resources ('SOL and token balances for an account'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'list-accounts' or 'get-token-info', which could provide related information, so it falls short of a perfect score.

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. For example, it doesn't clarify if this is for checking balances of a specific account versus listing all accounts (as 'list-accounts' might do), or how it differs from 'get-token-info' in terms of balance retrieval. This lack of context leaves the agent to infer usage.

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

get-token-infoC

Get information about a Pump.fun token

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenAddressYesThe token's mint address

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 this is a read operation ('Get information'), which implies it's likely safe and non-destructive, but doesn't address potential rate limits, authentication needs, error conditions, or what specific information is returned. This leaves significant gaps for a tool with no annotation coverage.

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 any unnecessary words. It's perfectly front-loaded and every word earns its place, making it highly concise and well-structured.

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 insufficiently complete. It doesn't explain what information is returned (e.g., price, liquidity, creator), how errors are handled, or any behavioral constraints. For a tool with no structured data beyond the input schema, this leaves too many unknowns for reliable agent operation.

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 single parameter 'tokenAddress' clearly documented in the schema as 'The token's mint address'. The description doesn't add any additional parameter context beyond what the schema provides, so it meets the baseline for adequate but not exceptional coverage.

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 ('Get information') and target resource ('about a Pump.fun token'), making the purpose immediately understandable. However, it doesn't differentiate from potential sibling tools like 'get-account-balance' that might also retrieve information, so it doesn't reach the highest score.

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 'get-account-balance' or 'list-accounts'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.

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

list-accountsB

List all accounts in the keys folder

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
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. While 'List' implies a read-only operation, it doesn't specify whether this requires authentication, what format the output takes, whether results are paginated, or any rate limits. The description is minimal and lacks important behavioral context.

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 exactly what the tool does with zero wasted words. It's appropriately sized for a simple listing tool with no parameters and gets straight to the point without unnecessary elaboration.

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?

For a zero-parameter listing tool with no output schema, the description provides the basic purpose but lacks important context about authentication requirements, output format, or behavioral characteristics. While simple tools need less documentation, the absence of annotations means the description should compensate more than it does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters since none exist, maintaining focus on the tool's purpose rather than parameter details.

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 ('List') and target resource ('all accounts in the keys folder'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get-account-balance' which retrieves specific account information rather than listing all accounts.

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 'get-account-balance' or other sibling tools. There's no mention of prerequisites, context for usage, or comparison with other listing/filtering tools that might exist.

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

sell-tokenC

Sell a Pump.fun token

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenAddressYesThe token's mint address
sellAmountYesAmount of tokens to sell (0 for all)
accountNameNoName of the account to usedefault
slippageBasisPointsNoSlippage tolerance in basis points (1% = 100)

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 full burden for behavioral disclosure. 'Sell a Pump.fun token' implies a financial transaction with potential consequences, but doesn't disclose critical behaviors like whether this is irreversible, requires authentication, has rate limits, or what happens on failure. The description mentions no behavioral traits beyond the basic action, leaving significant gaps for a financial 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 states exactly what the tool does without any wasted words. It's appropriately sized for a straightforward financial transaction tool and is perfectly front-loaded with the core action. Every word earns its place in conveying the essential purpose.

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 financial transaction tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after selling (e.g., where funds go, confirmation process), error conditions, or return values. The combination of a potentially destructive financial operation with minimal contextual information creates significant gaps for safe and effective use.

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 description coverage is 100%, so the schema already fully documents all 4 parameters. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter relationships, provide examples, or clarify edge cases. This meets the baseline for high schema coverage but doesn't add value beyond the structured data.

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 ('sell') and resource ('Pump.fun token'), making the purpose immediately understandable. It distinguishes this from sibling tools like 'buy-token' and 'create-token' by specifying the opposite financial transaction. However, it doesn't specify what type of token (e.g., cryptocurrency) or platform context beyond 'Pump.fun', which slightly limits specificity.

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. It doesn't mention prerequisites like needing tokens to sell, account setup, or market conditions. While the tool name implies it's for selling tokens, there's no explicit context about when this operation is appropriate versus using 'buy-token' or other financial tools.

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. 6 tool updatesv1.0.0
    • Changedbuy-token2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcreate-token2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget-account-balance2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget-token-info2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedlist-accounts1 field changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
    • Changedsell-token2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
  2. 6 tool updates
    • First observedbuy-token
    • First observedcreate-token
    • First observedget-account-balance
    • First observedget-token-info
    • First observedlist-accounts
    • First observedsell-token
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 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: buying, selling, and creating tokens are separate actions, while getting token info, account balances, and listing accounts are distinct read operations. The descriptions make it unambiguous which tool to use for each task.

Naming Consistency4/5

The naming follows a consistent verb-noun pattern with hyphens (e.g., buy-token, create-token, get-token-info), except for 'list-accounts' which uses 'list' instead of 'get' like the other read operations. This minor deviation prevents a perfect score but maintains overall readability.

Tool Count5/5

With 6 tools, this server is well-scoped for interacting with Pump.fun tokens and accounts. Each tool serves a clear purpose (e.g., core token lifecycle operations and account management), and none feel redundant or missing given the domain.

Completeness4/5

The toolset covers the essential token lifecycle (create, buy, sell, get info) and account management (balance, list), but lacks update or delete operations for tokens or accounts, which might be minor gaps depending on the platform's capabilities. Overall, it supports core workflows effectively.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches