Skip to main content
Glama
bzdOS

hubd

by bzdOS
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Local

hub_whatsnew

Retrieve personalized journal activity since your last call, per agent, and surface top lint/audit findings for review.

Instructions

Personalized "what did I miss" — journal activity since YOUR OWN last hub_whatsnew call (tracked per agent name), not a fixed time window like hub_brief. Call this at the start of a session/sweep instead of re-reading hub_status/hub_brief from scratch; a never-seen agent gets a 24h window on its first call. Also carries review: the top few hub_lint + hub_audit findings, one per kind, each quoting the rule it enforces and the date that rule was written — read-only, files nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNoreturn everything, uncapped. By default long lists are trimmed to fit an agent context and what was left out is reported in `truncated`.
agentYesyour stable identity, e.g. "orchestrator" or your agent name — reused across calls to compute the delta
hoursNofallback window in hours if this agent has no prior checkpoint yet, default 24
reviewLimitNohow many finding KINDS to inline, default 3; 0 turns the review block off

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.12
    • addedInput schema / properties / reviewLimit
      Added value: +{
+  "description": "how many finding KINDS to inline, default 3; 0 turns the review block off",
+  "type": "integer"
+}
  2. Changed1 schema field changedv0.9.0
    • addedInput schema / properties / full
      Added value: +{
+  "description": "return everything, uncapped. By default long lists are trimmed to fit an agent context and what was left out is reported in `truncated`.",
+  "type": "boolean"
+}
  3. Addedv0.5.0

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it succeeds: it discloses that the tool is read-only, files nothing, tracks per-agent checkpoints, uses a fallback window on first call, and returns a review block with one finding per kind, each quoting the rule and date. This is unusually transparent for a tool description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every clause carries meaningful information: what it returns, how the window is determined, when to call it, and what the review block contains. It is somewhat run-on, with many embedded clauses, but it remains readable and front-loads the core purpose before the alternatives and details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, this description provides enough context for correct invocation: the delta model, first-call behavior, return contents, review block semantics, and read-only guarantee. The agent knows what to expect and how this tool differs from its siblings. No critical information appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that agent is a stable identity reused across calls to compute the delta, and that review findings are limited to one per kind. This goes beyond the schema's bare parameter descriptions without duplicating them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific function: returning journal activity since the caller's own last hub_whatsnew call, tracked per agent name. It explicitly differentiates itself from hub_brief (not a fixed time window) and positions itself relative to hub_status, so an agent can identify when this is the right tool. The verb is implicit but the resource and behavior are unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit usage guidance: call at the start of a session/sweep instead of re-reading hub_status or hub_brief from scratch. It also explains the first-call default (24h window), which prevents an agent from making wrong assumptions about deltas. This is strong contextual direction for when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools