Skip to main content
Glama

Get Deal Health

get_deal_health
Read-onlyIdempotent

Health scores for the caller's OPEN deals: each scored 0-100 on how likely it is to be slipping (healthy >= 70 / watch / at_risk), worst first, with plain-language reasons — days since last logged contact, whether it is past its own expected close date, and how its age compares to the caller's average won-deal cycle. Includes per-band counts, an average score, and the reference cycle. Read-only and deterministic over the caller's own deals + activities; nothing is executed or sent. Pair with get_sales_recommendations to act on what is slipping. Requires authentication.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": false,
      -  "properties": {
      -    "text": {
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "text"
      -  ],
      -  "type": "object"
      -}New value: +null
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

The description reinforces the read-only and deterministic nature, adding details like 'nothing is executed or sent' and that it operates over the caller's own deals and activities. It also discloses the computation basis (days since last contact, close date, cycle comparison) and output components, going beyond the annotation hints.

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?

The description is relatively long but every sentence contributes meaningful information: scoring method, thresholds, reasons, output components, read-only nature, and usage pairing. The structure is logical, starting with the core purpose, then details, then usage guidance.

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?

With no output schema, the description fully explains what the tool returns: per-band counts, average score, reference cycle, and per-deal reasons. It also mentions authentication and scope. No critical information is missing for an agent to call it correctly.

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 tool has zero parameters, so the schema provides no parameter details. The description doesn't need to add parameter semantics. Per the baseline for 0 params, a score of 4 is appropriate, and the description clearly explains what the tool does without any parameter ambiguity.

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 precisely states the tool provides health scores for the caller's OPEN deals, with a clear scoring range and thresholds. It distinguishes itself from siblings like get_deal (single deal) and get_sales_recommendations (recommendations) by focusing on health assessment.

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 explicitly suggests pairing with get_sales_recommendations to act on slipping deals, providing a clear use case. It doesn't explicitly state when not to use it, but the description clearly frames it as a read-only health assessment tool, so an agent can infer appropriate contexts.

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.

Resources