Which integrations are available for this server?

Uses Zod validation schemas for input validation and type safety in API interactions

How do I use Amplemarket Knowledge Base MCP Server?

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., "@Amplemarket Knowledge Base MCP Server search for articles about email outreach best practices" 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.

Amplemarket Knowledge Base MCP Server

by artem-amplemarket

Overview Schema Related Servers Score Discussions

TypeScript

Remote

MCP Amplemarket Knowledge Base Server

A Model Context Protocol (MCP) server that provides seamless access to the Amplemarket Knowledge Base via Pylon's API. Designed specifically for Claude Desktop and other MCP-compatible clients.

Features

🔍 Smart Search: Search through Amplemarket articles by title and content
📄 Article Access: Retrieve full article content by ID or slug
📚 Complete Catalog: Get all available Amplemarket articles at once
🌐 Resource Support: Access articles via URI scheme
⚡ Fast Caching: Built-in 60-second cache to reduce API calls
🔒 Secure: Environment-based API token configuration
🎯 Focused: Hardcoded for Amplemarket knowledge base - no configuration needed

Setup

Install dependencies:
```
npm install
```
Configure your API key:
```
cp .env.example .env
```
Then edit the .env file and add your Pylon API token:
```
PYLON_API_TOKEN=your_actual_api_token_here
```
Important: Replace your_actual_api_token_here with your real Pylon API token. You can get this token from your Pylon dashboard.
Build the project:
```
npm run build
```
Test the server:
```
npm start
```

Configuration

Environment Variables

PYLON_API_TOKEN: Your Pylon API token (required)

Claude Desktop Integration

Add to your Claude Desktop mcp.json configuration:

{
  "mcpServers": {
    "pylon-kb": {
      "command": "node",
      "args": ["./dist/src/index.js"],
      "cwd": "/path/to/mcp-pylon-kb",
      "env": { 
        "PYLON_API_TOKEN": "your_actual_api_token_here"
      }
    }
  }
}

Note: Replace /path/to/mcp-pylon-kb with the actual path to this project directory, and your_actual_api_token_here with your real Pylon API token.

Tools

`kb.search`

Search for articles in the knowledge base.

Parameters:

query (string, required): Search query
limit (number, optional): Maximum results (1-100, default: 10)
collectionId (string, optional): Limit search to specific collection

`kb.getArticle`

Get a specific article by ID or slug.

Parameters:

id (string, optional): Article ID
slug (string, optional): Article slug

Note: Either id or slug must be provided.

`kb.getCollection`

Get collection metadata and articles.

Parameters:

id (string, required): Collection ID

Resources

The server supports the pylon-article:// URI scheme:

pylon-article://<article-id> - Get article by ID
pylon-article://<article-slug> - Get article by slug
pylon-article://help - Get resource usage help

API Client

The Pylon API client (src/pylon.ts) handles:

Authentication with Bearer token
HTTP requests via undici
HTML to text conversion
In-memory caching with TTL
Error handling

Development

# Install dependencies
npm install

# Build
npm run build

# Development mode (build + run)
npm run dev

# Run tests
npm test

Project Structure

mcp-pylon-kb/
├── package.json
├── tsconfig.json
├── .env.example
├── README.md
├── src/
│   ├── index.ts          # MCP server entry point
│   ├── pylon.ts          # Pylon API client
│   ├── schema.ts         # Zod validation schemas
│   └── tools/            # MCP tool implementations
│       ├── kbSearch.ts
│       ├── kbGetArticle.ts
│       └── kbGetCollection.ts
└── tests/
    ├── htmlToText.test.ts
    └── searchAdapter.test.ts

Security

API tokens are never logged or exposed in responses
All sensitive data is read from environment variables
Input validation with Zod schemas
Error messages don't leak sensitive information

License

MIT

Available Tools

3 tools

amplemarket_get_all_articlesA

PRIMARY TOOL: Get all articles from the Amplemarket knowledge base. Returns complete list of article titles, IDs, and metadata. Use this first to browse available articles, then use amplemarket_get_article to get full content of specific articles. No search needed - this shows everything available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does well by stating it 'Returns complete list of article titles, IDs, and metadata' and 'No search needed - this shows everything available', which clarifies scope and output. It doesn't mention rate limits, permissions, or pagination, but provides useful behavioral 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 front-loaded with the primary purpose, followed by usage guidance, all in three concise sentences with zero waste. Every sentence earns its place by adding 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?

Given 0 parameters, no annotations, and no output schema, the description is complete enough for a simple list tool: it states purpose, output format ('titles, IDs, and metadata'), and usage context. It could mention response format details, but it's largely adequate.

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 0 parameters with 100% schema description coverage, so the baseline is 4. The description adds no parameter information (as there are none), which is appropriate and doesn't detract from the high baseline.

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: 'Get all articles from the Amplemarket knowledge base' with specific verb ('Get') and resource ('articles'), and distinguishes it from its sibling 'amplemarket_get_article' by explaining this tool returns metadata while the sibling returns full content.

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

