Apier MCP Server

Apier price list (keyless)

get_pricing

Read-onlyIdempotent

Check per-call costs before metered work, even without an API key. Returns a machine-readable price list with enforcement status and recovery details to prevent unexpected 402 failures.

Instructions

Call this BEFORE metered work to check per-call cost and whether billing enforcement is live. Keyless: executes WITHOUT an API key, so an agent can price a workflow before it holds any credential. Returns the machine-readable price list: every credit-metered REST endpoint with its MCP tool name and cost in whole øre (always an integer), the enforcement.live flag (while false nothing is debited and a 402 is impossible), the 402 INSUFFICIENT_CREDITS recovery-contract field list, the top-up bounds with top_up_url, and the how_to_pay_guide URL. Prices derive from the SAME configuration the 402 meter debits, so this surface cannot drift from enforcement. Input: none — call with {}. Failure modes: per-IP rate limiting and transient errors only. For the calling key's own balance, use get_credit_balance (Bearer key required) instead. Docs: https://www.apier.no/docs/guides/billing

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	No
`result`	Yes	The machine-readable price list: per-endpoint/tool costs in whole øre, enforcement.live, the 402 recovery-contract shape, top-up bounds, and the how_to_pay_guide URL.
`metadata`	Yes
`justification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.1Sep 26, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the annotations (read-only, idempotent, non-destructive), the description discloses key behavioral traits: it executes without an API key, the enforcement.live flag determines debiting, and the price list is derived from the same configuration as the 402 meter to prevent drift. It also lists failure modes, adding significant context not captured by annotations.

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 well-structured and front-loaded with the critical usage instruction. Every sentence adds specific value—keyless execution, return content, enforcement alignment, failure modes, and the alternative tool. It is dense but not verbose, and the flow from purpose to details is logical.

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?

Given the tool's complexity and the existence of an output schema, the description is complete. It covers the return payload's key elements, failure modes, usage timing, and the relationship to get_credit_balance, leaving no ambiguity about when and how to invoke the tool. The docs URL also provides a fallback for deeper detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and the description explicitly states 'Input: none — call with {}.' This reinforces the schema and leaves no ambiguity. With no parameters to document, the description fully satisfies this dimension.

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 identifies the tool as a price list for Apier, with a specific imperative ('Call this BEFORE metered work') and explicit purpose: to check per-call cost and whether billing enforcement is live. It also distinguishes itself from the sibling get_credit_balance by clarifying its keyless, pricing-focused scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description explicitly states when to use the tool ('before metered work'), provides a clear alternative for balance queries ('use get_credit_balance (Bearer key required) instead'), and notes failure modes. This gives the agent unambiguous guidance on selecting this tool.

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