Skip to main content
Glama
aol-integration

accurate-schema-mcp

by aol-integration
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

schema_lookup

Retrieve the fields, parameters, and requirements for an Accurate API endpoint before calling it; pass resource/action or just a resource to list endpoints.

Instructions

Look up the fields, parameters, and requirements for a specific Accurate endpoint before calling it. endpoint format is '/', e.g. 'purchase-invoice/save', 'item/list', 'vendor/detail', 'purchase-invoice/delete'. Use list_resources first if you don't know the resource name, or pass just the resource name (e.g. 'item') to see all its endpoints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endpointYese.g. 'purchase-invoice/save', 'item/list', or just 'item' to list its endpoints

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the dual-mode input behavior (full endpoint vs. bare resource name), but never states that this is a read-only metadata operation, what the response contains, or how unknown endpoints are handled.

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?

Three tight sentences, all front-loaded: purpose first, format second, fallback guidance last. No sentence restates the tool name or wastes tokens.

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

Completeness4/5

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

For a single-parameter read-only lookup with no output schema, the description covers the input contract and the discovery path well. It falls short only on output expectations, which an agent may still have to infer.

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?

With 100% schema coverage the baseline is 3, and the description earns an extra point by specifying the '<resource>/<action>' format convention with four concrete examples. The bare-resource-name shortcut is also clarified as a second valid input shape.

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?

States a specific verb and resource: look up fields, parameters, and requirements for a named Accurate endpoint. The 'before calling it' framing cleanly separates it from generic_call, which performs the actual invocation.

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?

Gives explicit when-to-use ('before calling it') and names the alternative (list_resources) with the exact condition that selects it. It also documents a fallback mode for when the caller only knows the resource name.

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

Deploy Server

Other Tools