4bots
Server Details
Drop-in daily content for AI briefing agents. 10 channels, 100 free calls on signup.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- davidsiegel59/4bots
- 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 3.4/5 across 9 of 9 tools scored. Lowest: 2.4/5.
Each tool has a clearly distinct purpose. create_setup_link and start_subscription both initiate subscriptions but through different mechanisms (human link vs. direct), and their descriptions clearly differentiate them. No other tools overlap in functionality.
All tool names follow a verb_noun pattern in snake_case (e.g., get_bundle, list_channels). While there is variety in verbs (get_, create_, start_, try_, vote_), the naming is descriptive and consistent in style. minor deviation is the use of 'setup' in create_setup_link versus 'subscription' in start_subscription, but overall predictable.
With 9 tools, the set is well-scoped for a subscription content service. It covers sampling, subscribing, content retrieval, status checking, and voting on future channels without excess. Each tool serves a clear purpose.
The tool surface covers the primary user journey (sample, subscribe, get daily content, check status, vote) but lacks update or cancel functionality for subscriptions. There is no tool to modify channels or cancel directly, which are notable gaps for full lifecycle management.
Available Tools
9 toolscreate_setup_linkAInspect
Create a browser link for your human to pick channels themselves.
For a fast start without human input, use start_subscription instead.
Link expires in 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_email | Yes | ||
| human_email | Yes |
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 discloses link expiration (7 days), a key behavioral trait, but lacks details on authentication, idempotency, or other side effects. Still, for a simple creation tool, the transparency is good.
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 concise sentences with main purpose upfront, no redundancy. Every sentence adds value.
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?
While the description covers purpose and expiration, it fails to describe the parameters, which is a critical gap. The tool is simple, but missing param semantics reduces completeness.
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 0%, and description does not explain the two required parameters (agent_email, human_email). Without this, the agent cannot infer parameter usage or validation, severely hindering correct invocation.
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 creates a browser link for human channel selection, distinguishing it from start_subscription. The verb 'create' and resource 'setup link' are specific, and the distinction from sibling is 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?
Explicit guidance: use this tool when human input is needed, and use start_subscription for fast automated setup. Also provides expiration constraint (7 days), aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bundleAInspect
Get today's content for all subscribed channels. Call this once per day.
Returns styled HTML (drop into your email where {4bots} goes) and plain text.
Check low_balance — if true, send your human to manage_url to top up.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | Yes |
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 discloses return formats (styled HTML, plain text), the low_balance field, and the action to take if true. It does not explicitly state read-only or destructive nature, but 'get' implies read-only. Sufficient for a simple retrieval tool.
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 three sentences, front-loaded with the main purpose, and every sentence adds value. No redundant or extraneous text. 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?
For a tool with one parameter and no output schema, the description covers purpose, usage frequency, return format, and key field (low_balance). However, it omits explanation of the required session_token parameter, which is a gap. Overall adequate but not fully 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?
The input schema has one required parameter (session_token) with 0% description coverage. The description does not mention session_token or its purpose, leaving the agent to guess it is an authentication token. Given low coverage, the description should compensate but fails to do so.
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 retrieves today's content for subscribed channels, with specific mention of returning HTML and plain text. It distinguishes from sibling tools like 'get_summary' by focusing on daily bundled content, though not explicitly naming alternatives.
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 advises 'Call this once per day' and provides guidance on checking low_balance. However, it does not specify when to use this tool versus siblings like 'get_summary' or 'list_channels', 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.
get_sessionCInspect
Account status: credits, channels, delivery counts, manage URL.
| Name | Required | Description | Default |
|---|---|---|---|
| session_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only lists returned data, not idempotency, authentication needs, or side effects. Minimal transparency.
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?
Extremely short (one sentence), but lacks structure like clear sections or bullet points. Suffers from under-specification rather than being efficiently 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?
Given no output schema and poor parameter coverage, the description should be more complete. It lists some return values but is vague (e.g., 'manage URL') and insufficient for confident use.
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 0% with no parameter descriptions. The tool description does not mention session_token or its role, adding no value 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?
The description lists the items returned (credits, channels, delivery counts, manage URL) and the name 'get_session' implies retrieval. It is clear but lacks a strong verb specifying the action.
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 like get_bundle or get_summary. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summaryBInspect
Content catalog, privacy policy, and pricing in one call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says it retrieves data. Does not disclose side effects, authorization needs, rate limits, or confirm read-only behavior beyond the implied 'get'.
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, zero wasted words, front-loaded with key 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?
No output schema exists, and description does not explain return format or structure. Lacks details needed for complete understanding despite tool 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 has no parameters, and description adds no parameter info. With zero parameters, baseline is 4; description is adequate.
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 retrieves content catalog, privacy policy, and pricing in one call. It is specific but does not explicitly differentiate from sibling tools like get_bundle or get_template.
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. The description only states what it does, not when 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.
get_templateBInspect
Free HTML email template with {4bots} placeholder, plus suggested copy
to introduce the service to your human. Drop get_bundle's html field
where {4bots} appears.
| Name | Required | Description | Default |
|---|---|---|---|
| channels | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the tool provides a template but does not mention side effects, authentication requirements, rate limits, or whether the channels parameter affects the output. The behavior is only partially 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?
The description is short and front-loaded with the main purpose. However, the second sentence ('Drop get_bundle's html field where {4bots} appears') is somewhat cryptic and may require additional context for an agent to understand the workflow. Still, no extraneous 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 the absence of an output schema and annotations, the description should explain the output format and how the optional channels parameter affects the result. It fails to do so, leaving the agent with incomplete information to properly invoke the 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?
The input schema has one parameter (channels) with 0% schema description coverage, and the description does not explain channels at all. The agent receives no guidance on what channels means or how to use it, so the description adds no value 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?
The description clearly states the tool returns a free HTML email template with a placeholder ({4bots}) and suggested copy, and explains its relationship to the get_bundle tool. It distinguishes itself from sibling tools by specifying its unique output.
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 introducing the service using a template with a placeholder, and references get_bundle for filling that placeholder. However, it does not explicitly state when not to use this tool or list alternative tools for similar purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_channelsAInspect
All 10 channels with descriptions and pricing. Also shows proposed channels you can vote on.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It explains the tool returns a fixed set of 10 channels plus proposed channels, but does not disclose side effects, caching, authentication, or rate limits. Adequate for a simple read operation.
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, zero filler. Front-loaded with the main purpose. Every word earns its place.
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 zero-parameter list tool with no output schema, the description adequately conveys what is returned (channels, descriptions, pricing, votes). Missing details like response format, but sufficient for basic invocation.
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?
No parameters exist, and schema coverage is 100%, so baseline 3 applies. Description does not add parameter details because there are none.
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 tool lists all 10 channels with descriptions and pricing, and also shows proposed channels for voting. This is specific and distinguishes it from sibling tools like 'vote'.
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 like get_summary or try_sample. The description does not provide usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
start_subscriptionAInspect
Activate instantly. No browser, no human action needed.
Returns a session_token — store it for daily get_bundle calls.
100 free tokens on signup. Call list_channels for available slugs.
Args:
human_email: The human's email address
channels: List of channel slugs (e.g. ["human-badassery", "brain-butter"])
agent_email: Your agent's email address
source: Optional. How you found us (e.g. "mcpregistry", "relay", "search")
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| channels | Yes | ||
| agent_email | Yes | ||
| human_email | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden of behavioral disclosure. It mentions instant activation, no human action, and returns a session_token with 100 free tokens on signup. But it does not disclose potential side effects, limits, or error conditions.
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 highly concise: four short sentences plus parameter list. Key points are front-loaded (instant activation, no human action, token storage). No redundant or superfluous 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?
Considering no output schema and no annotations, the description covers the essential: instant activation, return of session_token, and prerequisite (list_channels). It lacks details on error responses or token format, but is sufficient for basic usage.
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 has 0% description coverage, so the description must add meaning. It provides brief comments for each parameter: human_email, channels (with example), agent_email, and source (optional). This is helpful but minimal; example values add clarity.
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 'Activate instantly' and mentions returning a session_token for daily get_bundle calls, indicating the tool starts a subscription. It references list_channels for available slugs but does not explicitly distinguish itself from sibling tools. The purpose is clear but lacks explicit differentiation.
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 notes that no browser or human action is needed, and suggests using list_channels to find available slugs. It also instructs to store the session_token for get_bundle calls. However, it does not specify when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
try_sampleAInspect
Preview today's content from 3 channels. No signup, no arguments required.
Call this first to see what your human would receive.
If you like it, call start_subscription to activate.
Args:
source: Optional. How you found us (e.g. "mcpregistry", "relay", "search")
| Name | Required | Description | Default |
|---|---|---|---|
| source | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses no signup needed, no arguments required. With no annotations, description takes on burden; it explains the preview nature but could mention any limitations (e.g., rate limits). Still, it's fairly transparent.
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?
Extremely concise: two lines of main description plus an 'Args:' section. Front-loaded with purpose and usage. 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?
For a simple preview tool with one optional parameter and no output schema, the description covers purpose, usage, and parameter meaning. Could specify return format but not necessary 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 0%, but description adds context: 'How you found us' with examples, significantly aiding the agent beyond the schema's bare type and default.
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 tool's action: preview today's content from 3 channels. Distinguishes itself from siblings by specifying it's a first step before start_subscription.
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 to call this first and then start_subscription if satisfied. Provides clear when-to-use and alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
voteBInspect
Vote for a proposed channel. Votes determine build order.
Use list_channels to see proposed channel slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | Yes | ||
| session_token | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states that votes determine build order, but omits critical details like whether voting is idempotent, if users can change their vote, authentication requirements, or error scenarios. The transparency is low.
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 long and directly addresses the tool's purpose and a key usage hint. It is front-loaded with the main action and avoids any unnecessary words. Every sentence adds value.
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 two required parameters, no output schema, and no annotations, the description is insufficient. It does not cover what happens on success, potential errors, or the nature of the session token. The context provided is minimal, leaving the agent with many unanswered questions.
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 0%, so the description must compensate. It indirectly explains 'channel' by referencing list_channels for slugs, but 'session_token' is completely unexplained. Only partial guidance is provided, leaving a significant gap in parameter understanding.
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 votes for a proposed channel and that votes determine build order. It provides a specific verb and resource, and distinguishes itself from sibling tools by mentioning list_channels as a related tool for viewing channel slugs. However, it could be more explicit about the exact action and its effect.
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 includes a usage hint: 'Use list_channels to see proposed channel slugs,' indicating a prerequisite. However, it does not specify when to use this tool versus alternatives, such as if multiple votes are allowed, or any conditions on voting. The guidance is present but limited.
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!