Provides tools for searching academic papers on arXiv by topic and extracting detailed information about specific papers by their ID.
Employs .env file for environment configuration, specifically for storing the Anthropic API key.
Leverages Node.js runtime environment to execute the MCP server functionality, with v16 or higher required.
Implements the MCP server using TypeScript for type safety and modern JavaScript features.
Uses Yarn package manager for dependency management and script execution.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP TypeScript Demo Server search for recent papers about large language models"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This is a TypeScript implementation of the MCP: Build Rich-Context AI Apps with Anthropic course from DeepLearning.AI.
This project demonstrates the Model Context Protocol (MCP) implementation with streamable HTTP capabilities. MCP is an open protocol that standardizes how LLM applications can access context through tools and data resources using a client-server architecture.
⚠️ This project is for educational and demo purposes only.
Related MCP server: NewsDigest MCP
MCP client-server architecture implementation
Streamable HTTP communication
arXiv paper search functionality
Paper information extraction
Tool selection and argument extraction
Prompt template management
Node.js (v16 or higher)
Yarn package manager
Anthropic API key
Clone the repository
git clone <repository-url>
cd mcp-demoInstall dependencies
yarn installEnvironment Configuration
Create a .env file in the root directory:
ANTHROPIC_API_KEY=<your_anthropic_api_key_here>Important: Replace <your_anthropic_api_key_here> with your actual Anthropic API key.
Build the project
yarn buildmcp-demo/
├── src/
│ ├── client.ts # MCP client implementation
│ ├── server.ts # MCP server implementation
│ └── index.ts # Core functionality and utilities
├── package.json # Dependencies and scripts
├── tsconfig.json # TypeScript configuration
├── yarn.lock # Locked dependencies
└── README.md # This fileyarn start:serveryarn start:clientyarn devThe MCP server provides the following tools:
search_papers - Search for papers on arXiv
Arguments:
topic (string): The topic to search for
max_results (number, optional): Maximum number of results (default: 5)
extract_info - Extract information from a specific paper
Arguments:
paper_id (string): The ID of the paper to look for
search_papers(topic: string, max_results?: number)Searches for papers on arXiv based on a topic and returns their information.
extract_info(paper_id: string)Searches for information about a specific paper by ID from arXiv.
getToolSelectionPrompt(toolList: string, userQuery: string)Generates a detailed prompt for tool selection and argument extraction.
This implementation is based on the MCP: Build Rich-Context AI Apps with Anthropic course by DeepLearning.AI in partnership with Anthropic. The course covers:
Core concepts of MCP
Client-server architecture
Building MCP-compatible applications
Connecting to third-party servers
Deploying MCP servers remotely
For the complete course content, visit: https://learn.deeplearning.ai/courses/mcp-build-rich-context-ai-apps-with-anthropic
This is a demo project for educational purposes. Feel free to experiment and modify the code to learn more about MCP implementation.
This project is for educational purposes only. Please refer to the original course materials for licensing information.
For questions about the MCP protocol or the original course, please refer to:
获取当前日期, 如果用户没有提供日期, 则返回当前日期, 如果用户提供的是相对单位, 如前天, 昨天, 明天, 则返回相对单位后的日期
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | 日期 比如2025-05-29 或者 前天 昨天 明天 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the core behavior (returning current date or calculating relative dates) but lacks important details: format of returned date, timezone handling, error behavior for invalid inputs, or whether this is a read-only operation. The description doesn't disclose these 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 appropriately concise with two sentences that efficiently explain the tool's functionality. It's front-loaded with the main purpose and follows with usage details. There's no wasted text, though it could be slightly more structured for clarity.
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 has no annotations and no output schema, the description is incomplete. It doesn't explain the return format (e.g., date string structure), error handling, or timezone considerations. For a date-handling tool with 1 parameter, more contextual details are needed to ensure proper agent usage.
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 100%, with the parameter 'date' clearly documented in the schema. The description adds some semantic context by explaining the two types of inputs (absolute dates like 2025-05-29 and relative units like yesterday), which complements the schema. However, it doesn't provide additional syntax or format details beyond what the schema already states.
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: '获取当前日期' (get current date) and explains it returns the current date or calculates relative dates like yesterday/tomorrow. It distinguishes from sibling 'get_current_weather' by focusing on dates rather than weather. However, it doesn't explicitly contrast with the sibling tool in the description text itself.
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 context: when users need current date or relative date calculations. It mentions handling both absolute dates (e.g., 2025-05-29) and relative units (e.g., yesterday). However, it doesn't provide explicit guidance on when to use this vs. alternatives or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get weather info for a given city.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | 城市名称, 比如北京 上海 广州 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Get weather info' which implies a read-only operation, but doesn't disclose any behavioral traits like rate limits, error conditions, data freshness, or what 'weather info' includes (e.g., temperature, humidity). This leaves significant gaps for an agent.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'weather info' includes, potential errors, or any operational constraints. For a tool with one parameter but undefined output and behavior, this leaves too much ambiguity for reliable agent use.
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 100%, with the parameter 'city' fully documented in the schema. The description adds no additional meaning beyond implying the tool requires a city input, so it meets the baseline of 3 where the schema does the heavy lifting.
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 verb ('Get') and resource ('weather info') with a specific scope ('for a given city'), making the purpose unambiguous. However, it doesn't explicitly differentiate from the sibling tool 'get_current_date', though the distinction is obvious from the names.
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 or any contextual prerequisites. The description simply states what it does without indicating any constraints, dependencies, or comparison with the sibling tool beyond the obvious domain difference.
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.
v1.0.0get_current_dateget_current_weatherScored across 2 tools
The two tools have completely distinct purposes: one handles date calculations and the other provides weather information. There is no overlap in functionality, making it impossible to confuse them.
Both tools follow a consistent 'get_current_*' naming pattern, which clearly indicates their purpose. The minor deviation is that one description is in Chinese and the other in English, but the naming structure itself is uniform.
With only two tools, this server feels thin and under-scoped for a general-purpose demo. It lacks the depth or breadth expected for a meaningful toolset, making it appear incomplete or trivial.
The server covers two unrelated domains (date and weather) but lacks any cohesive scope. There are significant gaps in both domains—no date manipulation beyond basic relative units and no weather-related operations like forecasts or historical data—making it feel like a random collection rather than a complete surface.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.