Loading ToolBench
MCP server for the Apple App Store Connect API and App Store Server API (StoreKit 2). 890 tools across 13 profiles, generated from Apple's official OpenAPI spec, plus review triage and reply drafting that runs on your own model, and confirm-before-write safety. Works with Claude, Codex, Cursor and any MCP client.
Heimdall provides 5 well-structured StoreKit tools with complete JSON schemas and detailed descriptions. All tools follow verb_noun naming (get_*, check_*). Descriptions are substantive (150-250 chars), exceeding the baseline median of 194 chars. Input schemas are explicit and properly typed. However, OUTPUT schemas are undocumented, the tools describe what they return in prose ('Apple's SIGNED transactions', 'verified and decoded') but lack formal response type definitions that LLMs can parse. This is the primary gap: agents cannot reliably extract fields from responses without schema documentation. Error handling guidance is minimal, tools do not explain recovery steps for common failure cases (invalid transaction ID, authentication errors, rate limits). No confirmation-before-write pattern despite sensitive operations (check_entitlement could trigger business logic). Parameter descriptions are good but lack format hints (e.g., transaction_id format, expected length). Overall, this is a solid B-range implementation, well above median, but falls short of A-grade due to missing output schemas and limited error recovery guidance.
Answer the single question "does this customer currently have access?". Returns a boolean plus the active subscriptions backing it — those come back as Apple's SIGNED payloads (JWS strings), so verify and decode them before reading any field. Optionally narrow to one product ID. [App Store Server API]
List every refunded transaction for a customer. Useful for auditing refund abuse before granting goodwill credit. Returns Apple's SIGNED transactions (JWS strings) unless ASC_APPLE_ROOT_CERTS is set, in which case they arrive verified and decoded. [App Store Server API]
Get the status of every subscription a customer holds, including expiry date, auto-renew state, billing retry and grace period. Apple returns those fields inside SIGNED payloads (JWS strings) on each item, so verify and decode them before reading. Use this for entitlement checks. [App Store Server API]
Get a customer's full purchase history from any one of their transaction IDs. Supports filtering by product type, product ID and date range. Returns Apple's SIGNED transactions (JWS strings) unless ASC_APPLE_ROOT_CERTS is set, in which case they arrive verified and decoded. [App Store Server API]
Output schemas are undocumented. Tools return complex nested payloads ('SIGNED transactions', 'verified and decoded' records, 'active subscriptions', 'refund items') but the response structure is not formally specified. LLMs cannot reliably extract fields (e.g., transaction dates, subscription expiry, refund amounts) without a documented output type. Agents must guess or parse prose descriptions, increasing hallucination risk.
No error recovery guidance. Tools do not explain how to handle common failures: invalid transaction_id, authentication/credential errors, rate limiting from Apple, network timeouts. Error responses should guide the agent ('Invalid transaction ID format. Transaction IDs are 50-character alphanumeric strings.') and suggest recovery ('Retry after 60 seconds' for rate limits).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 73 | 2026-07-28+ | v2 |
Get a single transaction: product, price, dates, ownership type and revocation state. Set ASC_APPLE_ROOT_CERTS and the payload arrives verified and decoded; without it you get Apple's SIGNED payload (a JWS string) to verify yourself with the App Store Server Library. [App Store Server API]
Parameter format constraints are missing. 'transaction_id' (required on all tools) has no description of its format: length, character set, origin (Apple-issued), or validation rules. 'status' enum values (1=Active, 2=Expired, etc.) are documented only in prose within the description, not enforced by the schema. LLMs may pass invalid values.
JWS payload handling is complex and error-prone. Tools return 'Apple's SIGNED transactions (JWS strings)' unless ASC_APPLE_ROOT_CERTS is set. This dual-mode behavior (raw vs. decoded) requires agents to understand cryptography and certificate validation. No helper tools to verify/decode JWS or guidance on when to request raw payloads. Simplify: offer a separate 'verify_and_decode_jws' tool or always return decoded.
No pagination guidance for get_transaction_history. The schema includes 'max_pages' (default 5, 20 transactions per page) and returns 'hasMore' and 'revision cursor', but the output schema is not documented. Agents cannot predict response size or plan pagination loops. Document the response structure and provide an example of chaining pagination calls.
check_entitlement performs a business-critical decision (entitlement grant) but has no confirmation or dry-run option. An agent invoking this may trigger downstream systems (access grants, feature unlocks) without explicit user confirmation. No safety pattern present.