Devto
Server Details
DEV.to MCP — wraps the DEV Community API (free, no auth for public reads)
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- pipeworx-io/mcp-devto
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.3/5.
The tools mix memory operations (remember, recall, forget) and DEV.to article operations (get_article, get_articles, search_articles) with Pipeworx-specific tools (ask_pipeworx, discover_tools). The memory and article tools are distinct, but ask_pipeworx and discover_tools overlap in purpose—both help find or execute tools, causing ambiguity.
Tool names use a mix of verb_noun (get_article, search_articles) and single verbs (forget, recall, remember), with some being one-word commands. The naming is readable but inconsistent in pattern, and ask_pipeworx/discover_tools break the pattern entirely.
Eight tools is a moderate count. However, the server seems to combine two unrelated domains (memory/storage and DEV.to article fetching) with a general query tool, making the scope feel fragmented rather than focused. The count itself is reasonable but the mix lowers appropriateness.
For the DEV.to article part, the tools cover get single, get list, and search, but lack create, update, or delete operations. Memory operations have basic CRUD (create, read, delete) but no update. The Pipeworx tools are a separate concern. Overall, the surface feels incomplete for each domain.
Available Tools
8 toolsask_pipeworxAInspect
Ask a question in plain English and get an answer from the best available data source. Pipeworx picks the right tool, fills the arguments, and returns the result. No need to browse tools or learn schemas — just describe what you need. Examples: "What is the US trade deficit with China?", "Look up adverse events for ozempic", "Get Apple's latest 10-K filing".
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Your question or request in natural language |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals that the tool picks the right tool and fills arguments, indicating autonomous multi-step behavior. No negative side effects mentioned, but the positive behavior is well described.
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?
Three sentences are concise and front-loaded. First sentence states core purpose, second explains mechanism, third provides examples. No fluff.
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's simple interface (one param, no output schema), the description is sufficiently complete. It covers input format, behavior, and use cases. Could mention output format or limitations, but not necessary for clarity.
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 coverage is 100% with only one parameter, so baseline is 3. The description adds meaning by explaining the parameter's role: it should be a natural language question/request, reinforced with examples. This exceeds baseline.
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 accepts plain English questions and returns answers by selecting the best data source. It differentiates itself from siblings (e.g., get_article, search_articles) by acting as a smart routing layer.
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 explicitly tells when to use: 'just describe what you need', and provides three diverse examples. It implies alternatives (browsing tools/learning schemas) are not needed, setting clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_toolsAInspect
Search the Pipeworx tool catalog by describing what you need. Returns the most relevant tools with names and descriptions. Call this FIRST when you have 500+ tools available and need to find the right ones for your task.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tools to return (default 20, max 50) | |
| query | Yes | Natural language description of what you want to do (e.g., "analyze housing market trends", "look up FDA drug approvals", "find trade data between countries") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It clearly states the tool returns 'most relevant tools with names and descriptions' and that it searches via 'natural language description'. However, it doesn't detail the ranking algorithm or potential limitations (e.g., handling of ambiguous queries), but overall provides solid behavioral insight.
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?
Two sentences, front-loaded with the core action. No wasted words. Every sentence adds value: first defines what it does, second gives usage guidance.
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 output schema, the description adequately explains what is returned ('most relevant tools with names and descriptions'). The tool has only 2 simple params, and the description covers usage context thoroughly. It's complete for the tool's purpose.
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 coverage is 100% (2 params fully described in schema). The description adds value by explaining that the query should be a 'natural language description' and gives examples, which enriches the schema meaning. The limit parameter is well described in schema; description doesn't add much but examples are helpful.
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 uses a specific verb ('Search') and resource ('Pipeworx tool catalog') and clearly distinguishes from siblings by stating 'Call this FIRST when you have 500+ tools available'. This sets it apart as the tool discovery entry point.
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?
Explicitly states when to use ('Call this FIRST when you have 500+ tools available'), and implies it's for finding tools before using others. No explicit 'when not to' but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
forgetAInspect
Delete a stored memory by key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key to delete |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'Delete' clearly indicates a destructive action. However, the description does not mention whether the deletion is permanent, requires confirmation, or any side effects. It is adequate but lacks details like 'This action cannot be undone' or permission requirements.
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, clear sentence that conveys the essential information with no wasted words. It is optimally concise and front-loaded with the action and resource.
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's low complexity (one parameter, no output schema), the description is nearly complete. It explains what the tool does and the required input. A minor improvement would be to note if the operation is irreversible, but overall it is sufficient.
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% (the 'key' parameter is described in the schema). The description does not add extra meaning beyond what the schema provides. Baseline 3 is appropriate since the schema already covers the parameter adequately.
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 uses a clear verb 'Delete' and resource 'stored memory by key'. It precisely describes the action and differentiates from sibling tools like 'remember' (store) and 'recall' (retrieve).
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: use this tool when you want to delete a memory by its key. However, it does not provide explicit guidance on when not to use it or alternatives. Given that sibling tools include 'remember' and 'recall', a brief note on when to use those instead would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_articleAInspect
Fetch full article content from DEV.to by ID (e.g., "12345"). Returns title, author, markdown body, tags, reactions, comments, and published date.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Numeric article ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It discloses the returned fields (title, author, body markdown, etc.) which adds value. However, it does not mention any side effects, authentication requirements, rate limits, or error conditions. For a read-only fetch, the transparency is adequate but not exceptional.
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 sentence that effectively communicates the purpose and key return fields. No unnecessary words, front-loaded with the action and resource.
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 1 parameter, no output schema, and no annotations, the description provides essential information about the return fields. It is complete enough for a simple fetch operation, though it could mention that the article must exist (e.g., 404 handling).
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 coverage is 100% and the only parameter 'id' is described as 'Numeric article ID'. The description adds value by confirming the ID is numeric and tying it to the article retrieval, but does not add new semantics beyond the schema. However, since the schema already clearly describes it, a 4 is justified for not needing more.
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 'Fetch' and the resource 'a single DEV.to article by its numeric ID'. It distinguishes from sibling tools like 'get_articles' which likely fetches multiple articles, and 'search_articles' which is search-based.
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 when to use (when you need full article details by ID) but does not explicitly state when not to use or mention alternatives like 'get_articles' or 'search_articles'. The presence of sibling tools suggests a context, but no 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_articlesBInspect
Get trending or recent DEV.to articles, optionally filtered by tag (e.g., "javascript", "react"). Returns title, author, reaction count, comments, reading time, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter articles by tag (e.g., "javascript", "python", "webdev") | |
| top | No | Return top articles from the last N days (e.g., 7 for last week) | |
| limit | No | Number of articles to return (default 10, max 30) |
Tool Definition Quality
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 indicates the tool fetches data (read operation) but does not disclose pagination behavior, default ordering, rate limits, or what happens with no parameters (likely returns recent). This leaves significant behavioral uncertainty.
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 two sentences, front-loaded with the core purpose, and each sentence adds value. No unnecessary words or repetition.
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?
The tool is simple with 3 optional parameters and no output schema. The description covers the basic purpose and one key parameter (top). However, without annotations or more detail on default behavior (e.g., default limit, sorting), the completeness is adequate but not thorough.
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?
The input schema already has 100% description coverage for all three parameters. The description adds context by mentioning the 'top' parameter specifically for trending over days, which reinforces its purpose. However, it does not add new meaning beyond what the schema already says.
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 fetches trending or recent articles from DEV.to, with optional tag filtering. It distinguishes itself from 'get_article' (singular) and 'search_articles' by focusing on trending/recent scope, though the distinction could be more explicit.
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 provides a specific use case: using the 'top' parameter to get articles trending over the last N days. However, it does not mention when to use this tool versus the sibling 'search_articles' or 'get_article', leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallAInspect
Retrieve a previously stored memory by key, or list all stored memories (omit key). Use this to retrieve context you saved earlier in the session or in previous sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Memory key to retrieve (omit to list all keys) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states the tool retrieves or lists memories, implying read-only behavior. However, does not disclose whether repeated recalls have side effects or if memory persists across sessions.
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?
Two clear, front-loaded sentences. No wasted words. Each sentence adds distinct value: first explains the two modes, second explains when to use.
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?
Simple tool with 1 optional parameter, no output schema. Description covers usage and parameter semantics adequately. Lacks details on return format or error cases, but acceptable given simplicity.
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 coverage is 100%, but description adds meaning: explains that omitting key lists all keys. This clarifies the parameter's optionality beyond the schema.
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?
Clearly states the verb 'retrieve' and resource 'memory by key', with an alternative action 'list all stored memories'. Distinguishes from siblings like 'remember' and 'forget' by focusing on retrieval.
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?
Explicitly says when to use: 'to retrieve context you saved earlier'. Implicitly excludes when not to use (e.g., for storing), but does not explicitly mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAInspect
Store a key-value pair in your session memory. Use this to save intermediate findings, user preferences, or context across tool calls. Authenticated users get persistent memory; anonymous sessions last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Memory key (e.g., "subject_property", "target_ticker", "user_preference") | |
| value | Yes | Value to store (any text — findings, addresses, preferences, notes) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses persistence behavior: authenticated users get persistent memory, anonymous sessions last 24 hours. No contradictions.
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?
Three sentences, front-loaded with core purpose, then usage context, then persistence details. No wasted words.
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 simple tool with only 2 string params and no output schema, description is sufficient. Explains what to store and persistence model. Lacks mention of max size or overwrite behavior, but these are minor.
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 coverage is 100%, but description adds context beyond schema: explains key is a string like 'subject_property' and value is any text. Provides usage examples.
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?
Description clearly states the tool stores a key-value pair in session memory, with specific examples of what to save (findings, preferences, context). Differentiates from sibling 'recall' (retrieves) and 'forget' (removes).
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?
Explicitly says to save intermediate findings, user preferences, or context across tool calls. Does not explicitly mention when not to use or alternatives, but the purpose is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_articlesAInspect
Search DEV.to articles by tag with pagination support. Returns title, author, tags, reactions, comments, reading time, and URL for each result.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Tag to filter by (e.g., "typescript", "rust", "ai") | |
| page | No | Page number for pagination (default 1) | |
| limit | No | Number of articles per page (default 10, max 30) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains pagination (page, limit) and return fields, but does not mention rate limits, authentication, or whether it returns only published articles. It is adequate but not comprehensive.
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?
Two sentences, no wasted words. First sentence states purpose and scope, second lists returned fields. Efficient and front-loaded.
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?
For a tool with 3 parameters and no output schema, the description covers the basics: what it returns and pagination. However, it lacks context on default tag (none implied), sort order, or whether results are paginated in a specific way (e.g., recent first). The description is sufficient but not rich.
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 coverage is 100%, so baseline is 3. The description adds no parameter-specific details beyond what the schema provides (tag, page, limit). It mentions 'filtered by tag' and 'pagination' which aligns with schema but does not add new semantic meaning.
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 browses DEV.to articles filtered by tag with pagination, listing returned fields (title, author, etc.). It uses a specific verb (Browse) and resource (DEV.to articles), distinguishing it from siblings like get_article (single article) and get_articles (likely no tag filter).
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 for browsing articles by tag with pagination, but does not explicitly state when to use this tool versus alternatives (e.g., get_article for a specific article, get_articles for all articles without tag filter). No when-not-to-use 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!