@dayby/mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DAYBY_API_KEY | No | Your DayBy API key (alternative to dayby-mcp auth) | |
| DAYBY_API_URL | No | DayBy API URL | https://dayby.dev |
| DAYBY_BLOCKED_TERMS | No | Comma-separated blocked terms | |
| DAYBY_BLOCKED_DOMAINS | No | Comma-separated blocked domains |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| draft_postA | Create a sanitized draft of a dev progress post. Content is cleaned locally — nothing is sent to the network. Returns a preview for the user to review before publishing. |
| edit_draftA | Edit a draft post before publishing. Provide updated title and/or content — they will be re-sanitized locally. |
| publish_postA | Publish a previously drafted post to DayBy. Only the sanitized version is sent — the original content never leaves your machine. |
| list_postsC | List your recent DayBy posts. |
| get_postA | Get a single DayBy post by its slug. |
| update_postC | Update an existing DayBy post by slug. Content is sanitized locally before sending. |
| update_articleA | Set or replace the HTML article for a DayBy post. Use this to write custom articles with CTAs, rich formatting, or any content the user wants. DayBy article HTML rules:
|
| delete_postA | Permanently delete a DayBy post by its slug. |
| check_contentA | Check if content contains sensitive data without creating a draft. Useful for quick checks before writing a post. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools map cleanly to distinct lifecycle stages: draft, edit, publish, update, delete. The main potential confusion is between update_post and update_article, since both modify an existing post, though their descriptions differentiate general content updates from HTML article replacement.
Tool names mostly follow a clear verb_noun snake_case pattern: list_posts, get_post, publish_post, update_post, delete_post, check_content. Minor deviations exist with edit_draft and update_article, which use different object nouns, and draft_post could be read as a noun phrase, but the overall convention is still predictable.
Nine tools is a well-scoped size for a focused post-management server. Each tool covers a meaningful part of the drafting, publishing, updating, and deletion workflow without redundancy or excessive surface area.
The core lifecycle is covered well: draft, edit draft, publish, list, get, update, delete, and content checking. The main gap is that once a draft is created, there is no explicit way to list or retrieve saved drafts, which could make the edit_draft workflow harder to use.