This server is an MCP template that enables interaction with Anthropic's Claude API through a single ask_claude tool. Here's what you can do with it:
Ask Claude any question by providing a required prompt, with an optional system prompt to guide Claude's behavior
Get Claude's text response returned directly within your MCP-compatible client (e.g., Claude Desktop)
Integrate with Claude Desktop by configuring it in your claude_desktop_config.json
Use it as a starting point to build your own Claude-powered MCP tools in Rust, leveraging the crimson-crab Rust SDK
It communicates over stdio using the MCP protocol, reads the ANTHROPIC_API_KEY environment variable for authentication, and handles API errors gracefully by returning them as MCP tool errors.
A minimal, production-ready Model Context Protocol
(MCP) server, written in Rust, backed by Anthropic's Claude API through the
crimson-crab SDK. It exposes five
tools: ask_claude (send a prompt, get Claude's reply), chat (multi-turn
conversation), count_tokens (price a prompt without running it), list_models
(enumerate the models your API key can use), and get_model (limits and
metadata for one model).
Use it as the reference starting point for building your own Claude-powered MCP tools in Rust.
Click Use this template on GitHub, or generate a fresh project with
cargo generate:
cargo generate --git https://github.com/singhpratech/crimson-crab-mcp-templateYou can also just clone it:
git clone https://github.com/singhpratech/crimson-crab-mcp-templateRelated MCP server: MCP Server Boilerplate
export ANTHROPIC_API_KEY=sk-ant-...
cargo runThe server communicates over stdio, so running it directly just waits for an MCP
client to connect. All logging goes to stderr — stdout is reserved for the MCP
protocol. Set RUST_LOG=debug for more verbose logs.
To build an optimized binary you can point a client at:
cargo build --release
# -> target/release/crimson-crab-mcp-templateAdd an entry to your Claude Desktop MCP config
(claude_desktop_config.json), pointing at the built binary and passing your API
key through the environment:
{
"mcpServers": {
"claude-via-crimson-crab": {
"command": "/absolute/path/to/target/release/crimson-crab-mcp-template",
"env": {
"ANTHROPIC_API_KEY": "sk-ant-..."
}
}
}
}Restart Claude Desktop; the ask_claude, chat, count_tokens,
list_models, and get_model tools will then be available.
ask_claudeParameter | Type | Required | Description |
|
| yes | The prompt to send to Claude. |
|
| no | Optional system prompt. |
Builds a Claude Messages request (defaulting to the claude-opus-5 model),
calls the API, and returns the concatenated text of Claude's reply.
chatParameter | Type | Required | Description |
|
| yes | The conversation so far, oldest first: |
|
| no | Optional system prompt. |
|
| no | Model id (defaults to the |
|
| no | Maximum tokens to generate (default 1024). |
Sends the whole message history to Claude and returns the next reply — use it
instead of ask_claude when the caller needs to keep context across turns.
count_tokensParameter | Type | Required | Description |
|
| yes | The prompt whose token count you want. |
|
| no | Optional system prompt to include in the count. |
|
| no | Model id to count against (counts are model-specific). |
Returns the number of input tokens the prompt would consume, without running it — useful for estimating cost before an expensive call.
list_modelsParameter | Type | Required | Description |
|
| no | Maximum number of models to return. |
Returns the id, display name, and release date of each Claude model available to the configured API key.
get_modelParameter | Type | Required | Description |
|
| yes | The model id to look up, e.g. |
Returns the model's display name, release date, context window
(max_input_tokens), and maximum output tokens.
Errors from all tools are returned as MCP tool errors rather than panicking. The Claude client is built once at startup and reused across calls.
This template is built with crimson-crab
— a production-grade Rust SDK for Anthropic's Claude API. Source:
https://github.com/singhpratech/crimson-crab.
Licensed under either of
MIT license (LICENSE-MIT)
Apache License, Version 2.0 (LICENSE-APACHE)
at your option.
crimson-crab is an independent open-source project and is not affiliated with Anthropic.
Ask Anthropic's Claude a question and return its answer.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt to send to Claude. | |
| system | No | Optional system prompt that steers Claude's behavior. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, so the description must fully disclose behavior. It only states the basic action (ask and answer) without mentioning safety, idempotency, statefulness, rate limits, or any other behavioral traits.
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, clear sentence with no unnecessary words. It is optimally concise for the information provided.
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 simple Q&A tool with no output schema, the description covers the basic purpose but lacks context on usage scope, response format, or limitations. It is minimally adequate.
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 100% with clear descriptions for both parameters. The tool description adds no extra meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool asks Claude a question and returns an answer, with a specific verb and resource. However, there are no sibling tools to distinguish from, so it loses the chance for a higher score on differentiation.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any conditions or exclusions mentioned. The description is purely functional without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count the input tokens a prompt would consume for a given Claude model, without sending it.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model id to count against (counts are model-specific). Defaults to the same model `ask_claude` uses. | |
| prompt | Yes | The prompt whose token count you want. | |
| system | No | Optional system prompt to include in the count. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately conveys that the tool counts tokens without sending the prompt, which is appropriate for a low-risk tool. However, it does not mention that token counts are model-specific or other potential nuances.
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 consists of a single, front-loaded sentence with no superfluous words. It efficiently conveys the tool's purpose.
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 simple estimation tool with no output schema, the description adequately covers the core functionality. It could mention the return format, but that is relatively minor.
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 input schema already provides descriptions for all three parameters (100% coverage). The tool description adds no additional meaning beyond what the schema provides.
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 that the tool counts input tokens for a given Claude model without sending the prompt. It uses specific verbs and resources, and it distinguishes from sibling tools like 'ask_claude' and 'list_models'.
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 that the tool is for estimating token usage before using 'ask_claude', but it does not explicitly state when to use it versus alternatives or provide any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Claude models available to the configured Anthropic API key.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of models to return (the API defaults to 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. However, it does not disclose any behavioral traits such as authentication requirements, rate limits, or whether the list is sorted. For a simple read-only list, this is a minor gap.
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 consists of one concise sentence that covers the core functionality without any extraneous words. It is efficiently front-loaded with the essential information.
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 tool's simplicity (one optional parameter, no output schema), the description is sufficient for understanding the primary purpose. However, it does not specify what the return value contains (e.g., model IDs, names) or any pagination behavior, which could leave some uncertainty for the agent.
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 100%: the single parameter 'limit' has a clear description in the schema. The description does not add additional meaning beyond what the schema already provides, so baseline 3 applies.
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 explicitly states the action ('list'), the resource ('Claude models'), and the scope ('available to the configured Anthropic API key'). It clearly distinguishes from sibling tools 'ask_claude' and 'count_tokens' by focusing on model listing.
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 usage when the agent needs to query available models, but does not provide explicit guidance on when to use vs. alternatives, nor does it mention any prerequisites or exclusions. Sibling tools have different purposes, so ambiguity is low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: ask_claude handles queries, count_tokens deals with token counting, and list_models retrieves available models. There is no functional overlap.
All tool names follow a consistent verb_noun pattern in snake_case (ask_claude, count_tokens, list_models), making them predictable and easy to use.
With 3 tools, the server is lean and focused on core Claude API interactions. This is appropriate for a minimal template without unnecessary bloat.
The tools cover essential operations: asking questions, counting tokens, and listing models. Minor gaps exist, such as missing streaming or model details beyond listing, but the set is sufficient for basic use.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Cloudflare Workers MCP server: ai-agent-scratchpad
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/singhpratech/crimson-crab-mcp-template'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
