Skip to main content
Glama

Inspect Revenue Opportunity

inspect_revenue_opportunity
Read-onlyIdempotent

Use this first when deciding whether a business has recoverable missed-call or follow-up revenue leakage. Returns a score, estimated monthly leak, recoverable revenue, and next action. Execution costs $0.005 via x402 Base USDC.

Input Schema

NameRequiredDescriptionDefault
zipCodeNoOptional postal code used as business-market context.
industryYesBusiness industry or service category, for example HVAC, roofing, plumbing, legal, or dental.
businessNameNoOptional business name used only to label the result.
interestLevelNoOptional buying/response urgency used to calibrate the recommended commercial action.
followUpMethodYesCurrent follow-up process for missed opportunities: none, manual human follow-up, email, or text/SMS.
averageJobValueNoAverage revenue in USD from one won job or customer opportunity.
missedCallsPerWeekYesEstimated inbound calls missed per week. Use 0 when none are missed.
estimatedRecoveryRateNoExpected fraction of leaked opportunities that can be recovered, from 0 to 1. Omit to use the model default.

Output Schema

NameRequiredDescriptionDefault
resultYesInspection result containing the leakage score, modeled monthly leak, recoverable revenue estimate, and recommended next action.
paymentYes
proofIdYesUnique KlearFlow proof identifier for this settled paid execution.
priceUsdYesUSDC-denominated execution price settled through x402.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / followUpMethod / description
      Added value: +"Current follow-up process for missed opportunities: none, manual human follow-up, email, or text/SMS."
    • addedInput schema / properties / interestLevel / description
      Added value: +"Optional buying/response urgency used to calibrate the recommended commercial action."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "payment": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "network": {
      +          "description": "Payment network identifier, currently Base mainnet eip155:8453.",
      +          "type": "string"
      +        },
      +        "payer": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Settled payer address when supplied by the payment facilitator."
      +        },
      +        "protocol": {
      +          "const": "x402",
      +          "type": "string"
      +        },
      +        "transaction": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Settlement transaction identifier when available."
      +        }
      +      },
      +      "required": [
      +        "protocol",
      +        "payer",
      +        "transaction",
      +        "network"
      +      ],
      +      "type": "object"
      +    },
      +    "priceUsd": {
      +      "description": "USDC-denominated execution price settled through x402.",
      +      "minimum": 0,
      +      "type": "number"
      +    },
      +    "proofId": {
      +      "description": "Unique KlearFlow proof identifier for this settled paid execution.",
      +      "type": "string"
      +    },
      +    "result": {
      +      "additionalProperties": true,
      +      "description": "Inspection result containing the leakage score, modeled monthly leak, recoverable revenue estimate, and recommended next action.",
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "proofId",
      +    "priceUsd",
      +    "payment",
      +    "result"
      +  ],
      +  "type": "object"
      +}
  2. Changed6 schema fields changed
    • addedInput schema / properties / averageJobValue / description
      Added value: +"Average revenue in USD from one won job or customer opportunity."
    • addedInput schema / properties / businessName / description
      Added value: +"Optional business name used only to label the result."
    • addedInput schema / properties / estimatedRecoveryRate / description
      Added value: +"Expected fraction of leaked opportunities that can be recovered, from 0 to 1. Omit to use the model default."
    • addedInput schema / properties / industry / description
      Added value: +"Business industry or service category, for example HVAC, roofing, plumbing, legal, or dental."
    • addedInput schema / properties / missedCallsPerWeek / description
      Added value: +"Estimated inbound calls missed per week. Use 0 when none are missed."
    • addedInput schema / properties / zipCode / description
      Added value: +"Optional postal code used as business-market context."
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds material context not in the annotations: the call costs $0.005 via x402 Base USDC, which an agent must know before invoking. It does not describe latency, failure modes, or whether the estimate is model-derived beyond the schema's 'model default' note.

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?

Three compact sentences, with the decision context front-loaded before the output list and the cost note last. Each sentence earns its place; the return-value sentence is partly redundant given the output schema but still aids selection.

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?

For a read-only scoring tool with a full output schema, 100% parameter coverage, and complete safety annotations, the only missing pieces an agent would need are usage timing and invocation cost — both are present. Nothing required to call it correctly is absent.

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

Parameters3/5

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

Schema description coverage is 100%, including enum explanations and defaults, so the schema carries all parameter meaning. The description adds nothing about parameter formats, units, or how inputs like interestLevel or estimatedRecoveryRate influence the output. Baseline 3 applies when structured fields do the heavy lifting.

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?

The description states a concrete diagnostic purpose (assessing recoverable missed-call / follow-up revenue leakage) and lists the concrete outputs (score, estimated monthly leak, recoverable revenue, next action). It never names the sibling recover_revenue explicitly, but 'use this first' implicitly positions it as the assessment step preceding recovery. Clear enough to select on, though not a textbook sibling differentiation.

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?

Explicit when-to-use: 'Use this first when deciding whether a business has recoverable missed-call or follow-up revenue leakage.' It also implies the boundary with recover_revenue by being the decision step. No explicit when-not clause or named alternative, so it falls short of 5.

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