Data Parrot AI Revenue Analyst for HubSpot

Review Pipeline History

get_pipeline_history

Read-onlyIdempotent

Return pipeline history for one concrete inclusive date range. For comparisons, call once per range with identical non-date arguments; align by explicit ranges and returned order, and treat unavailable history as missing, not zero.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`page`	No
`columns`	No	Optional fields; omission uses view defaults. For deal_changes, movement_type identifies the fact. assigned_to_owner means unassigned-to-assigned or entering owner/team scope; assigned_from_owner means assigned-to-unassigned or leaving scope; owner_changed is in-scope reassignment. amount is the ending deal_value_property value. Concurrent value and owner changes produce two fact rows.
`group_by`	Yes	Historical grouping. Limits: 120 day, 208 week, 60 month, or 40 quarter periods.
`team_ids`	No	Exclusive selector: exact team IDs, expanded to active owners.
`owner_ids`	No	Exclusive selector: exact IDs from the owners catalog.
`page_size`	No
`date_range`	Yes	Required explicit inclusive pipeline-history date range, bounded to 120 day, 208 week, 60 month, or 40 quarter periods for the selected grouping.
`end_stages`	No
`segment_by`	No	Optional current/latest deal-health segmentation for history_view=deal_changes.
`owner_scope`	No	Exclusive selector: all owners or current authenticated user.
`amount_range`	No	Inclusive configured Deal-value range.
`history_view`	No	For what changed or why pipeline grew or shrank, start with waterfall. Use stage_transitions for stage-flow causes and deal_changes for supporting deals. snapshot shows state, not change drivers.	snapshot
`start_stages`	No
`segment_value`	No
`group_page_size`	No
`pipeline_stages`	No
`movement_direction`	No	Movement direction filter for stage_transitions or deal_changes. Use pipeline_changed for moves between pipelines and won or lost for historical outcomes.

Output Schema

TableJSON 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.

First observedSep 15, 2026

TDQS

A3.7/5.0

Behavior4/5

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

The description adds value beyond annotations by disclosing the behavior that unavailable history is treated as missing, not zero, and that comparisons require aligned ranges and order. Annotations already indicate read-only, idempotent, and non-destructive, but the description enriches the operational context without contradicting them.

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?

Two sentences with zero filler. The purpose is front-loaded, and the comparison guidance is directly actionable. Every clause earns its place, making it highly concise and well-structured.

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?

Given the tool's complexity (17 parameters, nested objects, output schema), the description is minimal. It covers key caveats like missing data and comparison alignment but omits pagination behavior and broader use-case guidance. The output schema likely covers return format, and the schema covers parameter specifics, so it is not severely lacking, but more context would improve completeness for an agent.

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 59%, so the schema handles many parameters well, including history_view, movement_direction, and columns with detailed descriptions. The description itself does not add parameter-specific semantics beyond referencing 'non-date arguments' and 'explicit ranges,' which are generic. Baseline 3 is appropriate given moderate schema coverage.

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 clearly states the tool returns pipeline history for a specific inclusive date range. The verb 'return' and resource 'pipeline history' are specific. However, it does not distinguish from sibling tools like get_deal_timeline or get_forecast, so it misses the top score for 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance for comparisons (call once per range, identical non-date arguments, align by ranges, treat unavailable as missing). However, it does not state when to use this tool instead of alternatives like get_deal_timeline or get_forecast, nor does it give exclusions. The guidance is useful but incomplete for selecting between tools.

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?