Skip to main content
Glama

Cogmento MCP by usefulapi

List deals

cogmento_list_deals
Read-only

List or search deals (title, amount, close date, assigned users, products). GET /deals/.

Input Schema

NameRequiredDescriptionDefault
sortNoField to sort by, e.g. created_at; prefix with - for descending, e.g. -last_modified.
limitNoRows per page, 1-100 (default 25).
startNoRow offset to start from (default 0). Pass the previous reply's next_start.
filtersNoConditions, all of which must match (AND). Dates are yyyy-mm-dd.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the HTTP endpoint and the searchable field set but says nothing about pagination, result ordering defaults, or result volume beyond what the schema states.

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?

A single front-loaded sentence plus the endpoint, with no filler. Slightly thin rather than verbose; nothing is wasted but the parenthetical field list could have been framed as filterable fields.

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?

There is no output schema, and the description does not describe the return shape (deal records, paging via next_start, total counts). Annotations cover the read-only/open-world profile and the schema covers all four parameters, so the remaining gap is moderate but real.

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%, with sort, limit, start and filters all documented in detail including the next_start paging hint. The description's field list hints at what can be filtered on, but adds no syntax or operator detail beyond the schema, so baseline 3 applies.

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?

States a specific verb ('List or search') and resource ('deals'), plus the endpoint GET /deals/. The enumerated fields (title, amount, close date, assigned users, products) make clear this is the multi-record read, distinguishing it from cogmento_get_deal and cogmento_aggregate_deals, though it never explicitly names those siblings.

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 implied by 'list or search' plus the mention of filterable fields, but the description never says when to use this versus cogmento_get_deal (single record) or cogmento_aggregate_deals (aggregation), and gives no exclusions or prerequisites.

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.