What can you do with this server?

The CashPilot-MCP server acts as a bridge to a CashPilot instance, enabling LLMs to monitor passive income earnings, manage deployed services, and control fleet workers. Earnings & Monitoring: * Query daily earnings (last N days) and earnings history (week/month/year/all) * Trigger an immediate earnings collection across all services Service Management: * Deploy a service from the catalog, with optional environment variables * Start, stop, restart, or remove deployed services * Retrieve recent service logs and Docker Compose definitions Read-Only Resources: * Earnings summaries and breakdowns * Deployed services and service catalog * Fleet and worker status * Health scores and collector alerts

de en es ja ko ru zh

cashpilot-mcp

by GeiserX

Overview Schema Related Servers Score Discussions

Hybrid

What you get

Type	What for	MCP URI / Tool id
Resources	Browse earnings, services, fleet status, and health scores read-only	`cashpilot://earnings/summarycashpilot://earnings/breakdowncashpilot://services/deployedcashpilot://services/catalogcashpilot://fleet/summarycashpilot://workerscashpilot://health/scorescashpilot://collector-alerts`
Tools	Query earnings, manage services, and trigger collection	`get_earnings_dailyget_earnings_historyget_service_logsrestart_servicestop_servicestart_servicedeploy_serviceremove_servicetrigger_collectionget_compose`

Everything is exposed over a single JSON-RPC endpoint (/mcp). LLMs / Agents can: initialize -> readResource -> listTools -> callTool ... and so on.

Related MCP server: OpenAPI MCP Server

Quick-start (Docker Compose)

services:
  cashpilot-mcp:
    image: drumsergio/cashpilot-mcp:latest
    ports:
      - "127.0.0.1:8081:8081"
    environment:
      - CASHPILOT_URL=http://cashpilot:8080
      - CASHPILOT_API_KEY=<your-CASHPILOT_ADMIN_API_KEY>

Security note: The HTTP transport listens on 127.0.0.1:8081 by default. If you need to expose it on a network, place it behind a reverse proxy with authentication.

Install via npm (stdio transport)

npx cashpilot-mcp

Or install globally:

npm install -g cashpilot-mcp
cashpilot-mcp

This downloads the pre-built Go binary from GitHub Releases for your platform and runs it with stdio transport. Requires at least one published release.

Local build

git clone https://github.com/GeiserX/cashpilot-mcp
cd cashpilot-mcp

# (optional) create .env from the sample
cp .env.example .env && $EDITOR .env

go run ./cmd/server

Configuration

Variable	Default	Description
`CASHPILOT_URL`	`http://localhost:8080`	CashPilot instance URL (without trailing /)
`CASHPILOT_API_KEY`	(required)	Admin API key (`CASHPILOT_ADMIN_API_KEY` from your CashPilot instance — NOT the fleet key)
`LISTEN_ADDR`	`127.0.0.1:8081`	HTTP listen address (Docker sets `127.0.0.1:8081`)
`MCP_AUTH_TOKEN`	(empty)	Bearer token for HTTP transport auth. Required when `LISTEN_ADDR` is not loopback
`TRANSPORT`	(empty = HTTP)	Set to `stdio` for stdio transport

Put them in a .env file (from .env.example) or set them in the environment.

Testing

Tested with Inspector and it is currently fully working. Before making a PR, make sure this MCP server behaves well via this medium.

Example configuration for client LLMs

{
  "schema_version": "v1",
  "name_for_human": "CashPilot-MCP",
  "name_for_model": "cashpilot_mcp",
  "description_for_human": "Monitor passive income earnings, manage bandwidth-sharing services, and control fleet workers via CashPilot.",
  "description_for_model": "Interact with a CashPilot instance that manages passive income services. First call initialize, then reuse the returned session id in header \"Mcp-Session-Id\" for every other call. Use readResource to fetch URIs that begin with cashpilot://. Use listTools to discover available actions and callTool to execute them.",
  "auth": {
    "type": "bearer",
    "token": "<your-MCP_AUTH_TOKEN>"
  },
  "api": {
    "type": "jsonrpc-mcp",
    "url":  "http://localhost:8081/mcp",
    "init_method": "initialize",
    "session_header": "Mcp-Session-Id"
  },
  "contact_email": "acsdesk@protonmail.com",
  "legal_info_url": "https://github.com/GeiserX/cashpilot-mcp/blob/main/LICENSE"
}

