Loading ToolBench
A Model Context Protocol (MCP) server for Acumatica ERP - query and act on any tenant's contract-based REST API through 8 generic tools.
Server provides 8 well-named tools with clear verb-noun patterns (describe_, list_, get_, upsert_, delete_, invoke_, get_). All tools have descriptions (avg 85 chars, within baseline 34-392). Input schemas are present with type definitions for all parameters. However, parameter descriptions are minimal (often 1-2 lines), output schemas are not documented, and error handling lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing pagination details for list_records despite OData support. Composition is sound, tools chain well (describe_entity → list_records → get_record → upsert_record). Security: credentials injected via environment, no secrets in params. Overall: functional but lacks LLM-optimization depth.
Delete a record (DELETE /{Entity}/{id})
Describe an entity: fields, key format, actions, expand for any entity
Get a single record by ID (GET /{Entity}/{ids|id})
Get extension-field schema and view names (GET /{Entity}/$adHocSchema)
Invoke an entity action (POST /{Entity}/{ActionName}) such as Release, Cancel, etc.
List known entities from entity_catalog.json
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels. Tools marked READ_ONLY, WRITE, DESTRUCTIVE in metadata but not exposed to LLM via schema annotations.
Output schemas not documented. LLMs cannot infer what fields list_records, get_record, describe_entity return. Prevents downstream tool chaining and forces LLM to guess field names.
list_records lacks pagination documentation. Accepts OData $top/$skip but no guidance on default limits, max results, or when to paginate. Risk of context window exhaustion with large result sets.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | <=2025-11-25 | v2 |
List records from an entity with OData parameters (GET /{Entity})
Create or update a record (PUT /{Entity})
Parameter descriptions are minimal (1-2 sentences). E.g., 'data' in upsert_record: 'The record data to create or update' lacks format guidance, required fields, or examples of valid structure.
Error handling lacks recovery guidance. No indication of what to do if entity not found, ID invalid, or API call fails. LLM receives raw HTTP errors with no actionable next steps.