Skip to main content
Glama

devtune_get_timeline_events

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, removals, and restores return summary counts and an optional shared topic, never prompt names. Tracked-URL changes use kind tracked_urls_changed, one per day, with evidence { changeCount, brands, brandCount, requestedBy }: the number of tracked URL, brand or classification-rule changes that day and up to five affected brand names. 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 and result for results only. 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. No causal link to metric movements is implied.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.4/5.0
Behavior2/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. It does disclose some useful operational traits, like that agent picks facts ignore topic filters and that external facts have no platform keys, but it omits basic behaviors such as pagination, ordering, or authorization requirements. Much of the text is spent on output payload shapes that duplicate what the description never proves is an output schema, since none is declared.

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

Conciseness1/5

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

The description is an enormous wall of schema details with no front-loaded summary beyond one clause. Sentences run to 100+ words, and the payload field lists bury the single most actionable constraint (windowDays is not even mentioned).

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?

There is no output schema, so some return-shape explanation is warranted, but the description goes far beyond what is needed and still omits essential call behaviors like pagination and ordering. It is complete about payload fields but not complete about how to use the tool correctly.

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 description coverage is 100%, so the schema already fully documents the single windowDays parameter and its 30/90 enum. The description adds no additional parameter guidance, which matches the baseline 3 when the schema does the work.

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

Purpose3/5

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

The opening sentence says it retrieves project timeline events as context for Visibility trends, which is a specific verb+resource. However, the vast majority of the description dives into exhaustive payload schemas rather than clarifying the tool's scope, and it does not differentiate itself from sibling timeline-adjacent tools like devtune_get_action_events or devtune_get_dex_events.

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

Usage Guidelines2/5

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

The description frames usage loosely as 'context for interpreting Visibility trends' but gives no explicit when-to-use, when-not-to-use, or alternative tool routing. An agent looking at the ~80 siblings has no guidance on why it would pick this over get_action_events or get_visibility_summary.

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