Credits

CashPilot -- passive income fleet management dashboard

MCP-GO -- modern MCP implementation

GoReleaser -- painless multi-arch releases

Maintainers

@GeiserX.

Contributing

Feel free to dive in! Open an issue or submit PRs.

CashPilot-MCP follows the Contributor Covenant Code of Conduct.

Other MCP Servers by GeiserX

duplicacy-mcp — Backup health monitoring
genieacs-mcp — TR-069 device management
lynxprompt-mcp — AI configuration blueprints
pumperly-mcp — Fuel and EV charging prices
telegram-archive-mcp — Telegram message archive

Project	Description
CashPilot	Self-hosted passive income platform with web UI for setup and earnings tracking
CashPilot-android	Android monitoring agent for CashPilot passive income apps
cashpilot-ha	Home Assistant custom integration for CashPilot passive income monitoring
n8n-nodes-cashpilot	n8n community node for CashPilot passive income monitoring

Available Tools

10 tools

deploy_serviceB

Destructive

Deploy a service from the catalog

ParametersJSON Schema

Name	Required	Description	Default
`env`	No	Optional JSON string of environment variable key-value pairs
`slug`	Yes	Service slug to deploy

TDQS

B3.2/5.0

Behavior2/5

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

Annotations already indicate destructiveHint=true, but the description adds no additional behavioral context such as side effects, permission requirements, or reversibility. It relies solely on structured fields.

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?

The description is a single sentence with no waste. It is concise, though it could be slightly expanded to include usage guidance without losing conciseness.

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 simple tool with two parameters and good annotations, the description is minimally adequate but lacks explicit usage context and behavioral detail, leaving gaps 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% with descriptions for both parameters (slug and env). The description does not add any meaning beyond the schema, so the baseline of 3 is appropriate.

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 'Deploy' and resource 'service from the catalog', making the tool's purpose immediately understandable and distinct from siblings like start_service or remove_service.

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 is provided on when to use this tool versus alternatives such as start_service, stop_service, or restart_service. The description does not mention prerequisites, exclusions, or context for usage.

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

get_composeB

Destructive

Get the Docker Compose definition for a service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug identifier

TDQS

B3/5.0

Behavior1/5

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

The description claims a read operation ('Get'), but annotations set destructiveHint=true and readOnlyHint=false, indicating the tool may modify state. This contradiction misleads the agent about the tool's behavior, and the description fails to explain any side effects or required permissions.

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 concise sentence that is front-loaded with the key verb and object. No unnecessary words or repetition.

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 simplicity of the tool (one parameter, no output schema), the description is minimal but fails to resolve the annotation contradiction or clarify the return format. It lacks completeness for a safe agent 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?

The only parameter 'slug' is fully described in the input schema with 'Service slug identifier'. The description adds no additional meaning beyond what the schema already 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 tool retrieves the Docker Compose definition for a service, using a specific verb ('Get') and resource ('service compose definition'). It distinguishes from sibling tools like deploy_service, get_service_logs, and start_service.

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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent to infer from the name alone.

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

get_earnings_dailyC

Destructive

Get daily earnings for the last N days

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Number of days to retrieve (default 7, max 365)

TDQS

C2.7/5.0

Behavior1/5

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

The description indicates a read operation ('Get'), but annotations declare destructiveHint=true and readOnlyHint=false, implying the tool modifies data. This is a direct contradiction, and the description fails to disclose any destructive side effects.

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 concise sentence with no waste. It front-loads the purpose effectively.

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?

The tool is simple with one optional parameter and no output schema, but the description fails to address the destructive nature implied by annotations, leaving the agent underinformed about behavioral expectations.

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

Parameters3/5

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

The description does not add meaning beyond the input schema, which already fully documents the 'days' parameter. Schema description coverage is 100%, so baseline score of 3 is appropriate.

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 states the verb 'Get' and resource 'earnings daily' clearly. However, it does not differentiate from the sibling tool 'get_earnings_history', which likely covers similar data.

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_earnings_history'. The description does not clarify constraints or context for usage.

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

get_earnings_historyC

Destructive

Get earnings history for a given period

ParametersJSON Schema

Name	Required	Description	Default
`period`	Yes	Time period: week, month, year, or all

TDQS

C2.4/5.0

Behavior1/5

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

