Vaquill

by io.github.Vaquill-AI

Overview Discussions Admin

List Page Packs

list_page_packs

Read-only

Returns the page packs you can buy, and what they cost.

Free. Never charged, so you can poll it to keep your own price list current.

Authentication: a vq_key_ key holding translate:read.

Pages are sold in INR only

Translation pages are bought in Indian rupees with GST, through Razorpay. There is no USD price for a page, which is why the translation rows in GET /api/v1/api-credits/pricing carry usdCost: 0 and unit: "page". That zero means "not priced in dollars", not "free". This route is where the real price lives.

Pages are also a separate ledger from API credits. Credits do not buy pages and pages do not pay for primary-law calls.

Every money field is in paise

priceInr, baseInr and gstInr are in paise, 1/100 of a rupee, which is the unit the payment is charged in. priceInr is GST-inclusive and is the amount you pay. Only pricePerPageInr is in rupees, and it is a display figure.

Read this list rather than hard-coding a price. Larger packs are cheaper per page, and both pools (translation and ocr) have their own packs.

Example

curl https://api.vaquill.ai/api/v1/in/translation/packs \
  -H "Authorization: Bearer $VAQUILL_API_KEY"

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_page_packs"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare a safe read, but the description adds materially more: the call is never charged, so repeated polling is acceptable; it requires a `vq_key_` with `translate:read`; and the returned figures are in paise except `pricePerPageInr`. It also preempts a serious misread by explaining that `usdCost: 0` means "not priced in dollars", not free.

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?

Bolded leads and short sections keep it skimmable, and the purpose statement is front-loaded. Some material is on the long side for a zero-parameter lister — the Razorpay/GST aside and the reconciliation with API credits could be tightened without losing meaning.

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

Completeness5/5

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

For a parameterless read with an output schema and clear annotations, the description covers everything an agent needs: auth scope, cost model, currency, unit traps, and the instruction to read live prices instead of hard-coding them. Nothing essential is deferred to inference.

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?

The tool takes no parameters, which is the baseline-4 case, and the description has no parameter semantics to add. It does clarify the units and meaning of the returned money fields, but with an output schema present that is supporting context rather than the description's core duty here.

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?

Opens with a concrete verb and resource: "Returns the page packs you can buy, and what they cost." It also separates itself from the pricing endpoint by explaining that translation rows there carry `usdCost: 0` while "This route is where the real price lives," so an agent can pick the right tool without ambiguity.

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 a clear use case ("poll it to keep your own price list current") and a direct instruction against a common failure mode ("Read this list rather than hard-coding a price"). It stops short of naming a sibling tool or stating an explicit when-not-to-call condition, so it is clear context rather than full routing guidance.

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

All Vaquill tools Inspect

Try in Browser