cheaplane
Cheaplane π£οΈ
Keep your premium subscription on the main thread. Offload the grunt work to cheap models β Cheaplane even picks the right one for you. Stop burning premium tokens on boilerplate.
Cheaplane is a tiny single-file MCP server (~250 lines, stdlib + mcp only) that gives your main agent β e.g. Claude Code on a Max subscription β one extra tool: delegate. Your agent keeps doing the thinking (planning, architecture, final review) and hands replaceable grunt work β boilerplate code, formatting, translation, summarizing long docs β to cheap models behind a local LiteLLM proxy (DeepSeek, Kimi, Qwen, β¦). Think of it as a cheap intern for your premium agent β it churns out the boring parts while you keep thinking.
The trick that makes it safe: the delegated calls and your subscription live in physically separate processes and never share credentials. (why that matters β¬οΈ)
The trick that makes it effortless: auto-routing. delegate(task) picks the right cheap model from the task itself β code β DeepSeek, long docs β Kimi, Chinese β Qwen. (how β¬οΈ)
The trick that makes it stick: a per-turn reminder hook so your agent doesn't forget the tool exists β the part most "delegate" tools skip. And a savings ledger shows you what it kept off your quota.
See it in action β your agent hands a chore over; auto-routing sends it to the cheap code model:
delegate("convert to a TypeScript interface: {id, name, email, isAdmin, roles[]}")interface User {
id: number;
name: string;
email: string;
isAdmin: boolean;
roles: string[];
}β a real call's output β not a mockup, and no model picked by hand. That token cost ~90Γ less than your premium model, and your subscription quota never moved.
The problem
Premium models earn their price on hard problems β but every token counts against your plan, and you burn through quota on churn: reformatting JSON, translating UI strings, summarizing a doc you'll read once. The usual "just use a cheap model" setups force an ugly choice:
Downgrade the whole agent β you lose main-thread quality on the work that actually matters.
Route everything through an API key β you stop using the subscription you're already paying for.
Cheaplane keeps the sweet spot: premium main thread for judgment + cheap models for the churn + billing that physically can't cross.
Related MCP server: any-model-plugin
How Cheaplane compares
The popular 2026 move is to swap your whole agent onto a cheap model (DeepClaude-style). Great for raw cost β but it downgrades the thread you actually think with, breaks your other MCP tools, and doesn't even apply if you're on a Pro/Max subscription. Cheaplane takes the opposite bet:
Swap whole agent β cheap model (DeepClaude-style) | Everything via one API key | Cheaplane | |
Main thread | β¬οΈ downgraded | β¬οΈ no more subscription | β stays premium |
Your other MCP tools | β break | β | β (it is an MCP server) |
Works on a Pro/Max subscription | β API-key only | β replaces it | β built for it |
Picks the cheap model for you | β one model for everything | β | β
|
Shows what you saved | β | β | β
|
Billing | merged into one | one per-token bill | π subscription + cheap, isolated |
Comparison reflects how backend-swap setups (DeepClaude-style) behaved per public reports in mid-2026; specifics vary by tool and can change.
How cheap is "cheap"?
The grunt work is the easy part β paying premium rates for it is pure waste. Per million tokens (public list prices, mid-2026):
Model | Input | Output | Best for |
Claude Opus (API, for reference) | $5.00 | $25.00 | the judgment work you keep |
DeepSeek V4 Flash | $0.14 | $0.28 | code / formatting |
Kimi K2 | $0.60β0.95 | $2.50β4.00 | long docs (very large context) |
Qwen | $0.05β0.40 | $0.20β1.20 | Chinese copy |
That's an output token costing ~$25 on Opus vs ~$0.28 on DeepSeek β about 90Γ more for work that doesn't need the smarts. You're on a subscription, so you don't pay that $25 directly β your main thread spends quota, not dollars. That's the whole point: every routine task you offload is premium quota you keep for the hard problems. (Summarizing a 40-page doc on DeepSeek Flash runs ~$0.005 β your quota never even notices.)
Prices are public list rates, mid-2026, and vary by tier/caching β check each provider. The stable takeaway is the order-of-magnitude gap, not an exact dollar saving.
Billing isolation (the whole point)
Most "save money" hacks blur your bills together. Cheaplane keeps them physically apart:
flowchart LR
A["Main agent<br/>premium subscription"] -->|"delegate(task)"| B["Cheaplane MCP<br/>own process, own key"]
B -->|HTTP| C["LiteLLM proxy<br/>localhost:4000"]
C --> D["DeepSeek / Kimi / Qwen<br/>cheap, pay-per-use"]The Cheaplane process never imports your subscription provider's SDK, never reads its auth, never touches its OAuth token. It knows exactly one thing: an HTTP endpoint (your proxy) and its key. Your main thread bills to your subscription; delegated calls bill to your cheap proxy. The two can't cross β not by policy, by architecture.
Quick start
Fastest path β Claude Code, one script:
git clone https://github.com/millennialdreamer/cheaplane && cd cheaplane
cp litellm.yaml.example litellm.yaml # then: export DEEPSEEK_API_KEY=sk-...
litellm --config litellm.yaml & # start the cheap-model proxy on :4000
bash setup.sh # deps + register MCP + reminder hook + verifysetup.sh is idempotent (safe to re-run): it installs deps, registers the delegate MCP server with Claude Code, installs the per-turn reminder hook, and verifies the chain end-to-end. Then start a fresh Claude Code session β done.
Prefer a package? Cheaplane is on PyPI β no clone, no path to hard-code:
pip install cheaplane # or: uvx cheaplane / pipx install cheaplane
claude mcp add delegate cheaplaneYou still want the proxy from step 1 below, and the reminder hook is worth it β that part needs the repo.
1. Get an OpenAI-compatible endpoint for the cheap models. Most people run LiteLLM locally as a proxy in front of DeepSeek / Kimi / Qwen. A minimal config is ~5 lines:
# litellm.yaml β exposes DeepSeek under the model_name "deepseek"
model_list:
- model_name: deepseek
litellm_params:
model: deepseek/deepseek-chat # swap for any provider/model LiteLLM supports
api_key: os.environ/DEEPSEEK_API_KEYpip install 'litellm[proxy]'
litellm --config litellm.yaml # serves http://localhost:4000That model_name: deepseek lines up with Cheaplane's default alias, so it works out of the box. (deepseek is a built-in LiteLLM provider β no api_base needed; you'd add one only for a custom or self-hosted endpoint.) Already have an OpenAI-compatible endpoint (LiteLLM, OpenRouter, Ollama, vLLMβ¦)? Skip this and just point DELEGATE_BASE_URL at it.
2. Install Cheaplane β from PyPI, or from a clone if you also want the reminder hook and probe.py:
pip install cheaplane # installs a `cheaplane` command; that's the whole installgit clone https://github.com/millennialdreamer/cheaplane && cd cheaplane
uv sync # or: python -m venv .venv && .venv/bin/pip install mcp3. Register it with your MCP client. Installed from PyPI β the command is already on your PATH:
{
"mcpServers": {
"delegate": { "command": "cheaplane" }
}
}From a clone β copy .mcp.json.example to .mcp.json in the repo root and fix the path (or use claude mcp add):
{
"mcpServers": {
"delegate": {
"command": "uv",
"args": ["run", "--directory", "/ABSOLUTE/PATH/TO/cheaplane", "python", "server.py"]
}
}
}4. Verify it end-to-end β with your proxy from step 1 running (handshake β list tools β a real delegated call):
uv run python probe.py
# β
chain works (main β MCP β cheap model β back)Using delegate
Your agent now has delegate(task) β routing is automatic; override only when you want to:
delegate("convert this JSON to a TypeScript interface: β¦") # auto β deepseek (code)
delegate("summarize this 40-page contract: β¦") # auto β kimi (very long input)
delegate("β¦Chinese text in the task auto-routes hereβ¦") # auto β qwen (Chinese copy)
delegate("translate these UI strings to Japanese", "flash") # explicit alias still winsalias | good for |
| default β picks one of the below from the task itself |
| code / balanced |
| reasoning / multi-step |
| fast / formatting / translation |
| long documents (very large context) |
| Chinese copywriting |
Aliases map to your LiteLLM model_names. Point them at your proxy without editing code β set the DELEGATE_MODEL_MAP env var (a JSON object), or drop a ~/.claude/delegate-model-map.json (hot-reloaded β no restart needed); editing MODEL_ALIASES in server.py also works.
Delegate (let the cheap model do it):
boilerplate / scaffolding from a clear spec
mechanical refactors, formatting, lint fixes
translation; summarizing or extracting facts from long docs
routine prose: changelogs, docstrings, commit messages
Keep (you do it yourself):
planning, architecture, technical trade-offs
final review of delegated output β always you
talking to the user; judgment calls
anything where being subtly wrong is expensive
The delegated model sees only your task string β it has no access to your conversation. Make each task self-contained: spec + the actual input + the exact output format you want.
See what you saved
Every delegated call appends one line of metadata only β never the task content β to ~/.cheaplane/usage.jsonl. Ask your agent for savings any time (sample output):
Cheaplane savings β all time
delegated calls : 184
tokens offloaded: ~412,300 in / ~365,800 out
premium cost avoided (Opus list): ~$11.21
actually spent (DeepSeek-class) : ~$0.16 (β70Γ cheaper, in+out blended)
last 7 days : 31 calls, ~$2.04 avoidedNumbers are estimates at public list prices β the real win is the premium quota that never left your subscription. The ledger records token counts and model names only; delete the file any time, or set DELEGATE_NO_LOG=1 to turn logging off entirely.
Make your agent actually use it
Here's the dirty secret of every "delegate to a cheap model" tool: installing it isn't the hard part β getting your agent to actually use it is. Drop a tool into an agent and, a few turns into a real task, it forgets the tool exists and grinds through the grunt work itself on premium tokens. The instruction sinks down the context; attention moves on.
Cheaplane ships the fix in the box β three layers you can stack:
Skill (
SKILL.md) β teaches the agent when to delegate. Works on any client; passive, so treat it as the baseline.A one-line default in your
CLAUDE.md/ system prompt: "Before doing replaceable grunt work yourself, delegate it." Stronger β but a static instruction still drifts down a long conversation.A per-turn reminder hook β the reliable one (Claude Code). It re-injects the nudge on every prompt, so the habit never sinks out of view. This is what turns an installed tool into a used one.
On other MCP clients (no UserPromptSubmit hook system), use layers 1β2 β wire the one-liner into whatever system prompt your client supports.
Install the hook β safe and idempotent (backs up your settings, merges instead of overwriting, de-dupes on re-run):
bash install-hook.sh # registers hooks/delegate-reminder.sh as a UserPromptSubmit hook
# verify it's wired up:
python3 -c "import json,os;s=json.load(open(os.path.expanduser('~/.claude/settings.json')));print([h['command'] for e in s.get('hooks',{}).get('UserPromptSubmit',[]) for h in e.get('hooks',[])])"Start a fresh session, and your agent self-checks every turn: "is this replaceable grunt work? β delegate it."
The reminder costs ~60 tokens per turn β trivially less than the hundreds of premium tokens a single forgotten delegation burns. The hook uses Claude Code's UserPromptSubmit mechanism.
Config
Env var | Default | Meaning |
|
| OpenAI-compatible endpoint (your proxy) |
|
| key for that endpoint |
|
| per-call timeout (seconds) |
| (none) | JSON remapping aliases, e.g. |
|
| where the savings ledger lives |
| (unset) | set to |
FAQ
Will this leak my subscription credentials?
No. The delegate tool runs in its own process and only ever makes a plain HTTP call to the endpoint you configure. It never imports your subscription SDK and never sees its auth β see Billing isolation.
What exactly does the savings ledger record?
One JSON line per call: timestamp, alias, model name, and token/character counts. Never the task text, never the model's output. Delete ~/.cheaplane/usage.jsonl any time, or set DELEGATE_NO_LOG=1.
How does auto decide which model to use?
A small deterministic heuristic in server.py (_pick_model, ~20 lines you can read and tweak): code signals β deepseek, very long input β kimi, Chinese-heavy β qwen, multi-step language β mimo, short mechanical chores β flash. An explicit alias always overrides it.
How is this different from just using one API key for everything? With a single API key you stop using your subscription entirely and pay per token for all work β including the hard parts. Cheaplane keeps your subscription as the premium main thread and sends only the cheap, replaceable churn elsewhere.
Does it work with anything besides Claude Code? Yes β any MCP-compatible client (Cursor, Cline, Windsurf, β¦). The main agent just needs to support MCP tools; see Manual setup for the generic JSON config.
Do I have to use DeepSeek / Kimi / Qwen?
No. Anything reachable through an OpenAI-compatible endpoint works; the aliases are just convenience labels you can remap with DELEGATE_MODEL_MAP.
Why a proxy instead of calling providers directly? One endpoint, one key, usage logging, and easy model swaps β and it keeps provider keys out of the MCP server entirely.
Roadmap & ideas (help wanted)
Cheaplane's core stays deliberately tiny β but the surface it opens up is big. Shipped so far: β auto-routing (v0.2), β savings ledger (v0.2). Still worth building β proposals and PRs welcome, and most are small enough to be good first issues:
Smarter routing β the current router is a readable heuristic; better signals (or a learned router) are an open playground.
Richer savings dashboard β the ledger is plain JSONL; a
cheaplane statsHTML view would be lovely.Result cache β skip re-delegating identical tasks.
Auto-review β lint/test code that comes back before you trust it.
Batch / parallel delegate β hand off several chores in one call.
More client adoption recipes β the reminder hook targets Claude Code's
UserPromptSubmit; Cursor / Cline / others want their own nudge.
Design rule: keep the core single-file and dependency-light β that's the whole point. Build extensions as opt-in, so the 5-minute read stays a 5-minute read.
Contributing
Issues and PRs welcome β it's ~250 lines of single-file Python with no heavy deps, easy to hack on. Add a useful model alias, a routing signal, or a client recipe and send it over.
License
MIT β see LICENSE.
Available Tools
3 toolsdelegateA
Offload a self-contained subtask to a cheaper model and return its output.
WHEN TO USE: hand off replaceable grunt work to save your premium tokens β boilerplate code, small bug fixes, formatting, translation, reading/summarizing long documents, drafting routine copy. Do NOT delegate judgment work (planning, architecture, final review, talking to the user) β keep that for yourself.
The delegated model sees ONLY the task string and has NO access to this
conversation. So make task fully self-contained (include all needed context).
Args: task: Complete, self-contained instruction for the cheap model. model: "auto" (default) routes by task β codeβdeepseek, long docsβkimi, Chineseβqwen, multi-stepβmimo, quick choresβflash. Or force an alias (deepseek/mimo/flash/kimi/qwen) or a raw proxy model_name. max_tokens: Output cap. Default 4000 (kept large so reasoning models that spend budget on hidden thinking still return non-empty text).
Note: a call typically takes ~10-60s (longer for big inputs) and blocks until the cheap model returns, so prefer one focused task per call.
Returns: The model's text output, or a string starting with "[delegate-error]" on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| model | No | auto | |
| max_tokens | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses that the model sees only the task string, has no conversation access, blocks for ~10- 60s, routes models by task, and returns an error-prefixed string on failure. It also explains the max_tokens rationale, making runtime behavior predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries information: usage boundaries, parameters, latency, failure mode, and return value. It is front-loaded with the core purpose and uses clear section labels (WHEN TO USE, Args, Note, Returns) for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, what each parameter means, what the model sees, how long it takes, and what is returned on both success and failure. Nothing essential is missing for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain the parameters. It defines task as self-contained, explains the auto routing behavior for model with specific model aliases, and gives the default and purpose of max_tokens. This is more than enough to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: offloading a self-contained subtask to a cheaper model and returning its output. It clearly distinguishes itself from premium-token work and from the unrelated siblings (savings, list_models) by defining its exact role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit WHEN TO USE section with concrete examples of acceptable grunt work and an explicit DO NOT delegate list for judgment work. This gives an agent clear criteria for choosing this tool over doing the work itself or using another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_modelsA
List the model aliases available to delegate(), with their best use.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' indicates a read-only, side-effect-free operation, and the output content is specified as aliases plus their best use. No mutation or destructive behavior is suggested.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that front-loads the key information with no filler. Every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter, read-only, output-schema-bearing nature of the tool, the description fully covers what the agent needs: what it returns and why it matters for delegate().
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details and focuses on what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb ('List'), a concrete resource ('model aliases available to delegate()'), and the value add ('with their best use'). This clearly distinguishes the tool from delegate and the unrelated savings sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'available to delegate()' tells the agent this is the lookup step before selecting a delegate model, so the usage context is clear. It does not explicitly state when not to use it or compare it with savings, so it stops short of full explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
savingsA
Show what delegating has kept off your premium quota (estimates, list prices).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It indicates a read-only reporting behavior by saying 'Show' and names the output categories, but it does not disclose data sources, freshness, or what exactly 'kept off your premium quota' means. This is acceptable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that leads with the action and object, then adds a clarifying parenthetical. Every word contributes meaning, and there is no wasted or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only savings overview with an output schema available, the description conveys enough purpose and scope to guide an agent. It could elaborate on what 'premium quota' encompasses or what estimates/list prices derive from, but these are minor gaps for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description still adds semantic context by explaining what the savings refer to: delegation effects on premium quota, estimates, and list prices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing the savings that delegating has produced, specifically in terms of premium quota, estimates, and list prices. It uses a specific verb and resource, making it distinguishable from sibling tools like delegate and list_models, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for viewing delegation-related savings, but it gives no explicit guidance on when to use this tool versus delegate or list_models. No when-not-to-use conditions or alternative recommendations are provided.
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.
3 tool updates
v0.2.1- First observed
delegate - First observed
list_models - First observed
savings
TDQS
Each tool covers a distinct function: performing a delegation, viewing accumulated savings, and listing available models. There is no overlap or ambiguity between them.
delegate and list_models are imperative verbs, but savings is a noun and doesn't follow a verb_noun pattern. The mixed conventions are still readable.
Three tools is lean but well-scoped for a delegation utility: one core action, one supporting reference, and one feedback metric. Each earns its place.
The core delegation workflow is covered: choose a model, delegate, and review savings. A minor gap is the lack of pre-delegation cost estimation or detailed history, but it does not create a dead end.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- projectsOAuthcloud.tri2b
Task tracking built for coding agents. Work is leased, so two agents never take the same SubTask.
- AgentdaOAuthcom.myagentda
Agent-native task management: your AI agent is the interface. Delegate to anyone by email.
Human-as-a-Service for AI agents. Delegate tasks that need a real human, get results via API.
Delegate tasks to vetted human experts - research, writing, analysis, and data work.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI to delegate boilerplate, drafts, tests, and refactors to free LLM providers, saving tokens and running tasks in parallel.428MIT
- AlicenseNot gradedqualityAmaintenanceEnables AI agents to delegate tasks, run adversarial reviews, and manage background jobs across multiple models and providers via anymodel_* tools.Apache 2.0
- FlicenseAqualityBmaintenanceA delegation socket MCP server that enables a driver code agent to hand off subtasks to a cheap local worker (e.g., OpenCode) via a single MCP tool call and pick up results asynchronously without breaking flow.5-
- AlicenseBqualityCmaintenanceDelegates heavy, repetitive, and verifiable tasks like PDF extraction, code analysis, and log processing to a local LLM to reduce token consumption for frontier AI models, while keeping decision-making with the main AI.8MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/millennialdreamer/cheaplane'
If you have feedback or need assistance with the MCP directory API, please join our Discord server