Annotations indicate destructiveHint=true, suggesting the tool may modify state, but the description says 'Get' which implies a read-only operation. This contradicts the annotations. Additionally, no behavioral details are disclosed beyond the misleading verb.

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?

The description is a single sentence, but it omits critical information about behavior, result format, and context. It is under-specified rather than concise.

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 only one parameter and no output schema, the description fails to explain what the tool returns or how it behaves. Given the annotation contradiction, the description is incomplete and potentially misleading.

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% (period described with allowed values). The description adds 'for a given period' but does not provide additional meaning beyond the schema. Baseline score of 3 is appropriate.

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 'Get earnings history for a given period' clearly states the action and resource. However, it does not distinguish from the sibling tool 'get_earnings_daily', which may cause confusion about scope differentiation.

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 is provided on when to use this tool versus alternatives like 'get_earnings_daily'. The description lacks any context about prerequisites, exclusions, or typical use cases.

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

get_service_logsB

Destructive

Get recent logs for a deployed service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug identifier
`lines`	No	Number of log lines to retrieve (default 50)

TDQS

B3.4/5.0

Behavior2/5

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

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description implies a read-only operation ('Get'), failing to disclose potential side effects or destructive 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?

Single sentence, no filler, front-loaded with 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?

No output schema provided, and the description lacks details on log recency, format, or implications of the destructive hint, leaving ambiguity.

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%, and the description does not add meaning beyond the schema; baseline score.

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 'Get' and resource 'recent logs for a deployed service', distinguishing it from sibling tools like deploy, remove, and restart.

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?

No explicit guidance on when to use this tool versus alternatives, but the purpose is straightforward; minimal viable.

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

remove_serviceA

Destructive

Remove a deployed service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug to remove

TDQS

A3.5/5.0

Behavior3/5

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

The annotations already declare destructiveHint: true, so the destructive nature is known. The description 'Remove a deployed service' is consistent but adds no further behavioral detail (e.g., whether removal is reversible or affects dependencies). Baseline score given 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 sentence with no extraneous words. Every word is functional and concise.

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 simplicity (one parameter, no output schema) and annotations covering destructive behavior, the minimal description is marginally adequate. However, it does not explain post-removal effects or handling of failures, which would be useful for a destructive action.

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 input schema has 100% description coverage for its single parameter, 'Service slug to remove'. The description does not add additional meaning beyond what the schema already provides, so baseline score applies.

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 'Remove a deployed service' uses a specific verb (Remove) and resource (deployed service), clearly distinguishing it from sibling tools like deploy_service, restart_service, etc. The purpose is unambiguous.

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 is provided on when to use this tool versus alternatives (e.g., stop_service vs remove_service), nor are there any prerequisites or conditions mentioned. The description lacks context for appropriate usage.

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

restart_serviceA

Destructive

Restart a deployed service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug identifier

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already convey destructiveHint=true, so description adds no extra behavioral context. Consistent but minimal.

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, concise sentence that is front-loaded and contains no wasted words.

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?

Adequate for a simple restart tool but lacks context on side effects, return values, or behavioral expectations beyond what annotations provide.

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%, but description does not add meaning beyond the schema. 'slug' is described in schema but not elaborated.

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 'Restart a deployed service' is clear with a specific verb and resource. It distinguishes from siblings like start_service and stop_service by implying the service is already deployed.

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 restart vs alternatives like start_service or stop_service. Does not mention prerequisites or conditions.

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

start_serviceC

Destructive

Start a stopped service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug identifier

TDQS

C2.8/5.0

Behavior2/5

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

Annotations indicate this is a write operation (readOnlyHint false) with destructive potential (destructiveHint true). The description adds no further behavioral context, e.g., whether starting fails if already running or what resources are affected.

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?

Extremely concise (4 words), but lacks important usage context. Could be improved with a second sentence without becoming verbose.

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 low parameter count and no output schema, the description seems minimal but fails to differentiate from sibling tools or explain the destructiveHint annotation. Incomplete for safe agent 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?

Schema coverage is 100% with a clear description for 'slug'. The tool description does not add additional meaning beyond the schema, so baseline 3 is appropriate.

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 ('Start') and the resource ('a stopped service'). It distinguishes from siblings like stop_service and restart_service, though it does not explicitly name alternatives.

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 restart_service or deploy_service. Missing when-not-to-use conditions, such as if the service is already running.

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

