asha_digest
Clustered public news digest. format=markdown returns prose; otherwise JSON clusters.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | No | Default markdown. |
Clustered public news digest. format=markdown returns prose; otherwise JSON clusters.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | No | Default markdown. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it does very little. The description doesn't explain that 'clustered' implies grouped/related stories, whether the result set is deduplicated, how many clusters to expect, whether the digest is time-bucketed, or what the JSON response shape looks like. The format parameter is documented in the schema, so the description's only contribution is the word 'clustered,' which is not enough context for an agent to predict the tool's behavior.
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 with 12 words, making it extremely efficient. The format explanation is also concise and the parameters are simple with only two total. While one could argue the description is too sparse, for a simple read-only endpoint with two parameters, this level of conciseness is appropriate. The structure is front-loaded with the key identifier 'public news digest' followed by the format caveat.
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 only 2 optional parameters and no required fields, the description covers the essential behavior of retrieving a news digest and explaining the format switch. The sibling named asha_daily_brief suggests a potential alternative that an agent might confuse this with, and ideally the description would clarify how a 'digest' differs from a 'brief.' However, given the tool's simplicity and the lack of an output schema, the description is reasonably complete for an agent to invoke it 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?
Schema coverage is 50%: the format parameter has a description ('Default markdown') that clarifies its default value but not its semantics, while limit is undocumented beyond its type and range. The description's mention of format=markdown vs JSON maps directly to the format parameter. This is a borderline case: the description adds a little value by explaining the format parameter's output distinction (prose vs clusters), but the 'clustered' semantics of the JSON output remain unclear.
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 'Clustered public news digest' clearly identifies the tool's resource (news digest) and hints at its function (clustering), which places it at a basic level of clarity. However, 'digest' is used as a noun rather than a verb, so the tool's action is implicit rather than stated, and the description doesn't distinguish it from siblings like asha_daily_brief or asha_feed. The format parameter detail adds functional meaning but doesn't clarify the core purpose beyond what the name suggests.
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 guidance is provided for when to use this tool versus alternatives like asha_clusters_search or asha_feed. The description does not explain what 'clustered' means in practice, when a user would prefer this over the daily brief, or what kind of news items appear here that wouldn't appear elsewhere. The only usage signal is the format parameter description, which is insufficient for an agent to make an informed choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.