Skip to main content
Glama

AsOf

Trends by quarter

trends
Read-onlyIdempotent

What the record's dated events say about how AI and tech companies ship and where their money goes, by quarter since 2023. Counted from checked claims only, by trend tags a model gives each claim from a fixed list, including whether the claim is about AI or the rest of tech (judged by the announcement, not the company). domain ai or tech keeps one side and adds each company's releases, updates and deals; omit it for both, each row carrying d. summary is the sentence the page leads with (the totals over the quarters returned and the busiest complete quarter), with a topic the topic's. Without topic: product updates per quarter and each theme's count (themes: agents, coding, voice_audio, image_video, reasoning, search, memory_personalization, connectors, enterprise_security, open_weights, health_science, finance_legal, education, commerce_ads, robotics_physical, safety_policy, compute_infra, pricing_access, devices, developer_platform, os_apps, media_entertainment), releases by kind, model releases by company (each company read with its products, as group: true reads it) and tier, deals by kind (funding_round, investment_out, grant_program, capital_commitment, acquisition, partnership, customer, expansion, valuation), the amounts disclosed per currency (as stated, never converted), the latest releases and deals, the largest amounts, who bought whom, countries, partners' kinds, and each source's coverage (sources start on different days: compare shares within a quarter rather than counts across quarters). model_releases lists every model release with its day, maker, tier and themes; with domain ai, cadence gives each company's median days between model releases (and between frontier ones), its latest release and how long ago, and the mix (small and fast, frontier, open weights) in the last two complete quarters against the two before. quarter (YYYY-Qn) without topic is the first quarter returned; the default is the last eight. Without topic each list of claims holds its first rows (limit, default 20, as far as a list fits the result; lists gives each list's total) and the per-company, per-quarter rows are left to /v1/trends. With topic (a theme, a deal kind, model, release for every release, update for every product update or deal for every deal): the checked claims behind it, newest first, in quarter, domain and company when given, as timeline rows with their tags. limit default 50, max 200; offset pages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "trends"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
topicNoA theme (voice_audio), a deal kind (funding_round, acquisition), model, release, update or deal; omit for the counts
domainNoai or tech; omit for both
offsetNo
companyNoWith topic: one company's claims, its records read together; a key from the counts' companies[].key (google, openai, anthropic...)
quarterNoYYYY-Qn, e.g. 2026-Q3

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, it discloses checked-claim provenance, model-assigned fixed-list tags, announcement-based AI classification, unconverted monetary amounts, source-start-date coverage bias, list truncation, and complete-quarter cadence comparisons. These details materially affect trust and interpretation and are consistent with the annotations.

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

Conciseness2/5

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

The purpose is front-loaded, but the remainder is a single extremely dense paragraph with long inline enumerations and many semicolon-chained clauses. Telegraphic phrases such as "with a topic the topic's," "each row carrying d," and "as group: true reads it" substantially impede scanning and comprehension.

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?

With no output schema, the description does substantial necessary work by inventorying aggregate and drill-down outputs, defaults, pagination, truncation, and interpretation caveats. It is not fully self-contained because terms and references such as "record," "d," "group: true," tiers, and /v1/trends remain unexplained, and some output-truncation wording is ambiguous.

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?

The description compensates well for 67% schema coverage by explaining topic's modes, domain's filtering and added company breakdowns, quarter's start-of-range behavior and eight-quarter default, and mode-specific limit and offset behavior. However, the mode-specific limit defaults of 20 for embedded lists versus 50 in the schema and topic mode, the terse "offset pages," and compressed company-grouping wording leave some details difficult to reconcile.

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

Purpose4/5

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

The opening identifies quarterly trends since 2023 in how AI and tech companies ship products and where their money goes, while later text distinguishes aggregate counts from topic-based claim drill-downs. The undefined phrase "the record" and lack of explicit differentiation from siblings such as timeline or search keep it from being fully precise.

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?

It gives concrete mode-selection rules: omit topic for quarterly counts, or supply a theme, deal kind, model, release, update, or deal to retrieve the underlying claims. It also explains filtering, pagination, and source-comparison caveats, but does not say when a sibling tool is preferable; the /v1/trends reference is not a clear agent-facing alternative.

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