This server provides access to Reletter's newsletter database, enabling AI agents to search, retrieve, and analyze email newsletters from platforms like Substack, LinkedIn, Ghost, Beehiiv, and Kit.
Search: Find publications by topic, title, or author with advanced filters (subscriber count, platform, language, activity status). Full-text search across newsletter issue bodies and titles, with highlighting and filtering by publication.
Autocomplete: Get suggested keywords and matching newsletters as you type.
Publication Details: Retrieve metadata including subscriber counts, engagement, social links, contributors, recent issues, chart rankings, and SEO reach.
Issues: List recent issues of a publication and fetch full issue content (body text, metadata).
Contacts: Obtain email addresses, contact pages, and social accounts for PR or sponsorship outreach.
Charts: Explore chart categories and get latest rankings for platforms like Substack, LinkedIn, and Kit.
Reference Data: List supported languages and view index statistics (total publications, issues).
Quota Monitoring: Check current API usage and remaining quota.
Give AI agents and LLMs access to newsletter data from Reletter. Search 7M+ email newsletters across Substack, LinkedIn, Ghost, Beehiiv, and Kit. Fetch metadata, contacts, issues, and chart rankings.
This is a remote Model Context Protocol (MCP) server that connects AI assistants like Claude, ChatGPT, and Cursor to the Reletter API.
Read and analyze newsletter issues — pull the full body text of any indexed issue into your AI workflow
Search and discover newsletters — find newsletters by topic, platform, or audience size
Find newsletters to pitch — get your product, tool, or book featured. Filter by audience size, topic, or platform, then pull verified contact emails in one pass
Build sponsorship, cross-promotion, and PR target lists — pull verified contacts and export them to your CRM
Monitor brand or keyword mentions — track when your brand, competitors, or clients are mentioned across newsletters
Track chart rankings — daily Substack / LinkedIn / Kit / Reletter chart data
Related MCP server: Online PR - Press Release Distribution
search_publications — Search for newsletters by topic, title, or author with filters
search_issues — Full-text search across newsletter issue bodies
autocomplete — Suggested keywords and matching newsletters for a partial query
get_publication — Full metadata for a newsletter (subscribers, engagement, social, rankings, SEO reach)
list_issues — Recent issues for a publication
get_issue — A single issue with body text
contacts — Email contacts, contact pages, social accounts for a newsletter
chart_categories — Available chart platforms and categories
chart_rankings — Latest chart rankings for a platform / category
list_languages — Reference list of languages
api_quota — Your API request quota and usage for the month
You need a Reletter API key. Get one here.
For autonomous agents that want to provision a key without a human in the loop, Reletter implements the Machine Payments Protocol. Hit POST https://api.reletter.com/api/payments/buy/ to get a 402 challenge, pay with a Stripe Shared Payment Token or with USDC on Tempo, and the response carries an API key tied to a freshly-provisioned account. Current bundle tiers: GET https://api.reletter.com/api/payments/bundles/. See https://reletter.com/llms-full.txt for the full flow.
Go to Settings → Apps → Advanced settings and enable Developer mode
Click Create app
Enter Name: Reletter
Enter MCP Server URL: https://mcp.reletter.com
Click Create and enter your Reletter API key when prompted
Go to Settings → Connectors
Click Add custom connector and enter name Reletter and MCP server URL https://mcp.reletter.com
Click Add and enter your Reletter API key when prompted
Add to your config file and restart Claude Desktop:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"reletter": {
"url": "https://mcp.reletter.com"
}
}
}Add to your project's .mcp.json:
{
"mcpServers": {
"reletter": {
"type": "http",
"url": "https://mcp.reletter.com"
}
}
}Go to Settings → MCP → Add new MCP server. Set type to URL and enter https://mcp.reletter.com.
If you want to fork or customize this MCP server for your own needs, here is how you can run or deploy it.
Node.js
A Cloudflare account (for deployment)
npm install
npm startThe server runs at http://localhost:8789. Test with the MCP Inspector:
npx @modelcontextprotocol/inspector@latestnpm run type-checkAfter changing wrangler.jsonc:
npm run cf-typegenCheck your API request quota and usage for the current month.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It clearly indicates a read-only operation ('Check') and scopes it to the current month, which is transparent enough for an agent.
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?
A single, concise sentence that front-loads the purpose. Every word is necessary and there is no extraneous information.
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 parameters and no output schema, the description adequately covers the tool's function. It could optionally mention return format, but it is functionally complete for this simple query.
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 tool has zero parameters, so schema description coverage is trivially 100%. The baseline of 3 applies as the description adds no additional parameter-level meaning nor is it needed.
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 'Check' and the specific resource 'API request quota and usage for the current month'. It effectively distinguishes from sibling tools which focus on searching, listing, or autocomplete actions.
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 states the tool's purpose: to check API quota and usage. While it doesn't specify when not to use it or mention alternatives, for a simple zero-parameter tool this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns suggested keywords and matching newsletters for a search query.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Search mode. | |
| query | Yes | Search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results are suggested keywords and matching newsletters, but does not mention read-only behavior, pagination, or any side effects. The description is insufficient for a complete understanding of tool behavior.
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?
Single sentence, no redundant information. Front-loads the action and output. Perfectly concise for the information provided.
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 and two parameters, the description provides the core purpose. However, it omits details like the number of suggestions, sorting, or whether it is safe to call repeatedly. For a simple autocomplete tool, it 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?
Input schema has 100% coverage, so parameters are documented. The description adds context that the tool returns suggestions, but does not explain how the 'mode' parameter influences results (e.g., suggests keywords vs titles). Schema descriptions are minimal ('Search mode.', 'Search query.'), and the tool description adds little extra 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?
Description clearly states the tool returns suggested keywords and matching newsletters for a search query. It identifies the verb, resource, and context. However, it does not explicitly differentiate from sibling search tools like search_publications or search_issues, which also deal with newsletters.
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?
No guidance on when to use this tool versus alternatives. Sibling tools include search_publications and list_issues, but the description does not explain that autocomplete is for suggestions while others are for full searches. Implies usage via 'for a search query' but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available chart platforms and categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with 'list', but does not explicitly confirm safety, required permissions, or any side effects. With no annotations provided, the description could do more to disclose behavior, but the implication is acceptable.
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, front-loaded sentence with no unnecessary words. Every word contributes to meaning.
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 parameters and no output schema, the description provides a minimal but clear purpose. It could mention the output format (e.g., a list of names) to be fully complete, but the tool's simplicity makes it adequate.
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?
There are no parameters, so the schema coverage is 100%. According to guidelines, 0 parameters gives a baseline of 4. The description does not need to elaborate on parameters since none exist.
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 action ('List') and the resource ('available chart platforms and categories'). It distinguishes from sibling tool 'chart_rankings' and is specific enough for an agent to understand what the tool returns.
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?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or situations where this tool is preferable. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest chart rankings for a platform / category. Use chart_categories to discover valid platform and category slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| variant | No | Optional variant: 'paid', 'free', 'rising', etc. | |
| category | Yes | Category slug (from chart_categories). | |
| platform | Yes | Chart platform slug (from chart_categories). |
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 does not disclose behavioral traits such as read-only nature, data range, pagination, error handling, or rate limits. Only states it returns 'latest chart rankings'.
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: first states purpose, second gives usage guidance. No redundant words, front-loaded essential information.
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 3 parameters (2 required), no output schema, and no annotations, the description explains what it returns ('Latest chart rankings') but lacks details on response format, pagination, or handling of invalid inputs. Reasonable but incomplete.
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 descriptions for all three parameters. The description adds that platform and category slugs come from chart_categories, but the schema already mentions 'from chart_categories'. No additional semantic value beyond reinforcement.
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 'Latest chart rankings for a platform / category', specifying the resource and action. It distinguishes from sibling tools like chart_categories by directing users to that tool for valid slugs.
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 advises using chart_categories to discover valid slugs, guiding when to use this tool in a workflow. Lacks explicit when-not-to-use or alternative tool comparisons, but the sibling context implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email contacts, contact pages, and social accounts for a newsletter. Includes contributors where Reletter has identified them.
| Name | Required | Description | Default |
|---|---|---|---|
| publication_id | Yes | The Reletter publication ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only mentions 'includes contributors where Reletter has identified them.' It does not disclose read-only nature, authentication needs, or any other behavioral traits.
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 concise sentences with no wasted words. Front-loaded with the key information about what is returned.
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 one parameter and no output schema, the description is adequate but lacks behavioral details and does not specify return format. It is minimally complete for a simple tool.
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 one parameter (publication_id) described as 'The Reletter publication ID.' The tool description does not add extra meaning beyond the schema, so baseline 3 is appropriate.
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 returns email contacts, contact pages, social accounts, and contributors for a newsletter. It specifies the verb (returns) and resource (contacts) and distinguishes from sibling tools like search and list, which are about publications and issues.
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?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it or provide exclusions. Siblings do not include a similar contact tool, so context is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full data for a single issue, including the body text and the publication it belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | The Reletter issue ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description reveals that the tool returns full issue data including body and publication. However, it does not disclose other behavioral aspects such as error conditions, rate limits, or authentication 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 sentence that is front-loaded with the main purpose and includes key details about what data is returned. No unnecessary 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?
For a simple get-tool with one parameter and no output schema, the description provides enough context about what data is returned. It could mention that it retrieves from Reletter, but the sibling context clarifies the domain.
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% for the single parameter issue_id. The description adds no additional meaning for the parameter beyond the schema's 'The Reletter issue ID.' The description focuses on output content rather than parameter semantics.
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 that the tool retrieves full data for a single issue, including body text and the publication it belongs to. This distinguishes it from siblings like list_issues (which returns multiple) and search_issues (which searches).
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?
No guidance is provided on when to use this tool versus alternatives like list_issues or search_issues. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up full metadata for a newsletter by its Reletter slug, e.g. 'doomberg'. Includes subscribers, engagement, social, contributors, recent issues, rankings, and SEO reach (Google search keywords and estimated traffic).
| Name | Required | Description | Default |
|---|---|---|---|
| publication_id | Yes | The Reletter publication ID, e.g. 'doomberg'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses extensive behavioral details about the returned data (subscribers, engagement, social, contributors, recent issues, rankings, SEO reach). However, it does not mention authentication requirements, rate limits, or any potential 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys all necessary information without excess. It could be slightly improved by breaking the list of included data into bullet points, but it remains concise and informative.
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 absence of an output schema, the description comprehensively lists the types of data returned. It lacks details on error handling or limitations, but for a simple retrieval tool with one parameter, it is largely complete.
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% for the single parameter. The description adds value by giving an example ('doomberg'), but the schema already provides a clear description. Baseline 3 is appropriate.
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 the specific verb 'Look up full metadata' and clearly identifies the resource as a 'newsletter by its Reletter slug'. It lists the data categories included, which distinguishes it from sibling tools like search_publications and get_issue.
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 when a slug is available and full metadata is needed, but it does not explicitly state when to use this tool versus alternatives such as search_publications. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Global Reletter index stats: total publications, issues, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says it returns stats without additional behavioral context such as whether it is read-only, performance considerations, or the exact nature of the returned data.
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 very concise but omits important details like what 'etc.' covers. It is front-loaded but lacks sufficient substance.
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 stats tool with no output schema, the description should enumerate the statistics provided (e.g., total publications, total issues, etc.). The vague 'etc.' leaves incompleteness.
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?
With zero parameters, the description has no need to elaborate on parameters. The schema is empty and fully covered.
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 states it provides 'Global Reletter index stats: total publications, issues, etc.' which clearly indicates aggregate statistics for the Reletter index. It distinguishes from sibling tools focused on individual records like search_publications or search_issues.
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?
No guidance on when to use this tool versus siblings. It does not explain that this is for high-level overviews while other tools are for detailed queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 100 most recent issues for a publication in reverse chronological order.
| Name | Required | Description | Default |
|---|---|---|---|
| publication_id | Yes | The Reletter publication ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description alone must disclose behavioral traits. It reveals the output is limited to 100 items and reverse chronological order, but omits authentication needs, rate limits, side effects, or return format details.
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, well-structured sentence that immediately conveys the core functionality. Every word is meaningful with zero redundant content.
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 simple list tool with one parameter and no output schema, the description is mostly complete. However, it weakly addresses usage context relative to sibling tools and does not mention potential pagination beyond the 100-item limit.
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 fully documents the one parameter (publication_id) with a clear description. The tool description adds no further semantic value beyond what the schema provides, so baseline of 3 is appropriate.
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 action (list), the resource (issues for a publication), the limit (100 most recent), and ordering (reverse chronological). It is specific and effectively distinguishes from siblings like search_issues and get_issue.
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 the tool is for listing recent issues but does not explicitly state when to use it versus alternatives like search_issues. No exclusions or context about when not to use it are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every language. Codes are used with the languages search filter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral info. It states 'List every language', implying a read-only operation. It doesn't disclose return format or potential limitations, but for a simple list, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear sentences with no unnecessary words. The first sentence directly states the action, and the second adds relevant context. It is optimally concise.
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 parameterless tool with no output schema, the description covers the core purpose and usage context. It could mention the output structure (e.g., list of language code/name pairs), but the current description is largely 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?
There are no parameters (schema coverage 100% vacuously). The description adds value by explaining that the codes from this list are used with the `languages` search filter, providing context beyond the empty 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?
The description explicitly states 'List every language', using a specific verb and resource. It distinguishes the tool from siblings by noting that codes are used with the 'languages' search filter, which none of the sibling tools mention.
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 clearly indicates when to use this tool (to list languages) and provides context on how codes are used with searches. While it does not explicitly state when not to use it, the tool's simplicity and uniqueness among siblings make this guidance sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across the body and titles of every newsletter issue Reletter has indexed. Returns highlighted snippets when highlight=true. Accepts the same filters parameter as search_publications; filters apply to the parent publication.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, starts at 1. | |
| query | No | Search query. Supports parentheses, quotes, AND, OR and -negation. | |
| filters | No | Same syntax and filter set as search_publications; filters apply to the parent publication, e.g. `subscribers:gte:5000,languages:any:en`. See https://reletter.com/developers/search-filters. | |
| per_page | No | Results per page, max 100. Default: 50. | |
| highlight | No | If true, the response includes a `highlight` field per issue with query matches wrapped in HTML <b> tags. | |
| threshold | No | Only return issues published within the last N seconds (max 1209600 = 14 days). | |
| publication_id | No | Scope results to a single publication by its Reletter ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions the highlight behavior and filter applicability, but does not disclose rate limits, authentication needs, or whether the operation is read-only. The tool is clearly a search (read), but not explicitly stated as non-destructive.
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: first states the purpose, second adds detail on highlights and filters. It is concise and front-loaded with the main action. However, it could be slightly more structured by separating filter details.
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 7 parameters, no output schema, and no annotations, the description partially explains the return value (highlights when enabled) but not the default response structure or pagination details. It provides enough for basic use but leaves gaps.
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 covers all 7 parameters with descriptions (100% coverage). The description adds meaningful context: filters apply to parent publication, same syntax as sibling, and the highlight parameter behavior. This goes beyond what the schema alone provides.
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 it searches across body and titles of newsletter issues, using the verb 'search' and resource 'issues'. It distinguishes from the sibling 'search_publications' by explicitly mentioning it applies to issues and referencing the sibling's filters.
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 indicates it accepts the same filters as search_publications, providing a cross-reference to a sibling tool. However, it does not explicitly state when to use this tool versus alternatives like list_issues or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for newsletters by topic, title, or author across Substack, LinkedIn, Ghost, Beehiiv and Kit. Returns subscriber numbers per publication. Specify either query or filters or both. Filters are comma-separated, e.g. subscribers:gte:5000,active:is:true,platforms:any:substack-beehiiv-kit. Full filter reference: https://reletter.com/developers/search-filters
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Search mode. Default: topics. | |
| page | No | Page number, starts at 1. | |
| query | No | Search query. Supports parentheses for grouping, quotes for exact match, AND, OR and -negation. | |
| filters | No | Advanced search filters, comma-separated, e.g. `subscribers:gte:5000,active:is:true,languages:any:en,platforms:any:substack-beehiiv-kit`. See https://reletter.com/developers/search-filters for the full list. | |
| per_page | No | Results per page, max 100. Default: 50. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Mentions search across multiple platforms and returns subscriber numbers, but lacks details on pagination, empty results, or rate limits. Minimal behavioral info beyond schema.
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 with no fluff. Purpose is front-loaded, and all details are relevant. Efficient and well-structured.
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 and moderate complexity, the description covers main operations, query/filter usage, and provides a reference link. However, it does not explain the meaning of 'mode' (default topics) or the structure of returned subscriber data, which are gaps.
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%, baseline 3. Description adds value by explaining the relationship between 'query' and 'filters' with examples and a link to full filter reference. This clarifies usage beyond schema descriptions.
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?
Clear verb 'Search' with specific resource 'newsletters' and scope including platforms (Substack, LinkedIn, Ghost, Beehiiv, Kit) and search dimensions (topic, title, author). Also mentions output (subscriber numbers). Differentiates from siblings like search_issues.
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 to specify either 'query' or 'filters' or both, providing clear usage guidance. Does not cover when not to use this tool or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0api_quotaautocompletechart_categorieschart_rankingscontactsget_issueget_publicationindex_statslist_issueslist_languagessearch_issuessearch_publicationsScored across 12 tools
Each tool has a clearly distinct purpose with no overlap. For example, search_publications finds newsletters, search_issues searches within issues, and get_publication retrieves detailed metadata. No two tools could be confused.
Most tool names follow a verb_noun pattern (search_publications, get_issue, list_issues). However, 'contacts' is a noun-only name, and chart_categories/chart_rankings are noun_noun. Overall, the naming is clear and mostly consistent.
With 12 tools, the server is well-scoped for its purpose of newsletter search and metadata retrieval. Each tool serves a distinct function without being excessive.
The tool set covers the full lifecycle of querying newsletters: search (autocomplete, search_publications, search_issues), retrieval (get_publication, get_issue, list_issues, contacts), analytics (chart_rankings, index_stats), and management (api_quota). No obvious gaps exist for a read-only API.
Research 3M+ podcasts with audience data, contacts, episodes, transcripts, charts, and sponsors.
Search and enrich B2B people & companies — 70+ filters (funding, linkedin, industry, country, ...).
Creator discovery & analytics across YouTube, Instagram, TikTok (30M+) + brand/sponsor intel.
Search 400k+ SaaS and software companies by category, technology, country, pricing, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/getreletter/reletter-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
