Skip to main content
Glama

Generate AI prompt hypotheses

ai_tracking_suggestions_generate

Generate editable AI-tracking hypotheses from a reviewed preview. Require explicit paid consent and a stable retry UUID, then save only after separate acceptance.

Instructions

Generate editable hypotheses from the exact reviewed preview with explicit paid consent and a stable retry UUID. Generated prompts are hypotheses with no measured popularity and are saved only after separate acceptance.

Input Schema

NameRequiredDescriptionDefault
consentYesExplicit acceptance of model generation cost with no guaranteed maximum.
previewYesComplete frozen preview returned after explicit review.
project_idYesProject public ID; write membership and scope are enforced.
idempotency_keyYesStable UUID sent as Idempotency-Key; unchanged preview must be reused on retries.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.1

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that generation is paid with no guaranteed maximum, that the idempotency UUID must be stable across retries, that outputs are unvalidated hypotheses with no measured popularity, and that saving requires a separate acceptance step. These are exactly the mutation-side behaviors an agent needs and none are in the annotations.

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?

Two sentences, zero filler. The generation step and its constraints are front-loaded, and the acceptance caveat follows immediately.

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 a tool taking a deeply nested frozen preview contract with no output schema, the description adequately conveys consent, idempotency, and non-persistence. It could say more about what the call returns (hypothesis objects/IDs) and its cost/confirmation behavior, but the core invocation contract is covered.

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 description coverage is 100%, so the baseline is 3, but the description adds interpretive meaning: consent is explicitly 'paid consent', idempotency_key is the 'stable retry UUID', and preview is the 'exact reviewed preview' that must be reused on retries. project_id is not addressed in prose but is self-evident from schema.

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: generate editable hypotheses (prompts) from the reviewed preview. It signals its place in the preview → generate → accept chain, which differentiates it from siblings like ai_tracking_suggestions_preview and accept_ai_tracking_suggestions, though it never names those tools directly.

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?

Clear preconditions are given: it operates on the exact reviewed preview, requires explicit paid consent, and results are not persisted until separate acceptance. It stops short of explicitly naming the preview and accept sibling tools or stating when-not to call it.

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

Deploy Server

Other Tools