Usage Guidelines5/5

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

Explicit guidance is provided: 'Use this first to browse available articles, then use amplemarket_get_article to get full content of specific articles' and 'No search needed - this shows everything available', clearly indicating when to use this tool versus alternatives.

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

amplemarket_get_articleC

Get a specific article from the Amplemarket knowledge base by ID or slug

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	Article ID (provide either id or slug)
`slug`	No	Article slug (provide either id or slug)

TDQS

C2.9/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 the full burden of behavioral disclosure. It states the tool retrieves an article but lacks details on error handling (e.g., what happens if ID/slug is invalid), rate limits, authentication requirements, or response format. This leaves significant gaps for an agent to understand operational 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?

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly.

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?

Given no annotations and no output schema, the description is incomplete for a retrieval tool. It doesn't explain what data is returned (e.g., article content, metadata), error conditions, or dependencies. For a tool with 2 parameters and no structured behavioral hints, more context is needed to guide effective use.

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%, with clear descriptions for both parameters ('id' and 'slug') and their mutual exclusivity. The description adds minimal value beyond the schema by mentioning 'by ID or slug', but it doesn't provide additional context like format examples or usage tips. Baseline 3 is appropriate as the schema handles most documentation.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('a specific article from the Amplemarket knowledge base'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'amplemarket_get_all_articles' (which retrieves multiple articles) or 'kb_get_collection' (which may retrieve collections rather than individual articles).

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios where this tool is preferred over 'amplemarket_get_all_articles' for single articles or 'kb_get_collection' for different resource types, nor does it discuss prerequisites like authentication or availability.

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

kb_get_collectionC

Get collection metadata and articles from the Pylon knowledge base

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Collection ID

TDQS

C2.9/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 the full burden of behavioral disclosure. It states 'Get' which implies a read operation, but doesn't specify if it's safe, if it requires authentication, rate limits, or what happens on errors. For a tool with no annotations, this leaves significant behavioral gaps unaddressed.

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, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resources, making it easy to parse quickly.

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?

Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on behavioral traits, return values, or usage context, which are crucial for an agent to invoke this tool effectively in a broader workflow.

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 has 100% description coverage, with the single parameter 'id' documented as 'Collection ID'. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.

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

Purpose4/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 resources 'collection metadata and articles', making the purpose evident. It specifies the source 'Pylon knowledge base' which provides context. However, it doesn't differentiate from sibling tools like 'amplemarket_get_all_articles' or 'amplemarket_get_article', which appear to be related but from a different domain, so sibling differentiation is incomplete.

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, constraints, or scenarios where this tool is preferred over the sibling tools listed, leaving the agent with no usage context beyond the basic purpose.

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

Install Server

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

TDQS

B3.1/5.0

Disambiguation3/5

The first two tools have clear distinct purposes (get all articles vs. get a specific article), but the third tool 'kb_get_collection' introduces ambiguity. Its description mentions 'Pylon knowledge base' while the server name and other tools reference 'Amplemarket knowledge base', creating confusion about whether this is part of the same system or a different one. The overlapping 'get' functionality across all three tools could cause misselection.

Naming Consistency2/5

The naming is inconsistent with mixed conventions. The first two tools follow a 'amplemarket_verb_noun' pattern, while the third uses 'kb_verb_noun' with a different prefix. Additionally, 'get_all_articles' uses 'all' while 'get_collection' uses 'collection' for what might be similar concepts. The inconsistent prefixes and terminology create a lack of predictable pattern.

Tool Count3/5

With only 3 tools, this feels thin for a knowledge base server that presumably needs more operations like search, create, update, or delete. However, the tools do cover basic retrieval functionality. The count is borderline - adequate for minimal retrieval but insufficient for comprehensive knowledge base management.

Completeness2/5

The tool surface is severely incomplete for a knowledge base server. There are only retrieval operations (get all articles, get specific article, get collection) with no ability to search, create, update, or delete content. The third tool's description mentioning 'Pylon knowledge base' creates additional confusion about domain boundaries. This represents significant gaps that will cause agent failures when trying to perform basic knowledge base management tasks.

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

docs A
com.ntop
Search and query nTop's knowledge base and engineering guides from AI applications.
Search Documentation Access
32
The-Snip
com.the-snip
Team knowledge base for snippets, API calls and docs. Agents search and file items; humans review.
Knowledge & Memory Search Developer Tools
2
iknow
dev.iknow
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Knowledge & Memory Search Documentation Access
1
Knowledge Raven
com.knowledge-raven
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
RAG Systems Knowledge & Memory Search
2

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/artem-amplemarket/amplemarket-pylon-mcp'

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