Skip to main content
Glama
Sign In

Promvia

by app.promvia
OverviewDiscussionsAdmin

Add a tracked prompt

add_prompt
DestructiveIdempotent

Track a new prompt on a site. Returns the tracked prompt's queryId and stored text (the id archive_prompt and generate_brief take); a prompt that is already tracked returns that prompt's queryId with alreadyTracked: true, and no second row. Subject to the plan's account-wide tracked-prompt quota — refusals name the reason. When this month's room for automatic checks is used, the prompt is still tracked and automaticChecksFrom says the day its automatic checks start (it can be checked on demand before then). A reworded question is a different measurement, so a prompt is never edited: with replacesQueryId (a tracked prompt's queryId on the same site) the new prompt REPLACES it — in one transaction the new one is tracked under the same quota rules and the old one is archived (its history stays) and linked, and the result carries replacesQueryId. Replacing frees the old prompt's quota slot in the same transaction, so it is accepted at a full quota; but the old prompt keeps its active slot for the rest of the period, so at a full active pool the replacement's automatic checks start next period and the result's automaticChecksFrom says so (it can be checked on demand before then). A replacement is refused, changing nothing, with unknown-query (not a tracked prompt of this site), same-question (the new text is the old prompt's), already-tracked (the new text is already tracked; its queryId is returned) or a quota reason.

Input Schema

NameRequiredDescriptionDefault
queryYesThe prompt to track (≤300 chars).
siteIdNoOptional on a connected app: the site chosen with select_site is used. If given, it must be that site. With an API key it is required: a site id from list_sites.
replacesQueryIdNoOptional: the queryId of the tracked prompt this one replaces (it is archived, its history kept).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations, it details return values (queryId, text, alreadyTracked, automaticChecksFrom), quota behavior, replacement transaction semantics, and specific refusal reasons. This is rich behavioral disclosure that an agent could not infer from the annotations alone.

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

Conciseness3/5

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

The first sentence is front-loaded and clear, but the description becomes a dense, run-on block with multiple parentheticals and repeated quota explanations. It is informative but lacks structure, and some details about automatic check scheduling could be tightened.

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?

Given three parameters, no output schema, and the presence of annotations, the description is complete: it covers return values, replacement side effects, quota refusals, and edge cases like alreadyTracked. Nothing an agent needs to invoke the tool correctly is missing.

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 defines all three parameters. The description adds meaning for replacesQueryId by explaining the transactional replacement, quota slot behavior, and refusal conditions, which goes beyond the schema's simple 'archived, history kept' note.

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 opens with a specific verb and resource: 'Track a new prompt on a site.' It distinguishes itself from archive_prompt and generate_brief by naming them as consumers of the returned queryId, and it clarifies that a prompt is never edited but replaced. This is a clear, sibling-aware purpose.

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?

It gives strong context: use replacesQueryId to replace instead of edit, and already-tracked prompts return alreadyTracked rather than creating a second row. It does not explicitly route the agent away from list_prompts or other siblings for discovery, but the when-not and alternative conditions are clearly stated.

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

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