Skip to main content
Glama
Sign In
hubspot-pipeline-mcp

hubspot-pipeline-mcp

by RynoJor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Rep conversion

rep_conversion
Read-onlyIdempotent

Calculate stage-to-won conversion by sales rep versus team average, flag underperforming owners, and estimate USD at risk from their closed deals.

Instructions

Stage-to-won rate by owner: of each owner's closed deals that entered from_stage, the share won, against the rest of the team. Flags owners at z <= -3 and estimates usd_at_risk as closed deals x (team rate - rep rate) x average won amount.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "rep_conversion"
  }
}

Input Schema

NameRequiredDescriptionDefault
from_stageNoStage to measure from, e.g. 'Proposal' or 'Demo'.Proposal

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish this as a read-only, idempotent, non-destructive local operation, so the description is not needed for safety disclosure. It goes meaningfully beyond that by disclosing the analysis methodology: the z <= -3 flagging threshold and the exact usd_at_risk formula (closed deals x (team rate - rep rate) x average won amount). It does not explain what 'z' is computed over or the time window, which are the remaining behavioral unknowns.

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?

Two dense sentences with no filler; the core metric is front-loaded and the risk formula follows. Slight deduction because the compact formula notation ('z <= -3', 'x' as multiplication) assumes statistical vocabulary the agent may need to interpret.

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?

An output schema exists, so return values need not be described. However, for an analytical tool the description omits key framing: the time window of closed deals considered, what population 'z' is standardized against, and minimum sample-size caveats for small teams. These gaps matter for interpreting the flagging output 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?

Schema coverage is 100% and the single parameter already carries a description and default, so the baseline is 3. The description earns an extra point by clarifying the parameter's actual role: `from_stage` defines the cohort entry stage for closed deals, not merely a generic 'stage to measure from'.

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 names a specific computed metric (stage-to-won rate by owner) and defines both its numerator cohort ('closed deals that entered `from_stage`') and its comparison baseline ('the rest of the team'). It does not explicitly differentiate itself from siblings like pipeline_summary, but the metric is precise enough to be self-distinguishing.

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?

Usage is only implied: an agent can infer this is a diagnostic/analytics call for spotting underperforming reps, but there is no explicit 'use this when...' or 'use pipeline_summary instead when...' guidance. No prerequisites, no exclusions, and no statement of what data window or pipeline scope is analyzed.

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

Deploy Server

Other Tools