Medium MCP Server

by yoyojyv

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.0
Disambiguation4/5
Most tools target distinct actions (login, domain management, reading, searching). The only potential confusion is between search_author_articles and list_author_articles, but descriptions clarify search (query within author) versus list (full article list). All others are clearly separated by resource and action.
Naming Consistency4/5
Tool names follow a consistent snake_case verb_noun pattern (e.g., search_articles, add_domain, remove_domain). The only deviation is 'login_status', which uses a noun phrase rather than a verb, but it is still readable and predictable. No mixed casing or chaotic naming.
Tool Count5/5
Eleven tools is well-scoped for a Medium server that handles authentication, article retrieval, author queries, and domain configuration. Each tool covers a distinct feature area without redundancy or bloat.
Completeness4/5
The server provides solid coverage for reading and searching Medium content, including member-only access via login. Missing writing/publishing and comment features, but these appear out of scope. The domain management tools are a bit niche but complete for their purpose.
Average 4.1/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It clearly indicates a read operation ('Read and extract content') and lists expected outputs (title, author, content, metadata), but does not disclose potential edge cases, authentication requirements, or error behavior. While not misleading, it lacks depth.
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 concise (one sentence) and front-loaded with the primary action. Every word contributes meaning, directly stating the tool's function and return value.
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?
For a simple read tool with one parameter and no output schema, the description adequately covers what the tool does and what it returns. It could be slightly more detailed about the exact metadata or error handling, but it is sufficient for the tool's complexity.
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?
The input schema already describes the single parameter (url) with 100% coverage. The description repeats 'Medium article URL' but adds no new semantic detail. Baseline score of 3 is appropriate since schema handles the meaning.
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's purpose: 'Read and extract content from a Medium article URL.' It specifies the action (read/extract) and the resource (Medium article URL), and distinguishes itself from sibling tools like search_articles or list_author_articles by focusing on a single URL's content.
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 when you have a specific Medium article URL to read, but does not explicitly state when to use this tool versus alternatives like search_articles or list_author_articles. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does add the useful detail that the domain 'will be saved to config file', indicating persistence. However, it omits other behavioral aspects such as authentication requirements, duplicate handling, or whether the operation overwrites existing config entries.
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 exactly two sentences, front-loaded with the primary action and followed by a relevant side-effect note. Every word contributes to understanding the tool, with no redundancy or fluff.
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?
For a simple one-parameter tool, the description covers the essential operation and persistent effect. It does not mention return values or error/duplicate behavior, but the low complexity and clear intent make it sufficiently complete for an agent to select and invoke the tool correctly.
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?
The input schema already fully describes the single parameter 'domain' with examples (e.g., stackademic.com). The description adds no extra parameter semantics, but with 100% schema coverage, the baseline of 3 is appropriate.
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 ('Add a custom Medium partner domain') and the target resource ('allowed list'), with a specific scope ('custom Medium partner domain'). This distinguishes it from sibling tools like 'remove_domain' and 'list_domains', making the purpose immediately obvious.
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?
The description provides clear context for using the tool: adding a domain to the allowed list. It does not explicitly mention when not to use it or name alternative tools, but the purpose is unambiguous and naturally separates it from removal/listing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The word 'check' suggests a read-only operation, but the description does not disclose whether it makes a network call, returns a boolean, or how it handles an unauthenticated state. This is minimal but not misleading.
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 with no redundant information. Every word contributes to the meaning, achieving maximum conciseness.
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 (zero parameters, no output schema, no nested objects), the description adequately covers the essential context. It might be enhanced by explicitly noting the return type, but it is not necessary for basic invocation.
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 tool has zero parameters, which receives a baseline score of 4 per the rubric. There is no need for parameter-level detail; the schema validation is trivially satisfied.
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 ('Check') and the specific resource ('login status'), distinguishing it from sibling tools like 'login' and 'logout' that perform mutations. It concisely identifies the tool's role as a status query.
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 context (checking authentication state) but does not explicitly state when to use this tool versus alternatives such as 'login' or 'logout'. The sibling list provides some context, but no direct exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses an important behavior ('Cannot remove default domains') beyond the schema. However, it does not explain what happens when attempting to remove a default domain or other side effects, leaving some behavioral 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?
Two short sentences, front-loaded with the verb and resource, and no redundant information. Every word adds value.
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?
For a simple one-parameter mutation tool, the description covers the core behavior and an important constraint. It could mention error handling or preconditions, but the simplicity of the tool makes this adequate.
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 covers the 'domain' parameter with a description, and coverage is 100%. The tool description adds context ('custom domain', 'allowed list') but no additional meaning about the parameter format or validation, so baseline 3 is appropriate.
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 'Remove a custom domain from the allowed list' – specific verb and resource. The additional constraint 'Cannot remove default domains' adds precision and distinguishes this from sibling tools like add_domain and list_domains.
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?
Provides clear context for when to use (removing custom domains) and an exclusion ('Cannot remove default domains'), but does not explicitly mention alternative tools. The context is clear enough for an AI agent to select this tool for removal tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not explain side effects, what happens if called prematurely, error behavior, or whether the session save is idempotent. This leaves an agent uncertain about the tool's full behavior.
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?
Two short sentences, front-loaded with the action, and no wasted words. It is appropriately sized for the tool's simplicity.
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?
For a simple zero-param, no-output tool, the description covers the essential action and a required precondition. It could mention return values or failure modes, but given the context, it is adequately 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?
The input schema has zero parameters, so the description needs no parameter detail. The zero-parameter baseline of 4 is appropriate, and no additional explanation is required.
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 uses a specific verb 'save' and clearly identifies the resource ('current login session'), and the explicit dependency on the 'login' tool distinguishes it from siblings like login and logout.
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?
It explicitly states a mandatory precondition ('Must be called after login tool'), giving clear temporal guidance. It does not discuss alternatives, but for a zero-parameter persistence step this is adequate contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It clearly states the effect (clearing the session) but doesn't mention irreversibility, side effects, or what happens if no session exists. It provides the main behavior but lacks additional context.
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 directly states the action. It is front-loaded and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no params, no annotations, no output schema), the description is complete enough for an agent to understand what the tool does and when to invoke it. The core behavior is clearly and sufficiently described.
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 tool has zero parameters, so the description naturally doesn't need to explain parameter meanings. The baseline for 0 params is 4, and the description adds no confusing or missing parameter information.
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 uses the specific verb 'clear' and identifies the resource as 'the saved Medium login session,' making the action unambiguous. It also distinguishes from sibling tools like login and save_login by explicitly addressing session termination.
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 the tool's purpose but doesn't explicitly state when to use it vs alternatives. It doesn't mention prerequisites such as being logged in or contrast with login_status, leaving the when-to-use guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the list includes default, custom, and environment domains, adding useful context beyond 'list domains'. However, it does not mention authentication requirements, return format, or whether the list is ordered or filtered by user.
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 is front-loaded with the action ('Show all allowed Medium domains') and includes parenthetical scope details. No wasted words.
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?
For a zero-parameter, no-output-schema tool, the description is complete enough for the agent to understand its basic purpose. It specifies the domain categories, making the tool distinct from any hidden variants. A bit more detail on return value or behavior when no domains exist would have made it fully 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?
This tool has zero parameters, so the description does not need to explain parameter meanings. The baseline of 4 applies as the description is not required to compensate for schema gaps.
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 the tool lists all allowed Medium domains, specifying the scope (default, custom, environment). This distinguishes it from sibling tools like add_domain and remove_domain which perform mutations.
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?
The description implies this is the read-only counterpart to add_domain/remove_domain, making the usage context clear. However, it does not explicitly state when to prefer this over other tools or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses that the tool opens a browser window and that session persistence requires a separate save_login call, which is useful. However, it does not explain what happens on successful login, how failures are handled, whether it checks for an existing session, or what the return value is. Given the lack of annotations, more behavioral detail is expected.
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 exactly two sentences: the first states the core action, the second provides a follow-up action in context. There is zero fluff, and the information is front-loaded. Every sentence earns its place.
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?
For a tool with no parameters, no output schema, and no annotations, the description covers the essential context: what it does, when to call it, and what to do next. It omits edge cases (e.g., already logged in, login failure), but given the simplicity of the tool, the description is nearly complete. Sibling tools like login_status may cover additional context.
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 schema defines zero parameters, so schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description correctly avoids adding unnecessary parameter details. There is nothing to explain about parameters, so a 4 is appropriate.
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 opens a browser window to log in to Medium, using a specific verb+resource construction. It distinguishes from sibling tools like save_login and logout by explicitly positioning login as the initial authentication step, and it mentions save_login as a follow-up, which helps disambiguate.
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?
The description provides clear workflow guidance: 'After logging in, use save_login...' indicates when to use login versus save_login. It also implies that login is a prerequisite for member-only content. It lacks explicit exclusions (e.g., 'do not use if already logged in'), but the mention of save_login and the login context gives sufficient direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals the web scraping mechanism and the risk of bot detection, which is valuable beyond the simple search action. It does not mention potential errors or response format, but the disclosed risk is a significant transparency credit.
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 two sentences, with the primary purpose in the first sentence and a critical caveat in the second. It is compact, front-loaded, and every sentence adds necessary information.
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?
The tool is relatively simple with two parameters and no output schema. The description covers the search scope and the scraping risk, but does not specify return format or failure behavior if bot detection triggers. This is a minor gap, so 4 reflects a mostly complete but not exhaustive description.
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?
The input schema fully describes both parameters (query and limit) with descriptions and constraints. The tool description adds no additional semantic information about the parameters, so the baseline score of 3 is appropriate.
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 searches for articles across all of Medium, using a specific verb and resource scope. This distinguishes it from the sibling search_author_articles, which implies an author-specific search.
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?
The broad scope ('across all of Medium') implicitly indicates when to use this tool, but no alternative tools are explicitly mentioned. The bot detection warning adds a cautionary usage note, though without explicit exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It discloses that the tool uses an RSS feed, is fast, and only accesses approximately 10 recent articles. This is valuable information about limitations and performance. It does not mention return format or error cases, but for a simple search tool this is adequate.
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 two concise sentences. The first states the primary purpose, and the second provides a key limitation. No filler or redundant information, making it optimally front-loaded and easy to parse.
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?
For a tool with 2 params and no output schema, the description covers the core behavior and a critical limitation (RSS feed scope). It could benefit from stating what the tool returns, but given the straightforward nature of a search (returning matching articles), the description is largely sufficient. The absence of output schema means some return info would be helpful, but it is not a critical gap.
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?
The input schema already provides full descriptions for both parameters ('Keyword to search for' and 'Medium username (without @ prefix)'), achieving 100% schema coverage. The tool description adds no additional parameter semantics beyond restating the purpose, so the baseline score of 3 is appropriate.
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's function: 'Search for articles within a specific author's posts.' It uses a specific verb (search) and resource (articles within an author's posts), which distinguishes it from sibling tools like search_articles (general search) and list_author_articles (listing without a keyword). The RSS feed limitation adds further specificity.
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?
The description provides clear context on when to use the tool: for searching within a specific author's posts. The mention of 'RSS feed (fast, limited to ~10 recent articles)' implicitly warns against using it for comprehensive or older article searches, though it does not explicitly name alternatives. This is more than implied usage, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing default behavior (RSS), approximate result count (~10 recent articles), full content availability, and potential bot detection with scraping. It could add more on return format or edge cases, but the disclosed traits are valuable.
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 two concise sentences, front-loaded with the primary action and followed by essential source-selection guidance. Every sentence earns its place without redundancy.
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?
For a tool with four parameters, no output schema, and no annotations, the description covers the core usage and behavioral trade-offs. It does not explicitly explain the keyword filtering or limit behavior, but the schema covers those details, so the description is adequately complete for typical use.
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?
Schema coverage is 100%, so the baseline is 3. The description adds meaning to the 'source' parameter by explaining its practical trade-offs (fast vs. slower, risk of bot detection) beyond the enum descriptions, and clarifies that the default RSS mode provides full article content.
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 it retrieves articles from a Medium author, with a specific verb ('Get a list') and resource ('articles from a Medium author'). It differentiates from sibling tools like search_author_articles and read_article by its listing scope and source options.
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?
The description provides clear context on choosing between RSS and scrape sources, including trade-offs in speed, article count, and bot detection risk. However, it does not explicitly mention when to use this tool over sibling alternatives like search_author_articles, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![medium-mcp-server MCP server](https://glama.ai/mcp/servers/yoyojyv/medium-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/yoyojyv/medium-mcp-server)

Score Badge

Copy to your README.md:

[![medium-mcp-server MCP server](https://glama.ai/mcp/servers/yoyojyv/medium-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/yoyojyv/medium-mcp-server)

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/yoyojyv/medium-mcp-server'

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