How do I use MCP Server Medium?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server Medium publish a post titled 'MCP Server Setup Guide'" 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.

MCP Server Medium

by afikrim

Overview Schema Related Servers Score Discussions

Python

Remote

MCP Server Medium

MCP (Model Context Protocol) server for interacting with the Medium API. Allows AI agents to publish posts, manage publications, upload images, and parse RSS feeds to JSON.

Quick Start

# Run with uvx (no install needed) — uses MEDIUM_API_KEY env var
MEDIUM_API_KEY=your_token_here uvx mcp-server-medium

# Or use a config file instead
mkdir -p ~/.medium
echo 'api_key: your_token_here' > ~/.medium/config.yaml
uvx mcp-server-medium

# Or install and run
uv tool install mcp-server-medium
mcp-server-medium

Related MCP server: Paragraph MCP

Authentication

The server resolves your API key in this order:

MEDIUM_API_KEY environment variable — best for MCP clients
~/.medium/config.yaml — persistent local config

Create ~/.medium/config.yaml:

api_key: your_integration_token_here

Get your token at medium.com/me/settings (look for "Integration Tokens").

Tools

Tool	Description
`get_profile`	Get the authenticated user's Medium profile
`list_publications`	List all publications the user is related to
`list_contributors`	List contributors for a publication
`create_post`	Create a post on the user's Medium profile
`create_publication_post`	Create a post under a specific publication
`upload_image`	Upload an image to Medium from a URL
`get_rss_feed`	Fetch and parse Medium RSS feeds into JSON

RSS Feed Shorthands

The get_rss_feed tool accepts flexible input:

Shorthand	Resolves to
`@username`	`https://medium.com/feed/@username`
`publication-name`	`https://medium.com/feed/publication-name`
`tag/tag-name`	`https://medium.com/feed/tag/tag-name`
`pub-name/tagged/tag`	`https://medium.com/feed/pub-name/tagged/tag`
Full URL	Used as-is

Development

# Clone and setup
git clone https://github.com/afikrim/medium-mcp-server
cd medium-mcp-server
uv sync

# Run locally
MEDIUM_API_KEY=your_key uv run medium-mcp-server

# Use with MCP inspector
MEDIUM_API_KEY=your_key npx @modelcontextprotocol/inspector uv run medium-mcp-server

Configuration

Configure in your MCP client (e.g., Claude Desktop, Cursor):

{
  "mcpServers": {
    "medium": {
      "command": "uvx",
      "args": ["mcp-server-medium"],
      "env": {
        "MEDIUM_API_KEY": "your_token_here"
      }
    }
  }
}

Or using the config file (no env needed):

{
  "mcpServers": {
    "medium": {
      "command": "uvx",
      "args": ["mcp-server-medium"]
    }
  }
}

With ~/.medium/config.yaml:

api_key: your_token_here

License

MIT

Available Tools

7 tools

create_postB

Create a post on the authenticated user's Medium profile

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags to classify the post (max 3, max 25 chars each)
`title`	Yes	The title of the post (max 100 chars for SEO, must also be in content body)
`content`	Yes	The body of the post in HTML or Markdown format
`license`	No	License for the post
`author_id`	Yes	The author's user ID (from get_profile)
`canonical_url`	No	Original home of this content if published elsewhere
`content_format`	Yes	Format of the content: 'html' or 'markdown'
`publish_status`	No	Publish status: 'public', 'draft', or 'unlisted'
`notify_followers`	No	Whether to notify followers of the publication

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description only says 'Create a post', implying write behavior. Missing details on authentication, rate limits, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise sentence with zero wasted words. Front-loaded with key action and context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 9 parameters, 4 required, and no output schema, the description is too minimal. It doesn't explain how to obtain author_id, required content_format, or constraints like tags max 3.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline 3. Description adds no extra meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Create' and resource 'post on authenticated user's Medium profile'. It distinguishes from sibling create_publication_post, which is for publications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like create_publication_post. No prerequisites or context provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_publication_postB

Create a post under a specific Medium publication

ParametersJSON Schema

