Skip to main content
Glama
Sign In

Chartbrew MCP

by com.chartbrew.api
OverviewDiscussionsAdmin

get_workspace_activity

Read-only

Read recent observations and metric evaluations across accessible dashboards, or one projectId. Use this for changes over time; use search_workspace to find items by name. Does not run datasets. Results include the effective date range and coverage/truncation information, with no pagination; narrow the range when needed.

Input Schema

NameRequiredDescriptionDefault
toNoInclusive ISO 8601 end timestamp; defaults to the current time.
fromNoInclusive ISO 8601 start timestamp. Defaults to seven days before to. Older starts are clamped to the configured lookback, at most 180 days; from >= to resets to the preceding seven days.
limitNoCap applied separately to observations and metric evaluations, not to the combined result. If omitted, uses 20 observations and 30 evaluations. No pagination.
projectIdNoOptional accessible dashboard ID from search_workspace. Omit to include all dashboards accessible to the caller.

Output Schema

NameRequiredDescriptionDefault
resultYesTool-specific result. Chart preview and filter write verification is returned in result.completion_check; completionRequirements is an input.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / from / description
      Added value: +"Inclusive ISO 8601 start timestamp. Defaults to seven days before to. Older starts are clamped to the configured lookback, at most 180 days; from >= to resets to the preceding seven days."
    • removedInput schema / properties / limit / default
      Removed value: -20
    • addedInput schema / properties / limit / description
      Added value: +"Cap applied separately to observations and metric evaluations, not to the combined result. If omitted, uses 20 observations and 30 evaluations. No pagination."
    • addedInput schema / properties / projectId / description
      Added value: +"Optional accessible dashboard ID from search_workspace. Omit to include all dashboards accessible to the caller."
    • addedInput schema / properties / to / description
      Added value: +"Inclusive ISO 8601 end timestamp; defaults to the current time."
    • addedOutput schema / properties / result / description
      Added value: +"Tool-specific result. Chart preview and filter write verification is returned in result.completion_check; completionRequirements is an input."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare a safe read operation, and the description adds real behavioral context: results carry the effective date range plus coverage/truncation information, there is no pagination, and narrowing the range is the remedy. It does not detail result shape beyond that, but the output schema covers this.

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?

The definition is compact and front-loads the core purpose before alternatives and behavioral notes. There is minor redundancy with the schema on 'no pagination', repeated in both the description and the limit parameter.

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?

With annotations, full schema coverage, and an output schema present, the description supplies everything else needed: scope, alternatives, exclusions, and result caveats. Nothing an agent needs to call it correctly is missing.

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 coverage is 100% and the parameter descriptions already explain defaults, clamping, the limit split across observations and evaluations, and projectId resolution. The description adds only the general guidance to narrow the range, not new per-parameter meaning, so the schema carries the load.

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 description states a specific verb and resource: reading recent observations and metric evaluations across accessible dashboards or a single projectId. It distinguishes itself from search_workspace and from dataset-running tools, so an agent can identify its role without opening the schema.

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?

It gives an explicit when-to-use ('Use this for changes over time'), names the alternative for a different need ('use search_workspace to find items by name'), and states an exclusion ('Does not run datasets'), which implicitly routes to run_dataset.

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

All Chartbrew MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources