Skip to main content
Glama

Plutus

by com.plutus-cloud
OverviewDiscussionsAdmin

query_events

Read-onlyIdempotent

Query this account's business-event timeline (GitHub releases/PRs, PagerDuty incidents, Jira issues, GitLab, Salesforce onboarding/churn, Stripe subscription created/canceled, Vercel production deploys, Linear issue creation, Sentry newly reported errors) — the same events overlaid on the Cost/Event Explorer charts. Always scope with start_date/end_date: there is no pagination and results are capped at 5000 rows (oldest-first), so an unscoped query over a long history may be silently truncated. Carries no cost figure. Mirrors GET /api/events.

Input Schema

NameRequiredDescriptionDefault
qNoFree-text, case-insensitive substring match against the event title
categoryNoRestrict to event sources in these categories (cloud, ai, kubernetes, data, observability, developer-tools, finance, communications, saas, custom)
end_dateNoISO-8601 end of the date range (inclusive)
meta_repoNoRestrict to these GitHub repos (metadata.repo) — only narrows events that carry a repo; events with no repo (e.g. Salesforce onboarding/churn) are unaffected regardless of value
source_idNoRestrict to one event source, e.g. "github", "pagerduty", "jira"
event_typeNoRestrict to these event types, e.g. "issue_created", "deploy"
start_dateNoISO-8601 start of the date range (inclusive)
exclude_categoryNoLeave out event sources in these categories

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / category
      Added value: +{
+  "description": "Restrict to event sources in these categories (cloud, ai, kubernetes, data, observability, developer-tools, finance, communications, saas, custom)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / exclude_category
      Added value: +{
+  "description": "Leave out event sources in these categories",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds critical operational traits: no pagination, a 5000-row cap, oldest-first ordering, and silent truncation on unscoped long-range queries. It also clarifies that results carry no cost figure and that the tool mirrors GET /api/events.

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 description is front-loaded with purpose, then constraints and distinctions. The long source enumeration is useful for identification but makes the first sentence dense; the final API-mirror line is mildly extraneous for an agent. Overall it is efficient but not maximally tight.

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?

For an eight-parameter, no-output-schema query tool, the description covers purpose, scoping requirements, truncation risk, and cost-data exclusion well. It does not describe the returned event object shape, but the annotation and schema context make the definition largely complete for correct invocation.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all eight parameters in detail, including the meta_repo caveat. The description still adds useful meaning by making date scoping effectively mandatory and explaining the truncation consequence of unscoped start_date/end_date usage.

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?

States a specific verb and resource: query the account's business-event timeline. It enumerates concrete event sources (GitHub, PagerDuty, Jira, etc.) and explicitly distinguishes the tool from cost tools by saying it carries no cost figure. An agent can tell exactly what this tool returns and how it differs from query_costs/query_usage.

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

Usage Guidelines4/5

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

Gives clear operational guidance: always scope with start_date/end_date because there is no pagination and results are capped at 5000 oldest-first rows, with silent truncation risk. It does not name a sibling alternative for event-facet discovery, but the core when-to-use constraint is explicit.

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

All Plutus 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