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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It reveals return types (styled HTML and plain text), and a post-condition (check low_balance). It does not mention auth needs, rate limits, or side effects, but given the simple read-like nature (getting content), this is sufficient for a score of 4.
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 no wasted words. Front-loaded with the core action and usage frequency. Every sentence provides actionable 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?
For a tool with one parameter and no output schema, the description covers purpose, usage frequency, output format (HTML and text), and a critical post-call action. It does not explain session_token or list possible error states, but given the low complexity, this is quite 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 coverage is 0%, so the description must compensate for the undocumented session_token parameter. The description does not explicitly explain session_token, but since it's the sole required parameter and the tool is about fetching user-specific content, its purpose is reasonably inferred. The description adds value by explaining output format and balance check, earning a 4.
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 it gets today's content for all subscribed channels, using a specific verb-resource combination. It also distinguishes itself from siblings by noting it should be called once per day, whereas siblings like get_summary or list_channels likely serve different purposes.
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?
Clear usage guidance: 'Call this once per day.' It also provides actionable instructions on checking low_balance and directing the human to manage_url, making it explicit when and how to follow up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Tools are mostly distinct: try_sample shows a preview, start_subscription activates, create_setup_link offers an alternative path. However, get_bundle and get_template could be confused (both return HTML and mention {4bots}), and get_summary overlaps slightly with list_channels (pricing info appears in both).
Names consistently use verb_noun pattern (create_setup_link, start_subscription, list_channels, get_bundle). The only minor inconsistency is get_summary vs the more specific get_bundle/get_template/get_session—the verb 'get' remains uniform but 'summary' is vaguer than the others.
9 tools is appropriate for a subscription content service. There is one tool for each key action (preview, subscribe, fetch, manage account, vote, view info). The count feels well-scoped—not too few to cover the domain, not too many to overwhelm.
Core lifecycle is covered: try_sample (preview), start_subscription/create_setup_link (subscribe), get_bundle (daily delivery), get_session (account status), list_channels/vote (discover/select channels). Minor gaps include no unsubscribe/stop tool and no update_subscription to change channels, but the primary workflow is complete.