Skip to main content
Glama

count_new_crypto_news

Free: how many new items arrived since a cursor (next_since) for given topics/tickers, so an agent only pays for /v1/news when there is something new.

Input Schema

NameRequiredDescriptionDefault
sinceYes
topicsNo
tickersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the key behavioral traits: the call is free, it exists to avoid a paid endpoint, and 'since' is a cursor of the next_since form. It omits auth requirements, rate limits, and error behavior, which keeps it below a 5.

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

Conciseness5/5

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

A single dense sentence with no waste; the cost rationale is front-loaded alongside the purpose so an agent can decide immediately.

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

Completeness3/5

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

No output schema and no annotations, so the description must cover everything. It hints that a next_since cursor comes back and that the result is a count, but leaves response shape, parameter formats, and failure modes underspecified for a 3-parameter tool.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate. It explains 'since' as a cursor (previously next_since) and identifies topics/tickers as filters, but gives no format guidance (comma-separated, repeated, casing) for any of the three parameters.

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 verb-and-resource: counts new items arriving since a cursor for given topics/tickers. It also implicitly distinguishes itself from the sibling latest_crypto_headlines by being the cheap pre-check rather than the content fetch.

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

Usage Guidelines4/5

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

Explicitly frames the use case: call this so an agent only pays for /v1/news when there is something new. That is a clear when-to-use signal, though it names /v1/news rather than the listed sibling latest_crypto_headlines, leaving the mapping to be inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources