Loading ToolBench
Multi-MCP agent integration: Palantir Foundry OMCP + Spraay x402 batch payments. Demonstrates an AI agent reading enterprise data from Palantir's Ontology MCP and executing batch payments through Spraay's x402 MCP server.
This server exhibits critical definition gaps across nearly all dimensions. Tool names lack action verbs (settlePayroll, settleInvoices, settleMilestones use domain-specific verbs but are inconsistent with verb_noun convention). Parameter descriptions are present but minimal (10-50 chars, well below the 72-char baseline). Most critically, input schemas for 6 of 9 tools are incomplete or inferred from mock implementations rather than explicit MCP tool registration. The ctx parameter (present in tools 1-3) is an anti-pattern: it exposes internal client objects as parameters rather than using server-side injection. Output schemas are entirely undocumented, no tool declares what fields it returns. Error handling is absent: no recovery guidance, no error categorization, no actionable messages. The server reads like a proof-of-concept rather than production-grade tooling.
Executes a batch payment on the specified blockchain via Spraay x402 protocol. Settles multiple recipients in a single transaction.
Executes an action on the Palantir ontology. Supports RecordPayrollSettlement, RecordInvoicePayment, and RecordMilestonePayment action types.
Retrieves the USDC balance for a specified address on a given blockchain.
Retrieves a single ontology object by type and ID.
Retrieves a payment quote for a specified chain, token, and amount including estimated gas and fees.
Searches for ontology objects of a specified type with optional filtering. Supports PayrollRecord, Invoice, and SupplyChainOrder object types.
Queries approved invoices due within N days, groups by vendor chain preference, and settles via Spraay.
ctx parameter exposes internal MCP client objects as tool inputs. This violates secret-injection and composition patterns, clients should be injected server-side, not passed as parameters. Agents will log these objects, risking credential leakage.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., batchId, txHash, chainSettlement structure). Responses are unstructured.
Input schemas for tools 1 - 6 are incomplete or inferred from mock code. No explicit JSON Schema with type definitions visible. Parameter 'filter' in searchObjects and 'params' in executeAction are untyped objects with no constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 38 | 2026-07-28+ | v2 |
Checks supply chain orders for verified milestones and releases the corresponding percentage payment via Spraay.
Reads approved payroll records from the Foundry ontology, groups by chain, executes batch payments via Spraay, and writes settlement confirmations back to the ontology.
No error handling or recovery guidance. Irreversible operations (batchPayment, executeAction) lack dry-run, confirmation, or compensation patterns. Agents cannot distinguish retryable from fatal errors.
Parameter descriptions are minimal (10 - 50 chars vs. 72-char baseline). 'filter' and 'params' lack any guidance on valid structure, required fields, or examples. 'chain' in batchPayment lists 13 options but no description of what each does or when to use each.