Skip to main content
Glama

devtune_get_timeline_events

Read-onlyIdempotent

Get project timeline events as context for interpreting Visibility trends. Sources are external, team, deterministic, or detected. Detected facts use citation_share_change and return stable aggregate evidence { platform, domain, direction, currentShare, baselineShare, absoluteChange, relativeChange, observationStart, observationEnd, projectCount, projectFraction } inside detectedEvidence; relativeChange is null when the domain has no baseline citations. Project detected evidence uses the same platform, domain, direction, shares and observation dates, plus { scope: "project", domainRole, brandName, incidentId, baselineStart, baselineEnd, cohortPromptCount, activePromptCount, status, resolvedAt }, without projectCount or projectFraction. domainRole is own, competitor or other; brandName is null for other. Project incidents must meet their detector configuration absolute-share floor, currently 0.01 (one percentage point). Shares are fractions. Status is active or resolved; resolvedAt is null while active. High-confidence active incidents and movement-ended history surface automatically, unless an overlapping pending or active citation exclusion hides them. External facts use platform_model_change, platform_outage, data_collection_gap, search_algorithm_update, or devtune_methodology_change with evidence { title, description, sourceUrl }. Prompt additions, edits (prompts_edited), switches off (prompts_paused) and on (prompts_resumed), removals, and restores return summary counts and an optional shared topic, never prompt names; edits and switches are one event per kind per day, counting each prompt once. Tracked-URL changes use kind tracked_urls_changed, one per day, with evidence { changeCount, brands, brandCount, requestedBy, requestedByCredential }: the number of tracked URL, brand or classification-rule changes that day and up to five affected brand names. requestedByCredential (the API key reference and name, or MCP connection reference, when every change has the same credential) identifies the shared credential. Tracking changes apply to citations collected from that day on; earlier citations keep the labels they were recorded with. Measured-action facts use source measured_action and kinds change_detected, change_claimed, measurement_opened and outcome_measured. Their measuredAction evidence includes actionId and actionTitle when attributed. Agent Picks events require agent_picks and include structured agentPicks rationale for localized titles, with reason and cells for repeated reasons. It also includes nullable interventionId and url, changeEventId for changes and results, measurementOpenedAt for openings and results, and windowClosedAt, result and method (v1 or v2) for results only; an Agent Picks result adds agentPicksMethod, v2 (decided by the 90% interval on the difference from its baseline) or v1 (by 95% ranges), so say which when comparing results. Results are improved, mixed, no_clear_change, declined, still_measuring or unmeasured; an outcome_measured event requires the canonical measured_at timestamp from Results. These facts ignore topic filters and have no platform keys. Detected AI Traffic changes use source detected, kind ai_traffic_change and evidence trafficChange: { incidentId, platform, classGroup, direction, observedEvents, baselineEvents, expectedEvents, relativeChange, observationStart, observationEnd, baselineStart, baselineEnd, status, resolvedAt }. platform is the AI Traffic provider key (for example openai or anthropic); classGroup is answer_fetches or crawls (training and index crawlers). observedEvents counts the observation window, baselineEvents the baseline window, and expectedEvents is the baseline scaled to the observation window length; relativeChange is null when the baseline has no events. They require the AI Traffic feature, ignore topic filters and have no platform keys. Only high-confidence changes measured with complete sensor coverage surface; a sensor outage is never reported as a drop. No causal link to metric movements is implied.

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": "devtune_get_timeline_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
windowDaysNoRolling window in days: 30 or 90. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedInput schema / properties / windowDays / anyOf
      Previous value: -[
      -  {
      -    "enum": [
      -      "30",
      -      "90"
      -    ],
      -    "type": "string"
      -  },
      -  {
      -    "enum": [
      -      30,
      -      90
      -    ],
      -    "type": "number"
      -  }
      -]New value: +[
      +  {
      +    "enum": [
      +      "30",
      +      "90"
      +    ],
      +    "type": "string"
      +  },
      +  {
      +    "anyOf": [
      +      {
      +        "const": 30,
      +        "type": "number"
      +      },
      +      {
      +        "const": 90,
      +        "type": "number"
      +      }
      +    ]
      +  }
      +]
  2. Added

TDQS

A3.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses substantial behavioral context: which facts ignore topic filters and lack platform keys, that AI Traffic changes require the AI Traffic feature, that only high-confidence complete-coverage changes surface, that sensor outages are never reported as drops, and that no causal link to metric movements is implied. These are meaningful operational caveats an agent could not infer from readOnly/idempotent hints.

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 description is a single enormous paragraph that mixes purpose, source taxonomy, evidence shapes for six or more event kinds, thresholds, and caveats with no headings or bullets. While some return-shape detail is necessary because there is no output schema, the wall-of-text format makes it hard to scan and front-loads almost nothing after the first sentence.

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?

Given the tool's complexity and the absence of an output schema, the description is unusually complete: it enumerates every source and event kind, the evidence fields, status semantics, and filtering behavior. It stops short of explaining ordering, pagination, or maximum event counts, which leaves a small gap for an agent planning the call.

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?

There is a single parameter, windowDays, whose schema description already covers the allowed values and default at 100% coverage. The prose never mentions windowDays or adds meaning such as how the window interacts with event observation dates, so it adds nothing beyond the schema. Baseline 3 applies for full schema coverage.

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 sentence states a specific verb and resource (get project timeline events) and its intended use as context for Visibility trends. It is clear what the tool returns, but it never differentiates itself from sibling event tools such as devtune_get_action_events or devtune_get_dex_events, which likely overlap in scope.

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

Usage Guidelines3/5

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

Usage is only implied by the phrase 'as context for interpreting Visibility trends.' There is no explicit guidance on when to call this versus the other event-listing siblings, and no exclusions or preconditions are stated for the tool as a whole (only per-source caveats buried later).

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