Name	Required	Description
`tags`	No	Tags to classify the post (max 3, max 25 chars each)
`title`	Yes	The title of the post (max 100 chars for SEO)
`content`	Yes	The body of the post in HTML or Markdown format
`license`	No	License for the post
`canonical_url`	No	Original home of this content if published elsewhere
`content_format`	Yes	Format of the content: 'html' or 'markdown'
`publication_id`	Yes	The publication ID to post under (from list_publications)
`publish_status`	No	Publish status. Writers can only use 'draft'. Editors can use 'public', 'draft', or 'unlisted'.
`notify_followers`	No	Whether to notify followers of the publication

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It fails to disclose behavioral traits such as permission requirements (e.g., only editors can publish) or side effects. For a mutation tool with complex authorization, more transparency is needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no extraneous information. It efficiently conveys the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite high parameter coverage in schema, the description lacks context about the result of the operation (e.g., returns a post object), authorization nuances, and integration with other tools. This is insufficient for a complex tool with 9 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents parameters. The description adds no extra semantics beyond the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (create) and the resource (post) with a specific qualifier (under a specific Medium publication). It effectively distinguishes from the sibling tool 'create_post' which is likely for personal posts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for publication posts via the name and contextual qualifier, but does not explicitly state when to use this tool versus alternatives like 'create_post'. No exclusion or prerequisite guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_profileA

Get the authenticated user's Medium profile (id, username, name, url, imageUrl)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It indicates a read operation and lists output fields, but does not disclose authentication requirements, rate limits, or error behavior. For a simple getter, this is adequate but leaves gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no fluff. Every word contributes to understanding the tool's purpose and output.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is mostly complete: it states the action, resource, and return fields. Missing is a note on authentication or error conditions, but for a profile getter, it is nearly sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description adds value by listing the fields the profile contains (id, username, name, url, imageUrl), which is meaningful beyond the empty schema. Per guidelines, baseline 4 applies for 0 params.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the specific resource 'authenticated user's Medium profile', listing the fields returned. It distinguishes from siblings like create_post and list_publications, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving the authenticated user's profile but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The context from siblings offers indirect differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_rss_feedA

Fetch and parse a Medium RSS feed into JSON. Supports profile (@username), publication (publication-name), topic feeds (tag/tag-name), or any full feed URL

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max number of entries to return (default: all)
`feed_url`	Yes	RSS feed URL or shorthand. Examples: '@username', 'publication-name', 'tag/software-engineering', or full URL like 'https://medium.com/feed/@username'

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must convey behavioral traits. It only mentions fetching and parsing into JSON, omitting details like authentication requirements, rate limits, error handling, or behavior with invalid URLs. The description is insufficient for safe usage without these clarifications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the main action ('Fetch and parse a Medium RSS feed into JSON') and efficiently lists supported input types. Every word is meaningful with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has only two parameters and no output schema. The description explains what it does but does not specify the structure of the returned JSON (e.g., fields like title, link, pubDate). While common RSS fields are predictable, the agent would benefit from knowing the exact output format for downstream usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters completely. The description adds value by explaining shorthand formats (e.g., '@username', 'publication-name') and providing examples for feed_url, as well as clarifying that limit defaults to all. This enhances usability beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches and parses Medium RSS feeds into JSON, listing specific feed types (profile, publication, topic, full URL). This distinguishes it from sibling tools like create_post or get_profile, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides examples of feed URL formats but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage context is implied by the tool's purpose, but there is no guidance on exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_contributorsA

List contributors for a given publication

ParametersJSON Schema

Name	Required	Description	Default
`publication_id`	Yes	The publication ID (from list_publications)

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the tool lists contributors but does not disclose whether it is read-only, any authentication needs, rate limits, or the structure of the output. The behavioral transparency is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly states the tool's purpose. It is front-loaded and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter and no output schema, the description is adequate but lacks details on what contributors information is returned (e.g., names, roles, pagination). The context signals indicate low complexity, so a score of 3 is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a single parameter described. The description adds value by specifying that the publication_id comes from list_publications, providing context beyond the schema type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is concise and specific: 'List contributors for a given publication'. It clearly identifies the action (list) and resource (contributors) and distinguishes from sibling tools like 'list_publications' or 'create_post'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description does not mention any prerequisites, context, or when another tool would be more appropriate. This leaves the agent without decision support for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_publicationsA

