Releases: rawveg/devtomcp
Patch Fix - openapi.json
v1.2.0: Rest openapi (#16)
Release Notes: Dev.to MCP Server – Major Feature Release
🚀 Major New Features
-
OpenAPI-Driven REST API
- First implementation of OpenAPI tooling for the Dev.to MCP server.
- All REST endpoints are now fully described and documented via OpenAPI, enabling:
- Auto-generated interactive docs (
/docs) - Machine-readable schema for LLMs, automation tools, and client generation
- Consistent, discoverable, and self-documenting API surface
- Auto-generated interactive docs (
-
RESTful Endpoints for All Core Operations
- Endpoints for reading, creating, updating, publishing, unpublishing, and searching articles, as well as user profile access.
- All endpoints follow RESTful conventions and are documented in the OpenAPI schema.
-
MCP Tool Registration
- All major Dev.to actions are available as MCP tools, with prompt definitions and OpenAPI integration.
- Tools include: browse/search articles, get by ID/title, create, update (by ID and by title), publish/unpublish (by ID and by title), and more.
✨ Enhancements & Improvements
-
Dual-Mode Update Endpoint:
/update_articlesupports both PATCH (RESTful) and POST (for LLM/tool compatibility). -
Update by Title:
New endpoint and tool for updating articles by title, with full OpenAPI and prompt support. -
Explicit API Key Handling:
All endpoints and internal helpers require explicit API key passing.- 401 errors are returned and logged if missing.
-
Comprehensive OpenAPI Schema:
- All endpoints have detailed summaries, descriptions, and response examples (success and failure).
- All Pydantic models and parameters use the new
examples=syntax. - One-shot examples and minimal, action-oriented responses for state-changing endpoints.
-
README & Documentation:
- All new tools and endpoints are documented in the README, including feature tables and usage examples.
🐛 Bug Fixes & Robustness
-
API Key Propagation:
- Fixed all flows to ensure the API key is always passed and required.
- Authentication errors are now surfaced clearly to clients and LLMs.
-
Correct HTTP Methods:
- PATCH is the default for updates, with POST as a temporary compatibility fallback.
-
Consistent Tag Handling:
- Tags are sanitized, lowercased, and omitted if empty.
-
Cleaner Error Handling:
- Dev.to API errors and authentication issues are surfaced with explicit messages and status codes.
-
Logging Improvements:
- Added logging for missing API keys and other critical errors.
🧠 LLM/Tool-Use Optimizations
-
Minimal, Explicit State Change Responses:
- State-changing endpoints (publish/unpublish) return minimal, explicit responses for LLM reliability.
- OpenAPI examples for both success and failure to help LLMs pattern match.
-
Workarounds for LLM Quirks:
- POST support for update endpoints as a temporary workaround for LLMs/tools that ignore PATCH.
🛠️ Developer Experience
-
Interactive API Docs:
/docsendpoint provides a live, interactive OpenAPI UI for testing and exploration.
-
Codebase Consistency:
- All prompt, tool, and endpoint registrations are explicit and consistent.
- Deprecated patterns (e.g.,
example=) have been fully replaced.
⚠️ Known Issues & Future Work
-
LLM Context Handling:
LLMs may still make “smart” guesses based on prior context, which can lead to unexpected tool invocations. Further prompt engineering and OpenAPI fine-tuning may be required for perfect reliability. -
Temporary POST Support:
POST support for/update_articleis a temporary workaround and should be removed once LLM/tooling support PATCH correctly. -
Refactoring:
What started out as a single small script has now evolved into a monolith. For my own piece of mind, maintainability and ongoing work the next release planned will be a bif refactor, separation of concerns, simplifying the tool layer to allow for drop-in tool extensibility and more. A general overhaul to make it neat and tidy. For now enjoy the dual use of SSE and REST with OpenAPI Tool Server. I have been using Open WebUI to test the development of the tool server, and yes it works well and is fairly robust, just needs some fine tuning around prompts and perhaps more documentation examples/one shots for LLM comprehension.
Upgrade Notes
- This is a major release introducing OpenAPI-driven REST endpoints and LLM/MCP tool integration.
- If you are integrating with LLMs or automation tools, ensure they are configured to pass the API key as required.
Thank you for helping shape this release! This is the first full-featured, OpenAPI-powered, LLM-friendly, and self-hostable Dev.to MCP server.
Let me know if you want this in a different format (e.g., CHANGELOG, GitHub release, etc.) or need a shorter/longer version!
Improved Prompt Support - Additional Functionality
New Prompts, New Functionality
All detailed in the README.md, but have added tools to publish/unpublish your articles, view your drafts, view your scheduled articles, and helper tools that allow you to perform functions on your articles based on the article title - these have been incorporated into dedicated prompts too to make sure Natural Language usage is improved (who ever remembers silly long numbers?). See the Changeling for more details.
What's Changed
- Removed unnecessay line duplication by @rawveg in #14
- Add article management functions for drafts and publishing by title/I… by @rawveg in #15
Full Changelog: v1.1.3...v1.1.4
MCP Prompts & Structured JSON Output
New Feature
Prompt support for better LLM utility.
MCP prompts are ready-made templates that make it easier to use your server's tools. They guide you through common tasks, help you find features, and save time by providing clear starting points. With prompts, you don't need to figure out how to structure your requests - you can simply fill in the blanks and get started quickly. Learn more in the MCP Specification
Article Prompts
✅ - get_article_prompt
✅ - list_my_articles_prompt
✅ - create_article_prompt
✅ - update_article_prompt
✅ - delete_article_prompt
✅ - get_article_by_id_prompt
✅ - search_articles_prompt
✅ - analyze_article
User Prompts
✅ - get_user_profile_prompt
✅ - analyze_user_profile
✅ - analyze_user_profile_by_id
The prompts are located within the prompts/ folder and included in the main server.py to preserve separation of concerns and reduce clutter in the main script.
Breaking Change
Endpoints that previously returned pure Markdown output have been modified to return structured JSON instead. This is much better and cleaner and allows for easier integration into automated flows without having to post-process the data.
What's Changed
- Add prompt generation functions for Dev.to API article and user operations - fixed tool output format to structured JSON for easier programmatic utility. by @rawveg in #10
- 8 feature prompts tool by @rawveg in #11
- Add optional params and improve prompt formatting for article managem… by @rawveg in #13
Full Changelog: v1.1.2...v1.1.3
Documentation Update
Updated examples for Google Cloud Run, as they require the passing through of environment variables. This forms part of the existing security warning and the need to warn users about their API Key being on the server if it is deployed in that environment, and would require further - additional - configuration to implement security controls.
Docker update
docker-compose.yml tweak to ensure that the port is driven by the environment variable. Ensuring that change is centralised.
Fix Release
The initial release was fine when working with anything but the authenticated endpoints, at which point there were failures.
This was due to a fundamental issue with the SSE protocol in that you can't pass authentication details through to an application for use. In our case the API KEY, due to technical limitations of the SSE protocol.
Instead we've implemented a change where the API KEY is set as an environment varialble in the .env file, and have added consideration notes and indemnifications to the documentation because if you want to deploy this online, then you're going to need an authentication layer to protect it. Most users are going to be using this as a standalone tool running on their own machine, so the Docker compose setup works just fine.
Initial Release
As described. I've seen implementations of a Dev.to MCP server in different guises, but I needed something a bit more robust that was cloud capable and runnable, so I built this one. Instructions for deployment with GCP Cloud Run included - but no support offered if it doesn't work for you.
Hopefully you'll enjoy.
Please note, if you want to incorporate my work as part of a commercial project or service, then the licensing of this is under AGPLv3, and you need to actively seek my permission to use this service, deploy it on your infrastructure or offer the service IN ANY FORM for a fee, and only then if you pay the appropriate licensing fee.
For everyone else, enjoy :)