Skip to main content
Glama
diklaaltman91-ux

ghl-gold

gold_ghl_pipeline_snapshot_report

Generate a Monday pipeline report of open and won values per stage for a sub-account to assess deal progress and prioritize follow-ups.

Instructions

One-call Monday report: pipelines with open/won value per stage across a sub-account. BYOK. PAID ONLY $39.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
location_idNo
Behavior4/5

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

With no annotations, the description discloses key operational behaviors: BYOK (caller's own key), PAID ONLY $39 (cost), and 'one-call' (single invocation). The word 'report' implies a read-only operation. It doesn't cover rate limits or exact output shape, but the main behavioral constraints are surfaced.

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?

Every phrase carries information: purpose, cadence, scope, auth, and cost. The primary purpose is front-loaded, and there is no filler.

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?

Adequate for a simple optional-parameter report, but with no annotations and no output schema it leaves gaps: the return content is only implied by the report name, and the effect of omitting location_id is not stated. Complexity is low, so this is a moderate rather than severe gap.

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?

The only parameter, location_id, has zero schema description coverage, but the description's 'across a sub-account' tells the agent that location_id selects the sub-account scope. This is a meaningful semantic addition beyond the bare schema.

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?

Description names a specific artifact: a Monday snapshot report of pipeline open/won value per stage within a sub-account. This clearly distinguishes it from sibling tools, which are mostly actions (enroll, list, draft, apply, move) rather than reporting.

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?

The phrase 'One-call Monday report' gives clear usage context: generate this report on Monday via a single call. It doesn't explicitly state when-not-to-use or name alternatives, but no sibling tool is a close alternative, so the missing exclusion is not a major gap.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/diklaaltman91-ux/17-ghl-gold'

If you have feedback or need assistance with the MCP directory API, please join our Discord server