Skip to main content
Glama
gptproto-ai

GPTProto MCP

Official
by gptproto-ai

Query live GPTProto model pricing

gptproto_pricing
Read-onlyIdempotent

Query GPTProto's live price catalog by exact model, search, or capability, and sort by starting price.

Instructions

Read GPTProto's live public price catalog. Query one exact provider/model, search all models, or filter a capability and sort by its starting price.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExact catalog operation tag, for example text-to-image or image-to-video
sortNocatalog
limitNo
modelNoExact provider/model ID
searchNoSubstring matched against model ID, alias, catalog model, and tags
languageNoen
capabilityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by saying the catalog is 'live' and 'public', and it details the modes of operation (exact query, search, capability filter with sorting), which go beyond the annotations. It doesn't contradict annotations, so a 4 is appropriate for adding useful context without redundancy.

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?

The description is two sentences with zero fluff. It front-loads the core purpose ('Read GPTProto's live public price catalog') and immediately lists the main usage modes. Every word earns its place, making it efficient and easy to scan for an agent.

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?

Given the tool's moderate complexity (7 parameters, 0 required, no output schema), the description covers the main querying mechanisms (exact, search, capability filter) and the output is 'price catalog', which implies return values. However, it doesn't explain the 'limit' and 'language' parameters' behavior, nor does it specify sorting direction (e.g., ascending by price), which might be ambiguous. It's close to complete but misses a few operational details.

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 description coverage is low at 43% (only 'mode' and 'model' have descriptions, and 'sort' has enum but no description beyond default). The description compensates by explaining the high-level purpose of key parameters: 'query one exact provider/model' for 'model', 'search all models' for 'search', and 'filter a capability and sort by its starting price' for 'capability' and 'sort'. This adds meaningful meaning over the schema, though it could be more explicit about 'limit' and 'language'.

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 tool reads GPTProto's live public price catalog, with explicit verbs ('Read', 'Query', 'search', 'filter') and a resource (price catalog). It distinguishes itself from siblings by focusing on pricing, whereas siblings like gptproto_models_list or gptproto_status handle model lists or status, making it easy for an agent to differentiate.

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 implies usage through its query modes ('Query one exact provider/model, search all models, or filter a capability and sort by its starting price') but does not explicitly state when to prefer this over siblings, nor does it mention exclusions. While it hints at being the go-to for pricing, it lacks explicit alternatives or when-not-to-use guidance, so it's only marginally clear.

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