Cookiecat is a Cursor/Agent MCP plugin that wraps RelayRouter’s OpenAI-compatible API: list models and run non-streaming chat completions.
Ownership: Meyra
Version: 0.1.0
License: MIT
Tools: list_models, chat_completion (non-streaming)
Never commit API keys. Set them only via:
Cursor → Plugins → Configure (plugin variables RELAYROUTER_API_KEY, optional RELAYROUTER_BASE_URL), or
A local gitignored .env (copy from .env.example) / shell export for smoke tests.
Default base URL: https://api.relayrouter.ai/v1 (also compatible with https://relayrouter.io/v1).
Related MCP server: rapidrouter-mcp
cd /path/to/cookiecat # or this repo
npm install
npm run bundle # writes dist/cookiecat.mjs (SDK + zod inlined)Marketplace / clone installs should ship dist/cookiecat.mjs so node can start without node_modules.
Add this folder as a plugin, or clone into the plugin search path.
mcp.json runs: node ${CURSOR_PLUGIN_ROOT}/dist/cookiecat.mjs
Configure RELAYROUTER_API_KEY (required) and optional RELAYROUTER_BASE_URL in Plugins → Configure.
{
"mcpServers": {
"cookiecat": {
"command": "node",
"args": ["/absolute/path/to/cookiecat/dist/cookiecat.mjs"],
"env": {
"RELAYROUTER_API_KEY": "YOUR_KEY_FROM_CONFIGURE_OR_ENV",
"RELAYROUTER_BASE_URL": "https://api.relayrouter.ai/v1"
}
}
}
}For source hot-reload during development: "command": "npx", "args": ["tsx", "/absolute/path/to/src/index.ts"] (needs npm install).
npm run bundle
npm run typecheck
# missing key → clear error:
RELAYROUTER_API_KEY= npm run smoke
# with key → list_models + short chat:
npm run smokeCommand | Purpose |
| esbuild → single |
|
|
|
|
|
|
| typecheck only |
| API smoke without an MCP client |
.gitignore ignores node_modules, .env, *.key; keeps dist/cookiecat.mjs for clone-runnable installs
Logs/replies mask keys (at most first 4 + last 4 chars)
Do not put real secrets in the repo or Marketplace forms
Non-streaming chat completion via RelayRouter (POST /v1/chat/completions, stream=false). Returns assistant content and usage.
| Name | Required | Description | Default |
|---|---|---|---|
| stop | No | ||
| model | Yes | Model id from list_models, e.g. deepseek-v4-flash | |
| tools | No | Optional OpenAI-style tools | |
| top_p | No | ||
| messages | Yes | Chat messages (system|user|assistant|tool) | |
| max_tokens | No | ||
| temperature | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it does add real value beyond the schema: the underlying endpoint, the non-streaming guarantee, and the fact that content plus usage are returned. It omits auth/API-key requirements, rate limits, error behavior, and whether tool calls are honored, which matter for a remote LLM invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact clauses, front-loaded with the operation type and endpoint, with zero filler. Every fragment conveys something the caller can act on.
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 partially covers outputs ('assistant content and usage') which is valuable given no output schema, but with 7 parameters at 43% coverage and no annotations, a caller still lacks guidance on tuning parameters, error handling, or auth. Adequate as a minimum-viable definition, not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 43%, so the description should compensate but instead says nothing about the seven parameters — no mention of temperature/top_p tuning, max_tokens, stop sequences, or the tools array. The only useful parameter hint (model comes from list_models) lives in the schema, not the description.
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?
States a specific verb+resource (non-streaming chat completion) and anchors it to a concrete endpoint (POST /v1/chat/completions). The 'non-streaming' qualifier implicitly separates it from a streaming variant, though it doesn't explicitly reference the only sibling, list_models, which is trivial anyway.
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?
Usage is only implied: 'stream=false' signals this is the choice when you do not want a streamed response, but there is no explicit when-to-use/when-not-to-use statement or pointer to alternatives for token budgeting or model selection. The agent must infer the operating context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List models available on RelayRouter (GET /v1/models). Returns model ids and any upstream fields such as object/owned_by.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it does disclose that this is a GET against /v1/models and what the response contains (model ids plus upstream fields like object/owned_by). It says nothing about authentication requirements, rate limits, or whether listing is filtered/paginated, which are the remaining behavioral questions for a live API call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and endpoint, with the return contents appended. Nothing redundant or padded.
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?
No output schema exists, so the description must convey return values, which it does at a high level (model ids, object/owned_by). It stops short of describing the response envelope shape (e.g., whether results are wrapped in a data array), a minor gap for a simple list 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 takes zero parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly conveys that no inputs are required.
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?
States a specific verb and resource ("List models available on RelayRouter") and even names the underlying endpoint GET /v1/models, so the operation is unambiguous. It does not explicitly contrast itself with the sibling chat_completion, but the read-only listing nature makes the distinction fairly evident.
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?
Usage is only implied: an agent can infer this is a discovery call to enumerate model ids before issuing a chat_completion. There is no explicit statement of when to use it, when not to, or what to do with the results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0chat_completionlist_modelsScored across 2 tools
The two tools have clearly distinct purposes: one lists available models and the other performs a chat completion. There is no meaningful overlap in resource or action.
Both names use snake_case and are readable, but the pattern is not fully uniform: list_models is verb_noun while chat_completion is noun-oriented without a clear verb. Minor deviation only.
Two tools is thin for a RelayRouter-style server, even if the immediate scope is minimal. It covers a basic workflow but leaves little room for common adjacent operations.
The surface includes model listing and non-streaming chat completion, but omits obvious adjacent capabilities such as streaming responses or richer model retrieval. Core chat use is covered, with notable gaps for a fuller API wrapper.
Connect MCP clients to 2,000+ AI models without managing provider API keys.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Chat, image, video, and audio models from many vendors behind one remote MCP server and one key.
OpenAI-compatible LLM gateway: pay per request with an API key, signed receipt for each call.