stop_serviceB

Destructive

Stop a deployed service

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Service slug identifier

TDQS

B3.3/5.0

Behavior2/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds no new behavioral context. It does not clarify side effects, state changes, or reversibility beyond what annotations imply.

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, concise sentence that front-loads the core purpose with no extraneous text.

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 simple tool with one parameter and no output schema, the description is minimally adequate. However, it lacks context about the service state, side effects, or how the slug relates to other tools.

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 slug parameter described as 'Service slug identifier'. The description does not mention parameters, so it adds no value over the schema. Baseline 3 is appropriate.

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 specifies the verb 'stop' and the resource 'deployed service', directly conveying the action. Among siblings like start_service, restart_service, remove_service, it clearly distinguishes this tool's purpose.

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 is provided on when to use this tool instead of alternatives like restart_service or remove_service. The description lacks context about prerequisites or expected states.

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

trigger_collectionA

Destructive

Trigger an immediate earnings collection across all services

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds minimal value by noting 'immediate'. Does not explain what happens during collection or any side effects.

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, efficient and front-loaded.

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?

Lacks details about return value or postconditions. For a tool with no parameters and no output schema, description could provide more context on what the agent should expect after triggering.

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?

Schema has zero parameters with 100% coverage, so description need not add parameter info. Baseline 4 is appropriate.

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 ('Trigger an immediate earnings collection') and scope ('across all services'). It effectively distinguishes from siblings, as no other sibling performs a collection trigger.

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_earnings_daily or get_earnings_history. No warnings about potential impacts despite destructiveHint=true annotation.

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. Dates show when Glama detected each change.

10 tool updatesv0.1.0Apr 3, 2026
- First observeddeploy_service
- First observedget_compose
- First observedget_earnings_daily
- First observedget_earnings_history
- First observedget_service_logs
- First observedremove_service
- First observedrestart_service
- First observedstart_service
- First observedstop_service
- First observedtrigger_collection

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: service lifecycle (deploy, start, stop, restart, remove, get logs, get compose) and earnings (daily, history, trigger collection). There is no overlap; even similar earnings tools are differentiated by time range.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, e.g., deploy_service, get_earnings_daily, stop_service. The verb sets (deploy, get, remove, restart, start, stop, trigger) are clear and predictable.

Tool Count5/5

10 tools is well within the ideal 3-15 range. The set covers service management and earnings without being overly complex or sparse.

Completeness4/5

The service surface covers deploy, manage, and remove, but lacks a list_services tool to see deployed instances. Earnings coverage is good with retrieval and trigger, but no summary. Minor gaps, but core workflows are supported.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

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

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
gainium-mcpOAuth
io.gainium
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
Cryptocurrency Finance
22
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

mcp-llm
Code Execution Autonomous Agents
sammcj
A
license
B
quality
C
maintenance
An MCP server that provides LLMs access to other LLMs
Updated a year ago (2025-03-15 05:37 UTC)
4
48
78
MIT
OpenAPI MCP Server
API Testing Developer Tools App Automation
cloudwarriors-ai
A
license
A
quality
D
maintenance
A generic MCP server that dynamically exposes any OpenAPI-documented REST API to LLMs by auto-discovering endpoints. It provides tools for exploring API capabilities and making authenticated requests directly through natural language interfaces.
Updated 7 months ago (2026-01-27 03:22 UTC)
2
14
MIT
pumperly-mcp
Travel & Transportation Location Services Search
GeiserX
A
license
A
quality
A
maintenance
MCP server that exposes any Pumperly instance to LLMs, enabling real-time fuel price queries, station search, route planning, and geocoding.
Updated 4 days ago (2026-09-02 21:46 UTC)
5
78
3
GPL 3.0
fund402-mcp
Blockchain Cryptocurrency
nickthelegend
F
license
Not graded
quality
C
maintenance
MCP server that exposes Fund402 protocol tools to Casper testnet, allowing LLMs to execute real on-chain actions like wallet creation, token management, and borrowing via natural language.
Updated 2 months ago (2026-07-08 10:01 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GeiserX/cashpilot-mcp'

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

What you get

Quick-start (Docker Compose)

Install via npm (stdio transport)

Local build

Configuration

Testing

Example configuration for client LLMs

Credits

Maintainers

Contributing

Other MCP Servers by GeiserX

Related Projects

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API