Skip to main content
Glama

Helvabase — Governed response dossiers

helvabase_save_opportunity_profile

Idempotent

Save a bounded watch profile in this workspace. Requires an owner or administrator; marking it reviewed or needing changes also requires review scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
profileYes
idempotencyKeyYesUnique key for this logical mutation. Reuse exactly the same key and arguments after a timeout; never generate a new key to force a replay.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Adds meaningful context beyond the annotations: the permission model (owner/admin) and the elevated review scope needed for setting review status. The annotations already cover idempotency (idempotentHint=true) and non-destructiveness, so the remaining value is the auth/scope disclosure, which is a genuine behavioral detail most definitions omit.

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 compact sentences, front-loaded with what the tool does before the permission caveat. No filler, and the mutation intent is stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation built on a large nested profile object with no output schema and undocumented inner fields, the description is too thin. It never explains what 'bounded' means in practice, what the idempotencyKey contract is for replay, or the semantics of the profile subfields, so an agent must infer most of the payload.

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

Parameters2/5

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

Schema description coverage is only 50% (only idempotencyKey is documented), and the nested profile object has ~15 fields with zero descriptions. The description's only nod to parameter meaning is 'marking it reviewed or needing changes', hinting at reviewStatus; it explains nothing about cantons, cpvCodes, dailyCandidateLimit, or the 'bounded' maxItems limits.

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 (save) and resource (watch profile) scoped to the current workspace, so an agent can tell it mutates a profile rather than reading one. However, it does not explicitly differentiate from the sibling helvabase_opportunity_profiles, and the term 'watch profile' diverges slightly from the tool's 'opportunity profile' naming.

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

Usage Guidelines3/5

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

Provides real preconditions: requires owner or administrator, and review scope for marking reviewed/needs_changes. It gives no guidance on when to use this versus the sibling read/list tools such as helvabase_opportunity_profiles, so usage is implied rather than routed.

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.