Skip to main content
Glama
doitintl

DoiT MCP Server

Official
by doitintl
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
TypeScript
Remote

list_aws_planned_purchases

Read-only

Get planned AWS commitment purchases for your organization to evaluate and optimize cloud costs. Review laddering projections by commitment type to plan future purchases.

Instructions

Evaluate current AWS commitments, plan and automate purchases, and optimize cloud costs with PerfectScale for Commitments. Returns planned purchases (laddering projections) for the AWS organization. One item per commitment type that has a projection available (typically compute and/or database; up to four commitment types as PerfectScale for Commitments expands).

With no filters, returns all available planned-purchase items for the AWS organization in stable commitment-type order (compute, then database, then any future commitment types in enum order). When a filtered commitment type has no planned purchases, the response is an empty items array (not 404). Partial items return only the fields available at response time.

404 is returned only when the AWS organization does not exist or the caller cannot access it. An AWS organization that is not onboarded for PerfectScale for Commitments still returns 200 with an empty items array when no planned purchases exist — use GET /ps4commitments/v1/aws/organizations (or get-by-id) for onboardingStatus.

Pagination: results are returned in stable commitment-type order (compute, then database, then any future commitment types in enum order). Use maxResults to limit page size (default 50, max 500). When more items remain, the response includes a non-null pageToken; pass it unchanged on the next request with the same query parameters (service, maxResults). rowCount is the number of items in this page. An invalid pageToken returns 400 with code pagination_token_invalid; an expired token returns 400 with code pagination_token_expired. This endpoint is paginated: to fetch the next page, call again passing the response's pageToken value as the pageToken parameter. Stop once the response has no pageToken — that means there are no more pages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serviceNo
pageTokenNo
maxResultsNo
X-Tenant-IdNo
customerContextNoScope the request to a specific customer by ID. Required for DoiT employees (whose token isn't tied to a single customer); omit for direct customer users.
managementAccountIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.19.2

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark the tool read-only and non-destructive, and the description adds substantial behavior: stable ordering, empty items vs 404, partial-field responses, and exact pagination error codes. This goes well beyond the structured annotations 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and front-loaded, with useful operational details. However, the stable commitment-type order is stated twice, the pagination paragraph redundantly repeats the call-again instruction, and the opening sentence is more promotional than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a paginated list with no output schema, it covers ordering, empty responses, 404/onboarding cases, pagination tokens, and rowCount semantics. It stops short of describing planned-purchase item fields or the required managementAccountId parameter semantics, but the invocation-relevant behavior is well covered.

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 only 17%, so the description must compensate. It does explain service as a filter, maxResults limits (default 50, max 500), and pageToken handling, but it never explains the required managementAccountId or X-Tenant-Id semantics, leaving important parameters to inference.

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?

The description clearly states the resource (planned purchases / laddering projections for the AWS organization) and the verb (Returns). It also clarifies scope — one item per commitment type — which differentiates it from tools that list existing commitments like list_aws_savings_plans or list_aws_reserved_instances.

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?

It explains behavior with no filters, with a filtered commitment type, and for non-onboarded organizations, and explicitly routes 404 cases to GET /ps4commitments/v1/aws/organizations for onboardingStatus. It does not name sibling tools as alternatives for existing commitments, so some when-not-to-use guidance remains implicit.

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