Skip to main content
Glama
bzdOS

hubd

by bzdOS
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

hub_whatsnew

Get journal activity since your last call per agent to see what you missed, plus top lint and 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
sinceNo"checkpoint" (default: since your own last call — right after a night away, empty right after a context compaction), "session" (since this session began: everything it wrote itself included — use this after a compaction), or an ISO time
projectNoonly entries of this project — a slug, or several comma-separated; the checkpoint still moves
reviewLimitNohow many finding KINDS to inline, default 3; 0 turns the review block off

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.15
    • addedInput schema / properties / project
      Added value: +{
+  "description": "only entries of this project — a slug, or several comma-separated; the checkpoint still moves",
+  "type": "string"
+}
    • addedInput schema / properties / since
      Added value: +{
+  "description": "\"checkpoint\" (default: since your own last call — right after a night away, empty right after a context compaction), \"session\" (since this session began: everything it wrote itself included — use this after a compaction), or an ISO time",
+  "type": "string"
+}
  2. 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"
+}
  3. 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"
+}
  4. Addedv0.5.0

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden, and it does substantial work: read-only / files nothing, per-agent-name checkpoint tracking, default trimming with a `truncated` report, and the review block contents. It does not mention permissions or rate limits, but for a pure-read tool this is close to fully disclosing its behavior.

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?

Dense but front-loaded: the identity/mode of the tool comes first, then the differentiation from siblings, then the review payload. A few clauses are packed with parentheticals that make a single paragraph slightly heavy to parse, but no sentence is wasted.

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

Completeness4/5

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

There is no output schema, so the description must convey the return shape, and it does: journal activity plus a `review` block of top hub_lint/hub_audit findings, one per kind, each quoting its rule and date, with truncation reported. The only gap is that the shape of the journal entries themselves is not described.

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 coverage is 100% so the baseline is 3, but the description adds genuine meaning beyond the schema for the critical `since` parameter (checkpoint vs session vs ISO, and when each applies) and explains the interaction between checkpoint movement and `project`/`hours`. This is more than restating the schema, though not every parameter gets extra context.

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?

States a specific and unusual verb+resource ('personalized what did I miss — journal activity since your own last call') and explicitly distinguishes it from hub_brief ('not a fixed time window like hub_brief') and hub_status. An agent can tell exactly what this returns and how it differs from its closest siblings.

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?

Gives explicit when-to-use guidance ('call this at the start of a session/sweep instead of re-reading hub_status/hub_brief from scratch') and names the alternative it replaces. It also covers the edge case of a first-time agent (24h window) and which `since` mode to use after a context compaction.

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

Deploy Server

Other Tools