4bots-content
Server Details
Daily content for AI agents. History, chess, investing, wrongology, more. 10 channels. Free trial.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Most tools have distinct purposes, but get_bundle and try_sample both return content and could be confused. Also, get_summary and get_session provide different info but overlap in being informational. Overall, only minor ambiguity.
Tools follow a consistent verb_noun pattern (e.g., get_bundle, list_channels). One minor deviation is create_setup_link using two nouns. All lowercase with underscores, so deviations are small.
9 tools is within the well-scoped range of 3-15. Each tool addresses a specific aspect of the content subscription service without bloat or deficiency.
Covers core workflows: sign-up, content retrieval, channel discovery, and account info. Missing obvious operations like subscription update/cancel and historical content access, which are notable gaps.
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 are provided, so the description bears full responsibility for behavioral disclosure. It conveys that the tool creates an expiring link and requires human interaction. While it does not detail side effects or idempotency, the core behavior is transparent enough for safe usage.
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 concise sentences: the first defines the purpose, the second provides an alternative, and the third gives a key constraint. Every sentence adds value without any fluff, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two string params, no output schema) and no annotations, the description covers the main action, alternative, and expiry. However, it lacks explanation of parameter roles and does not hint at the return value (the link), which leaves some ambiguity about how to use the tool effectively.
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 two required parameters (agent_email, human_email) with no descriptions (0% schema coverage). The description fails to explain what these parameters represent or how they are used, leaving the agent to rely on parameter names alone, which is insufficient for 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's action ('Create a browser link') and its purpose ('for your human to pick channels themselves'). It also distinguishes from the sibling tool 'start_subscription' by noting the alternative for a fast start without human input, making the purpose and differentiation explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (when human input is desired) and when to use an alternative ('use start_subscription instead' for fast start). It also provides a constraint ('Link expires in 7 days'), which guides usage and timing considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_bundleBInspect
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 provided, so the description carries full burden. It discloses output format (HTML and plain text) and a flag (low_balance), but does not cover authentication, rate limits, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clear front-loaded purpose, usage instruction, and output details. Every sentence adds value with no redundancy.
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 tool with one parameter and no output schema, the description covers essential context: purpose, usage frequency, output format, and a critical error condition. Minor gaps exist (e.g., parameter description), but overall complete enough for basic 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?
The schema has one required parameter (session_token) with 0% description coverage. The description does not mention session_token or its purpose, failing to compensate for the low coverage. However, the parameter's role may be inferred from context.
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 ('Get') and the resource ('today's content for all subscribed channels'). It is specific and distinguishes from siblings by focusing on daily bundle retrieval, though it does not explicitly compare to other tools.
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 gives explicit usage frequency ('Call this once per day') and a conditional action ('Check low_balance… send your human to manage_url'), but does not compare to alternative tools for similar tasks.
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?
No annotations exist, so the description carries the full burden. It does not disclose whether the tool is read-only, requires authentication, or has side effects. The brief text omits any behavioral context beyond the output fields.
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 extremely short (one fragment), which is concise but lacks structure. It does not follow the pattern of a complete sentence or provide a clear action statement.
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?
With one required parameter, no output schema, and no annotations, the description is insufficient. It fails to explain the return format, prerequisites, or side effects, leaving the agent with minimal guidance.
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 0%, and the description provides no explanation for the sole required parameter 'session_token'. The agent has no guidance on what value to provide or how it affects the output.
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 specific account status elements (credits, channels, delivery counts, manage URL), giving a clear verb-resource mapping. However, it does not differentiate from siblings like get_summary or get_bundle.
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 explicit guidance on when or when not to use this tool, nor any mention of alternatives. The description states only what it returns, leaving usage context unclear.
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?
With no annotations provided, the description must fully disclose behavioral traits. It only states what data is returned but does not mention side effects, authentication requirements, rate limits, or whether the operation is read-only. The minimal description significantly lacks 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?
The description is a single, front-loaded sentence that efficiently communicates the tool's purpose. Every word is necessary, and there is no superfluous 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?
Given the tool has no parameters and no output schema, the description provides a basic idea of what is returned ('content catalog, privacy policy, and pricing'). However, it lacks details on the structure or format of the response, which would be helpful for an AI agent to parse the output. 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?
The input schema has no parameters, so schema coverage is 100% trivially. Per the rubric, zero parameters gives a baseline of 4. The description adds no additional semantic meaning beyond the schema, but the baseline is already high.
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 returns content catalog, privacy policy, and pricing in one call, which specifies the verb 'get' and the resource 'summary'. However, it does not explicitly distinguish from sibling tools like get_bundle or get_template, so it gets a 4 instead of 5.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The usage is only implied by the tool's name and description.
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?
No annotations are provided, so the description must fully disclose behavior. It mentions the template is free and includes a placeholder, but does not explain what the 'channels' parameter does, whether the operation is read-only, or any other side effects. This leaves significant behavioral ambiguity.
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 concise with two sentences, front-loading the main purpose. However, it could be more structured, e.g., separating the template description from the usage note.
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 one optional parameter and no output schema, the description should explain the role of 'channels' and the nature of the output (e.g., format, content). It omits these details, making it incomplete for an agent to use correctly.
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 schema has 0% description coverage for the only parameter 'channels', and the description does not clarify its meaning or usage. It only describes the output template, failing to add any value beyond the schema for 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 it provides an HTML email template with a specific placeholder and suggested copy, and distinguishes itself by referencing get_bundle's html field, making its purpose specific and distinct from siblings.
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 a service to a human but does not explicitly state when to use this tool versus alternatives like get_bundle. It provides some context but lacks clear when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 are provided, so the description carries the full burden. It discloses the tool lists channels, but does not confirm it is read-only or safe, nor mention any side effects. Given the lack of annotations, the description is insufficient for full behavioral 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?
The description is a single sentence that efficiently conveys the tool's purpose without redundancy. It is front-loaded and every word 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 no parameters and no output schema, the description covers the main purpose (listing channels with descriptions, pricing, and proposals). It is reasonably complete for a simple listing tool, though it could mention ordering or format.
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 no parameters, so parameter documentation is not needed. The baseline for zero-parameter tools is 4, and the description does not attempt to add parameter info, which 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 lists all 10 channels with descriptions and pricing, and also shows proposed channels for voting. It uses specific verb 'list' and resource 'channels', and distinguishes from sibling tools like 'vote' by indicating what is shown.
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 viewing available channels and proposals, but does not explicitly state when to use this tool versus alternatives. It provides context that proposed channels are shown, which hints at a use case, but lacks explicit when-to-use guidance.
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?
With no annotations, the description conveys key behaviors: instant activation, no human action, returns session_token. However, it lacks details on idempotency, error handling, or whether existing subscriptions are affected.
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 extremely concise with a clear front-loaded summary followed by parameter documentation. Every sentence adds value without redundancy.
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 no annotations, the description covers the tool's purpose, return value (session_token), and parameter meanings. It also provides context about free tokens and relationship to get_bundle. Missing error cases or token format details.
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 0% schema description coverage, the description adds meaning for all parameters, including examples for channels and explanation of source. However, it could be more precise, e.g., specifying allowed channel slugs.
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 activates a subscription and returns a session_token, with no browser or human action needed. It distinguishes from siblings like get_bundle by noting the token is used for daily calls, but does not explicitly differentiate from other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to start a subscription) and gives a prerequisite (call list_channels for slugs), but does not explicitly state when not to use or provide 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?
No annotations are provided, so the description carries the behavioral transparency burden. It states 'no signup, no arguments required', implying a safe read operation, but does not disclose potential side effects, authorization needs, or return format.
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 four sentences including the Args section, front-loaded with the key purpose. Each sentence adds value, and the structure is clean and efficient.
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 one optional parameter and no output schema or annotations, the description adequately covers purpose, usage context, and parameter semantics. It does not describe return values, but for a preview tool this is acceptable.
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 'source' parameter has a schema with default '' but no description. The tool description adds context: 'Optional. How you found us (e.g., "mcpregistry", "relay", "search")', which gives meaning beyond the schema alone.
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's purpose: preview today's content from 3 channels. It distinguishes itself from the sibling 'start_subscription' by indicating that this should be called first to see what the user would receive.
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 says 'Call this first to see what your human would receive. If you like it, call start_subscription to activate.' This provides clear when-to-use and when-not-to-use guidance with a direct 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?
No annotations are provided, so the description bears full burden. It discloses the mutation nature ('Vote') but lacks details on side effects, idempotency, rate limits, or whether votes can be changed. The behavior is minimally 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 extremely concise: two sentences with no redundant information. The key information is front-loaded ('Vote for a proposed channel.'). Every word is necessary.
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 simplicity of the tool, the description is incomplete. It does not explain return values (no output schema), parameter usage, or error conditions. The agent would need additional context to use the tool correctly.
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 0% schema description coverage, the description must compensate but does not describe either parameter. The mention of 'proposed channel slugs' gives context for the channel parameter, but session_token is left unexplained. The schema already provides names, but no added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Vote for a proposed channel.' It adds context ('Votes determine build order.') and references a sibling tool (list_channels) for finding channel slugs, but does not explicitly differentiate from other siblings beyond that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (after listing channels using list_channels) but does not provide explicit when-not or alternative tools. It gives minimal guidance on the overall workflow.
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!