Data Parrot AI Revenue Analyst for HubSpot

Search and Analyze Deals

get_deals

Read-onlyIdempotent

Find deals that need review: questionable Commit deals, forecast risk, stalled or dormant deals, repeated outreach with no recorded response, and candidates for leadership involvement. Search, filter, count activity, group, rank, and return open, won, or lost deals using CRM fields, Data Parrot AI assessments, and recorded activity counts. Open deals include AI forecast_category. Omitted owner selectors include all workspace owners. Use get_deal for a shortlisted deal's reasoning and evidence. Consult deals/analysis_concepts in the catalog when the appropriate assessment or filter is unclear.

Input Schema

Name	Required	Description	Default
`page`	No
`columns`	No	Optional Deal fields; omit for the compact default. Grouped row_count and amount_sum are automatic outputs; do not put them in columns.
`sort_by`	No	Sort by a catalog-supported Deal field.
`deal_ids`	No
`group_by`	No
`team_ids`	No	Exclusive selector: non-empty exact team IDs, expanded to active owners. Use instead of owner_scope or owner_ids.
`deal_name`	No
`owner_ids`	No	Exclusive selector: non-empty exact IDs from the owners catalog. Use instead of owner_scope or team_ids.
`page_size`	No	Row size 1-100; use page/page_size. Groups use group_page_size.
`owner_scope`	No	Exclusive selector: all owners or current authenticated user. Omitting all three owner selectors defaults to all workspace owners.
`amount_range`	No	Inclusive configured Deal-value range.
`deal_statuses`	No
`group_sort_by`	No	Required with group_by: row_count, amount_sum, label, or value_order. rows, amount, and revenue are aliases.
`company_filter`	No
`contact_filter`	No
`sort_direction`	No		asc
`deal_name_match`	No		contains
`group_page_size`	No
`pipeline_stages`	No
`purchase_intent`	No
`activity_filters`	No	Up to 10 ANDed per-deal count filters. Item: {activity_types:[...],count:{operator,value},time_range:{start_date,end_date}}. For no activity use activity_types:["any"], count:{operator:"eq",value:0}, and dates. any counts meetings, calls, sent or received customer emails, and communications; zero includes never-contacted deals. Meetings without meeting_types count each meeting once. With meeting_types, counts represent lifecycle events; the same meeting can count as both booked and held, so do not add these as distinct meetings.
`close_date_range`	No
`custom_properties`	No
`forecast_category`	No
`sales_performance`	No
`overall_deal_health`	No
`competitive_position`	No
`deal_progress_status`	No
`group_sort_direction`	No		desc
`close_date_confidence`	No
`deal_stage_confidence`	No
`deal_probability_range`	No
`custom_property_filters`	No
`include_null_close_date`	No

Output Schema

Name	Required	Description	Default
`data`	Yes
`kind`	Yes
`tool`	Yes
`summary`	Yes
`result_id`	No
`limitations`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / activity_filters / description

Previous value: -"Up to 10 ANDed per-deal count filters. Item: {activity_types:[...],count:{operator,value},time_range:{start_date,end_date}}. For no activity use activity_types:[\"any\"], count:{operator:\"eq\",value:0}, and dates. any counts meetings, calls, sent or received customer emails, and communications; zero includes never-contacted deals."New value: +"Up to 10 ANDed per-deal count filters. Item: {activity_types:[...],count:{operator,value},time_range:{start_date,end_date}}. For no activity use activity_types:[\"any\"], count:{operator:\"eq\",value:0}, and dates. any counts meetings, calls, sent or received customer emails, and communications; zero includes never-contacted deals. Meetings without meeting_types count each meeting once. With meeting_types, counts represent lifecycle events; the same meeting can count as both booked and held, so do not add these as distinct meetings."

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / owner_ids / description

Previous value: -"Exclusive selector: exact IDs from the owners catalog."New value: +"Exclusive selector: non-empty exact IDs from the owners catalog. Use instead of owner_scope or team_ids."

changedInput schema / properties / owner_scope / description

Previous value: -"Exclusive selector: all owners or current authenticated user."New value: +"Exclusive selector: all owners or current authenticated user. Omitting all three owner selectors defaults to all workspace owners."

changedInput schema / properties / team_ids / description

Previous value: -"Exclusive selector: exact team IDs, expanded to active owners."New value: +"Exclusive selector: non-empty exact team IDs, expanded to active owners. Use instead of owner_scope or owner_ids."

Changed2 schema fields changedOct 21, 2026

changedInput schema / properties / columns / description

Previous value: -"Optional Deal fields; omit for the compact default. row_count and amount_sum are grouped metrics."New value: +"Optional Deal fields; omit for the compact default. Grouped row_count and amount_sum are automatic outputs; do not put them in columns."

removedInput schema / properties / forecast_status

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "minItems": 1,
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

First observedSep 15, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered. The description adds useful context beyond them: it names the data sources blended into results (CRM fields, Data Parrot AI assessments, recorded activity counts), notes that open deals carry forecast_category, and states the default when owner selectors are omitted. It says nothing about result limits, pagination caps, or cost/latency of the heavy activity-count filters.

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?

Four dense sentences, front-loaded with the highest-value scenario framing before mechanics, and the sibling pointer comes late where it belongs. No filler, though some sentences pack many clauses ("Search, filter, count activity, group, rank, and return...") at the cost of readability.

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-value shape need not be described, and the read-only annotations cover safety. But for a 34-parameter tool with zero required params and many unlabeled AI-assessment enumerations, the description leaves the agent dependent on an extra catalog call (deals/analysis_concepts) and does not clarify interaction rules among exclusive selectors (owner_scope/owner_ids/team_ids) or group_by vs. group_sort_by for row results.

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?

With 34 parameters and only 26% schema description coverage, the description carries a large compensation burden and only partly meets it: it explains the owner-selector defaulting, open-deal forecast_category availability, and the activity-count concept generally. Many high-impact filters (pipeline_stages, purchase_intent, sales_performance, overall_deal_health, competitive_position, deal_progress_status, close_date_confidence, custom_properties) are given no meaning at all and are deferred to a catalog lookup, leaving the agent unable to construct them from the description alone.

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?

States specific verbs and resource ("Find deals that need review", "Search, filter, count activity, group, rank, and return open, won, or lost deals") and enumerates concrete review scenarios (questionable Commit deals, forecast risk, stalled/dormant, outreach with no response). It explicitly separates itself from the sibling get_deal by scoping this tool to search and get_deal to a shortlisted deal's reasoning.

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?

Gives clear when-to-use framing (review triage, leadership involvement, forecast risk) and an explicit alternative: "Use get_deal for a shortlisted deal's reasoning and evidence." Also routes to the catalog when filter selection is unclear. It lacks an explicit when-not-to-use statement (e.g. bulk export vs. single-deal lookup beyond the get_deal pointer), which keeps it short of a 5.

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

All Data Parrot AI Revenue Analyst for HubSpot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?