Skip to main content
Glama

Get TrueCoverage Event Metadata Keys

get-truecoverage-event-metadata-keys
Read-onlyIdempotent

List metadata keys for a given event title (ListEventMetadataKeysRequest). Pass eventTitle (CLI: --event-title or json-input).

Input Schema

NameRequiredDescriptionDefault
botIdNoQA bots: your botId from your stored TestChimp binding.
eventTitleYes
projectApiKeyNoQA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / botId
      Added value: +{
      +  "description": "QA bots: your botId from your stored TestChimp binding.",
      +  "maxLength": 64,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / projectApiKey
      Added value: +{
      +  "description": "QA bots: your own project API key from your stored TestChimp binding. Required on every call except get-bot-credentials, get-project-credentials and get-bot-compat. Never print it.",
      +  "maxLength": 256,
      +  "minLength": 8,
      +  "type": "string"
      +}
  2. First observed

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond restating the operation, and the parenthetical request-type name ('ListEventMetadataKeysRequest') conveys nothing an agent can act on.

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?

Two compact sentences with the core action front-loaded and no padding. The only waste is the '(ListEventMetadataKeysRequest)' type-name aside, which adds no agent-relevant information.

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?

For a read-only list tool with no output schema, the description is minimally sufficient — it tells the agent what to pass and what it returns at a high level. It omits any notion of what 'metadata keys' are, whether results are scoped by project, or how they relate to the event-detail tools.

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 67%; botId and projectApiKey are documented in the schema, while the required eventTitle has no schema description. The description compensates by naming eventTitle and its CLI form (--event-title or json-input), which is genuinely useful for the undocumented required parameter. Baseline 3 is appropriate given the mixed coverage.

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 and resource: 'List metadata keys for a given event title.' This is clearly distinguishable from the closest sibling, get-truecoverage-session-metadata-keys, by the event-vs-session scope. However, it never names an alternative, so the differentiation is implicit rather than explicit.

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 offers no when-to-use guidance, no prerequisites, and no mention of alternatives such as get-truecoverage-event-details or get-truecoverage-session-metadata-keys. It only explains how to supply the required parameter.

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.