Skip to main content
Glama
thenavidm
by thenavidm

List activity log entries

list_activity_log
Read-onlyIdempotent

Retrieve Calendly activity log entries for an organization, with filters for actor, action, namespace, time range, and pagination to audit events.

Instructions

List activity log entries. Reads Calendly data. Supports bounded opaque page_token retrieval. Required scopes: activity_log:read.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrder results by the specified field and direction. List of {field}:{direction} values.
actorNoReturn entries from the user(s) associated with the provided URIs
countNoThe number of rows to return
actionNoThe action(s) associated with the entries
accountNoNamed private Calendly account; selects credentials, not an organization URI.
all_pagesNoRead bounded opaque page_token pages; each request consumes quota. Not a snapshot or guaranteed complete backup.
max_itemsNoMaximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
namespaceNoThe categories of the entries
page_tokenNoThe token to pass to get the next portion of the collection
search_termNoFilters entries based on the search term. Supported operators: - `|` - to allow filtering by one term or another. Example: `this | that` - `+` - to allow filtering by one term and another. Example: `this + that` - `"` - to allow filtering by an exact search term. Example: `"email@website.com"` - `-` - to omit specific terms from results. Example: `Added -User` - `()` - to allow specifying precedence during a search. Example: `(this + that) OR (person + place)` - `*` - to allow prefix searching. Example `*@other-website.com`
organizationYesReturn activity log entries from the organization associated with this URI
max_occurred_atNoInclude entries that occurred prior to this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone.
min_occurred_atNoInclude entries that occurred after this time (sample time format: "2020-01-02T03:04:05.678Z"). This time should use the UTC timezone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds two genuinely useful behavioral facts: required scope 'activity_log:read' and that page_token retrieval is bounded. However, it omits pagination/quota behavior detail that the schema hints at (all_pages/max_items), leaving the disclosure incomplete for a 13-param list tool.

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

Conciseness4/5

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

Three short, front-loaded sentences with no filler. Efficient, though it is arguably too terse for a 13-parameter tool.

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

Completeness2/5

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

For a 13-param list tool with no output schema, the description is thin. It does not mention pagination cursor flow, date-range filtering, search_term capability, or the all_pages quota cost — all of which matter for correctly invoking this 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 description coverage is 100%, so the schema already documents all 13 parameters thoroughly (sort enums, search_term operators, date formats, all_pages semantics). The description adds almost nothing beyond restating the scope and bounded page_token, so baseline 3 is appropriate.

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?

States a specific verb+resource ('List activity log entries') that clearly identifies the operation. It does not distinguish itself from any sibling (none of the listed siblings are activity log tools), so it lands at 4 rather than 5.

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?

No when-to-use, when-not-to-use, or alternatives are mentioned. There is no routing guidance for an agent choosing among the many list_* tools.

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