List all publications the authenticated user is related to (edits, writes, or follows)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Only states what the tool does, not behavioral details like pagination, sorting, data freshness, or what happens if no publications exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with purpose, no redundant information. Every word is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple, parameterless list tool. Could mention return format, but given no output schema and simple scope, it's reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist (0 params, 100% schema coverage). Baseline for 0 params is 4. No need for additional param info in description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states verb 'List', resource 'publications', and scope 'authenticated user is related to (edits, writes, or follows)'. Clearly distinguishes from sibling tools like create_post or list_contributors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description clearly indicates when to use: listing publications associated with the authenticated user. No exclusions or alternatives are mentioned, but the context is clear enough for this simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

upload_imageC

Upload an image to Medium from a URL or file path

ParametersJSON Schema

Name	Required	Description	Default
`image_url`	Yes	Public URL of the image to upload. Medium will fetch and host it.

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the burden. It mentions that Medium will fetch and host the image, providing some transparency about the side effect. However, it lacks details on permissions, size limits, or return value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise at 9 words, but the inaccuracy about file path reduces effectiveness. Could be improved by accurately stating 'from a public URL'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (1 parameter, no output schema), the description is minimally complete but lacks usage context and error handling information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already fully describes the parameter with 100% coverage, so baseline is 3. However, the description adds misleading info about 'file path' which is not a parameter, reducing clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool uploads an image, but inaccurately mentions 'file path' when only URL is supported by the schema. This slightly misleads the purpose. It does distinguish from sibling tools like create_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives. Does not mention prerequisites like needing an image URL to embed in a Medium post.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jun 28, 2026
- First observedcreate_post
- First observedcreate_publication_post
- First observedget_profile
- First observedget_rss_feed
- First observedlist_contributors
- First observedlist_publications
- First observedupload_image

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct action or resource: creating personal vs publication posts, fetching profile vs RSS feed, listing publications vs contributors, and uploading images. No overlap.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., create_post, get_profile, list_publications), making them predictable and easy to understand.

Tool Count5/5

7 tools is a well-scoped set for a Medium integration, covering posting, profile retrieval, RSS, publications, contributors, and image upload without being excessive.

Completeness5/5

The tool set covers the primary Medium API operations: creating posts (personal and publication), retrieving profile and RSS, listing publications and contributors, and uploading images. No obvious gaps given typical API limitations.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

qpost-mcp
io.github.arslan2012
MCP server for QPost — lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Social Media
1
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2

Related MCP Servers

plane-mcp-server
Project Management Developer Tools
goto-software
A
license
B
quality
D
maintenance
MCP server for Plane integration, enabling AI agents to interact with Plane APIs and services for project management tasks.
Updated 4 months ago (2026-05-05 17:44 UTC)
100
MIT
Paragraph MCPofficial
Content Management Systems Email
paragraph-xyz
A
license
Not graded
quality
A
maintenance
MCP server that connects AI agents to your Paragraph publication, enabling post management, subscriber analytics, and search across posts and publications.
Updated 5 days ago (2026-09-01 13:08 UTC)
65
1
MIT
writefreely-mcp-server
Content Management Systems Social Media
laxmena
A
license
A
quality
B
maintenance
An MCP server for WriteFreely that enables AI agents to publish and manage content on WriteFreely instances (including self-hosted instances and Write.as).
Updated 8 months ago (2026-01-16 01:40 UTC)
10
3
MIT
presskit-mcp
Content Management Systems Social Media
almoore
F
license
Not graded
quality
D
maintenance
An MCP server for publishing markdown articles to Medium and Substack via unofficial APIs, with tools to list, create, and manage posts and drafts.
Updated 5 months ago (2026-04-02 22:49 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/afikrim/medium-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

MCP Server Medium

Quick Start

Authentication

Tools

RSS Feed Shorthands

Development

Configuration

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Paragraph MCPofficial

Latest Blog Posts

MCP directory API