Skip to main content
Glama
adrianba

edge-history-mcp

by adrianba

get_history_summary

Get an hourly summary of Edge browsing history by domain for a given day and profile. Aggregates visit counts per domain with sample page titles, without exposing full URLs.

Instructions

Summarize Edge browsing history for a profile on a day, by domain only.

Prefer this tool over ``get_history`` for questions like "what did I browse
today, hour by hour?": it returns far less data and never exposes full URLs,
which can embed auth tokens, session ids or other secrets. It does include a
small sample of page titles per domain for context. Only use ``get_history``
when specific URLs are genuinely required.

Only ``http``/``https`` visits are aggregated; ``file:``, ``edge:``,
``chrome:``, extension and other non-web URLs are skipped (and counted).

Args:
    profile: Profile friendly name (from ``list_profiles``) or directory id.
    date: Day to summarize, formatted ``YYYY-MM-DD``. Day boundaries are
        interpreted in the local machine timezone.
    start_time: Optional lower bound within the day, ``HH:MM`` (24-hour,
        local time). Defaults to the start of the day (``00:00``).
    end_time: Optional upper bound within the day, ``HH:MM`` (exclusive,
        local time). Defaults to the end of the day. Must be later than
        ``start_time``.
    group_by: Bucket granularity. Currently only ``"hour"`` is supported.
    limit: Maximum number of underlying visit rows to aggregate per page
        (default 10000, capped at 50000). Non-positive values fall back to
        the default.
    offset: Number of visit rows to skip from the start of the window, for
        paging through large days (default 0).
    include_titles: Include a small sample of page titles per domain
        (default true). Set false to get domains and counts only.
    max_titles_per_site: Maximum sample titles per domain per bucket
        (default 3, capped at 10). Values <= 0 return no titles.

Returns:
    A dict with:

    * ``profile``/``date``/``group_by``/``timezone``: the query context.
    * ``entries_considered``: visit rows examined in this page.
    * ``web_entries``: rows counted in the buckets.
    * ``non_web_entries_skipped``: rows skipped as non-web URLs.
    * ``buckets``: hour buckets ordered ascending, each with the local ISO
      ``hour``, a friendly ``label`` (e.g. ``8 AM``), ``total_web_visits``
      and ``sites`` (``domain`` + ``visits`` + ``sample_titles``, sorted by
      visits descending then domain ascending). Domains are normalized
      (``www.`` stripped); no full URLs, query strings or fragments are
      returned. ``sample_titles`` holds up to ``max_titles_per_site``
      deduplicated, truncated page titles in first-seen order.
    * ``offset``/``limit``/``has_more``/``next_offset``: paging metadata,
      with the same semantics as ``get_history``.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
limitNo
offsetNo
profileYes
end_timeNo
group_byNohour
start_timeNo
include_titlesNo
max_titles_per_siteNo
Behavior5/5

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

With no annotations provided, the description carries the full burden. It discloses critical behaviors: non-web URL filtering, domain normalization, title sampling limits, pagination semantics, and that full URLs are never exposed to protect secrets. This goes far beyond minimal disclosure.

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?

The description is long but well-structured with Args and Returns sections. It is front-loaded with a succinct summary, then detailed parameter and return info. Each sentence conveys necessary information without redundancy, appropriate for a complex tool.

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

Completeness5/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 the description fully explains the return value structure, including nested bucket fields, ordering, and paging metadata. It also covers edge cases like timezone interpretation and limits, making the tool complete and understandable.

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

Parameters5/5

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

The schema provides no descriptions (0% coverage), so the description must compensate. Every parameter is explained in detail: formats, defaults, constraints, and behaviors (e.g., end_time exclusive, limit caps, non-positive fallback). This fully covers parameter semantics.

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?

The first sentence clearly states the verb and resource: 'Summarize Edge browsing history for a profile on a day, by domain only.' It immediately distinguishes itself from get_history by explaining the aggregation level and security rationale, making its purpose unambiguous.

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

Usage Guidelines5/5

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

Explicit guidance is given: 'Prefer this tool over get_history for questions like...' and 'Only use get_history when specific URLs are genuinely required.' This directly addresses when to use this tool versus the sibling, satisfying the dimension completely.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adrianba/edge-browser-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server