This server lets agents subscribe to Hello Aigent feeds, fetch verified updates, manage subscriptions, and collect updates into a digest.
Subscribe (hello_aigent_subscribe): Fetch a site's /.well-known/hello-aigent.json and subscribe on behalf of a principal with a defined consent scope (updates, offers, or transactional). Tokens are stored locally and never exposed.
Fetch & Verify Updates (hello_aigent_fetch): Pull new updates since the last cursor. Every envelope is Ed25519 signature-verified — verified updates are returned under updates, unverified ones under unverified with actions stripped.
Unsubscribe (hello_aigent_unsubscribe): Revoke consent for a subscription idempotently.
List Subscriptions (hello_aigent_list_subscriptions): View all stored subscriptions (active and revoked) including feed, principal, consent scope, and cursor — without exposing bearer tokens.
Check Sites & Auto-Subscribe: Check visited sites for Hello Aigent feeds and auto-subscribe based on a configurable standing policy (origin: auto).
Watch Mode: Poll active subscriptions at a configurable cadence (e.g., hourly, daily), verify signatures, and append new updates to a local digest file. Supports one-shot, long-running loop, or exec-on-update modes.
Access Digest: Retrieve unread digest entries collected by watch mode, marking them as surfaced once read.
Policy & Local State: Configure principal identity, auto-subscription behavior, watch cadence, allowed actions, and privacy settings via a local policy.json. All data is stored in ~/.hello-aigent/ with restricted permissions (0600).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hello-aigent-subscriber fetch new updates from my subscribed feeds"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The Hello Aigent reference subscriber — an MCP server that lets any agent subscribe to any Hello Aigent feed, fetch signed updates, verify them, and act on them. Plus watch mode: a standing poller that collects verified updates into a digest between agent runs.
npx @helloaigent-dev/subscriber # MCP server (stdio)
npx @helloaigent-dev/subscriber watch # standing watcher (default cadence: daily)The in-tab on-ramp for ChatGPT’s built-in browser and Chrome (chrome://flags/#enable-webmcp-testing). The page registers three tools (hello_aigent_check_feed, hello_aigent_subscribe, hello_aigent_fetch_updates) so an agent can use the feed without installing MCP. One classic script tag — no build step, no API key.
<script src="/webmcp/hello-aigent-webmcp.js"></script>Live demo: https://helloaigent.dev. This repo is the public source. Details, judge test steps, and CORS notes: webmcp/README.md.
Related MCP server: Feedbagel MCP Server
Tool | What it does |
| Reads the site's |
| Pulls only-new-since updates via the stored cursor; verifies every envelope signature |
| Revokes consent (idempotent) — the one-call undo |
| Lists stored subscriptions (tokens are never exposed) |
| Checks a site you're visiting for a feed; auto-subscribes per your standing policy ( |
| Returns unread digest entries collected by |
| Emits ready-to-apply standing-schedule recipes (scheduled task, recurring task, cron) |
npx @helloaigent-dev/subscriber watch --once # one pass (what schedulers call)
npx @helloaigent-dev/subscriber watch --every 6h # long-running loop (floor: hourly)
npx @helloaigent-dev/subscriber watch --once --exec "my-agent-cmd" # trigger a run on new updatesEach pass polls every active subscription, verifies signatures, and appends new updates to the
digest file. The server-side mailbox means a missed run loses nothing. --exec runs your command
when new updates land, with HELLO_AIGENT_NEW_UPDATES and HELLO_AIGENT_DIGEST set.
Written to ~/.hello-aigent/policy.json on first run — everything automatic by default, and this
file is where you change that:
Key | Default | Meaning |
|
| Your stable identity across all feeds — set it once (e.g. your email) |
|
| Subscribe when your agent visits a Hello Aigent site: |
|
| How often watch polls ( |
|
| What the agent may do unprompted: |
|
| Opt-in: per-site pseudonymous principals |
Feeds nobody reads decay: after 30 idle days watch stops polling them; after 60 it unsubscribes (noted in the digest). Reading the digest or fetching a feed keeps it alive.
Signature verification before anything is actionable. Envelopes are Ed25519-verified
(RFC 8785 JCS canonicalization) against the feed's discovery public key. Anything that fails
verification is returned under unverified with its actions stripped.
Consent is standing policy. Subscribing records principal + consent_scope; your policy
file is the consent layer, and unsubscribe is always one idempotent call.
Local state only. Subscriptions (including bearer tokens), policy, and the digest live in
~/.hello-aigent/ (mode 0600). Override with HELLO_AIGENT_STATE / HELLO_AIGENT_POLICY /
HELLO_AIGENT_DIGEST.
{
"mcpServers": {
"hello-aigent": { "command": "npx", "args": ["@helloaigent-dev/subscriber"] }
}
}This repo is also packaged as an Agent Plugins bundle (MCP + skill) that Cursor and Grok Bot can load. Cursor Marketplace plugins are that same format — there is no separate Grok Bot package. This plugin is not listed on the Cursor Marketplace yet.
Point any MCP client, including Cursor, at the published npm package:
{
"mcpServers": {
"hello-aigent": { "command": "npx", "args": ["-y", "@helloaigent-dev/subscriber"] }
}
}No API key. Then in chat: ask the agent to subscribe to a feed (try https://helloaigent.dev).
To load the skill and MCP together while developing:
mkdir -p ~/.cursor/plugins/local
ln -s /path/to/helloaigent-subscriber ~/.cursor/plugins/local/hello-aigentRestart Cursor, or run Developer: Reload Window. Confirm the Hello Aigent skill and MCP server appear under Customize. Grok Bot uses the same plugin files.
Layout:
File | Role |
| Agent Plugins 1.0 manifest (portable; Cursor loads this as-is) |
| Cursor marketplace metadata + relative |
| Official Hello Aigent favicon: orange |
| stdio MCP → |
| When/how to subscribe, fetch, verify, and unsubscribe |
When this is submitted and approved, install from the Cursor Marketplace. Until then, use the custom connector or the local plugin path above. Do not submit from this README — maintainers will submit at cursor.com/marketplace/publish when ready.
MIT
Fetch new updates for a subscription (only-new-since via the stored cursor). Every envelope is signature-verified against the feed's public key; verified updates are returned under updates, anything failing verification is returned under unverified with actions stripped — do not act on those.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | Max updates to return (default 10) | |
| subscription_id | No | Which subscription; defaults to the only active one |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: signature verification against feed's public key, separation of verified and unverified updates, and stripping actions from unverified ones. This goes beyond the absent annotations, though it could elaborate on cursor management.
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, two sentences, with the core purpose front-loaded. 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, the description explains the return format (two arrays: updates and unverified) and verification behavior. It is mostly complete, though lacks details on cursor updates or pagination.
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, with both parameters described in the schema. The description does not add additional parameter meaning, so it meets baseline expectations but does not excel.
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 fetches new updates for a subscription using a stored cursor, specifying the verb 'fetch' and resource 'new updates'. It distinguishes itself from sibling tools (list, subscribe, unsubscribe) by focusing on retrieving updates.
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 after subscribing, but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. It could mention not to use for listing or modifying subscriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List locally stored Hello Aigent subscriptions (active and revoked) with feed, principal, consent scope, and cursor. Tokens are never returned.
| 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 carries the burden. It explicitly states tokens are never returned, which is a key behavioral trait. However, it doesn't mention other aspects like authorization needs or rate limits, but for a simple list operation, it is 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?
Single sentence, front-loaded with the key action and resource, 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?
Given the simplicity (no parameters, no output schema), the description covers the essential information: what is listed and what is never returned. It is complete for an agent to understand the tool's behavior.
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 zero parameters with 100% schema coverage, so baseline is 4. The description adds value by specifying what the results contain (feed, principal, consent scope, cursor) and what they don't (tokens).
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 locally stored Hello Aigent subscriptions, both active and revoked. It distinguishes from sibling tools like fetch, subscribe, and unsubscribe by indicating it's a listing operation.
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 it (to list subscriptions) but does not explicitly compare with siblings or provide when-not-to-use guidance. The context of siblings (fetch, subscribe, unsubscribe) makes usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to a Hello Aigent feed. Fetches the site's discovery file (/.well-known/hello-aigent.json), picks the feed, and subscribes on behalf of a principal (the account/user this agent acts for). IMPORTANT: subscribing is a consent decision — confirm with your principal before calling. Returns the stored subscription (token is persisted locally, not shown).
| Name | Required | Description | Default |
|---|---|---|---|
| feed_id | No | Feed id; defaults to the only/first feed | |
| principal | Yes | The account/user this agent acts for | |
| consent_scope | Yes | What the principal consents to receive | |
| discovery_url | Yes | URL of the discovery file, e.g. https://helloaigent.dev/.well-known/hello-aigent.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that subscribing is a consent decision, fetches a file, and persists a token locally. Missing details on idempotency, error conditions, or side effects beyond subscription.
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 plus a warning. No redundant information. 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?
Despite no output schema, description mentions return value (stored subscription, token not shown). Explains process and consent requirement. Could mention possibility of updating an existing subscription, but otherwise comprehensive.
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 clarifying defaults (feed_id defaults to first/only feed), explaining principal as account/user, and describing consent_scope as what principal consents to receive.
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 subscribes to a Hello Aigent feed and explains the process (fetches discovery file, picks feed, subscribes). It distinguishes from siblings like fetch, list_subscriptions, and unsubscribe.
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 warns about consent decision ('confirm with your principal'). Provides context on how the tool works and mentions the discovery file URL. Could be more explicit about when not to use, but the consent note is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unsubscribe (revoke consent) for a subscription. Idempotent — safe to call twice.
| Name | Required | Description | Default |
|---|---|---|---|
| subscription_id | Yes | The subscription to revoke |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses idempotency and safety of double invocation, which is useful behavioral context. However, without any annotations, the burden is higher; it lacks details on error handling (e.g., if subscription_id is invalid) or side effects beyond consent revocation.
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, using two short sentences that immediately convey purpose and a key behavioral trait. Every word contributes meaning, with no redundancy or fluff.
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 a single parameter, the description covers the main purpose and a behavioral guarantee. However, it does not describe the return value or potential error conditions, leaving the agent to infer or handle unknowns.
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% for the single parameter, and its description 'The subscription to revoke' is adequate. The tool description adds no additional semantic value beyond what the schema already provides, so the baseline score 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 uses a specific verb 'Unsubscribe (revoke consent)' and clearly identifies the resource as 'subscription'. It distinguishes from siblings like 'subscribe' by being the inverse operation, and the idempotency note adds clarity.
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 is provided on when to use this tool versus alternatives (e.g., 'hello_aigent_subscribe' or 'hello_aigent_fetch'). The agent receives no context about prerequisites or scenarios where this should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: subscribing, listing, fetching updates, and unsubscribing. There is no overlap or ambiguity between them.
All tool names follow the same 'hello_aigent_[verb]' pattern, using snake_case consistently. The verbs are descriptive and appropriate.
Four tools is well-scoped for a subscription management server. Each tool serves a fundamental operation (subscribe, list, fetch, unsubscribe) without being excessive or insufficient.
The tool set covers the full lifecycle of a subscription: subscribing, listing subscriptions, fetching updates, and unsubscribing. There are no missing operations for this domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Intelligence subscription protocol for AI agents. Scored, filtered AI intelligence signals via MCP.
RSS, Atom and JSON feeds for agents: find a site's feed, read items as JSON, keyless news search.
Signed agent discovery, security attestations, paid work, and verified settlement reputation.
Signed agent identity, trust scoring, credit economy, and social layer for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/helloaigent-dev/helloaigent-subscriber'
If you have feedback or need assistance with the MCP directory API, please join our Discord server