Skip to main content
Glama
aol-integration

accurate-schema-mcp

by aol-integration
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

accurate-schema-mcp

Schema-aware Model Context Protocol server for Accurate Online.

Features

  • Always-fresh OpenAPI spec. Refetched on every server startup (i.e. each time Claude Desktop launches) and written over the cached copy, so new endpoints appear with no code change and no manual step. If the download fails, the cached copy is used.

  • Host auto-resolution. Nothing is hardcoded — the server asks Accurate which host your API Token's database lives on. refresh_host re-resolves if the database migrates mid-session.

  • Delete kill switch. generic_call refuses delete endpoints (HTTP DELETE and */delete.do, */bulk-delete.do) unless you explicitly opt in.

  • Verified list fields. Accurate's spec documents no response schema for list.do, so real field names are shipped in list_fields.json and merged into every <resource>/list lookup.

  • Python 3.10+, zero config files beyond .env, only mcp + requests as dependencies.

Related MCP server: MYOB Codex MCP

Requirements

Install

git clone https://github.com/aol-integration/accurate-schema-mcp.git
cd accurate-schema-mcp
uv sync   # creates .venv from the exact versions pinned in uv.lock

Configure

cp .env.example .env

Edit .env:

ACCURATE_BEARER_TOKEN=<your_api_token>
ACCURATE_API_SECRET=<your_api_token_secret_key>


# generic_call refuses delete endpoints unless this is true.
ACCURATE_ENABLE_DELETE=false

See this page for more information on Accurate Online API Token authentication.

Add to Claude Desktop

  1. Open Claude Desktop.

  2. Go to Settings → Developer → Edit Config. This opens the folder containing claude_desktop_config.json.

  3. Open claude_desktop_config.json in a text editor.

  4. Paste this in. If the file already has mcpServers, add only the "accurate-schema" entry inside it.

    {
  "mcpServers": {
    "accurate-schema": {
      "command": "uv",
      "args": [
        "run",
        "--directory", "/absolute/path/to/accurate-schema-mcp",
        "python", "-m", "accurate_schema_mcp.server"
      ]
    }
  }
}

  5. Replace /absolute/path/to/accurate-schema-mcp with your clone's real path (pwd inside the folder). --directory also sets the working directory, so .env is picked up.

  6. Save the file and fully quit Claude Desktop (Cmd+Q on macOS), then reopen it. The config is only read at launch.

  7. Check the tools menu in the chat input — accurate-schema should appear with 4 tools.

The server speaks MCP over stdio.

Tools (4)

Tool

Arguments

Description

list_resources

—

All resource names (item, vendor, purchase-invoice, sales-order, …). Call first if you don't know the resource.

schema_lookup

endpoint

Fields, query params and required-ness for one endpoint. Accepts '<resource>/<action>' (e.g. 'purchase-invoice/save') or just 'item' to list that resource's endpoints.

generic_call

endpoint, params?, body?

Call any endpoint. params for GET/DELETE, body for POST (save, bulk-save).

refresh_host

—

Re-resolve which host the API Token's database lives on.

Typical flow

# 1) Which resources exist?
list_resources()
# -> ["access-privilege", "branch", "customer", "item", "purchase-invoice", ...]

# 2) What does this endpoint want?
schema_lookup(endpoint="purchase-invoice/save")
# -> {"method": "POST", "path": "/api/purchase-invoice/save.do",
#     "body": {"vendorNo": {"required": true, ...}, ...}}

# 3) Call it
generic_call(
    endpoint="item/list",
    params={"fields": "id,name,unitPrice", "sp.pageSize": 50},
)

Authentication

Each request is signed fresh — no session or token-refresh step:

X-Api-Timestamp: <unix epoch milliseconds>
X-Api-Signature: HMAC-SHA256(api_secret, timestamp)
Authorization:   Bearer <bearer_token>

The host is resolved at startup by calling https://account.accurate.id/api/api-token.do with the same headers. The host comes straight from d.database.host in that response (e.g. https://public.accurate.id) — one field, no payload walking. A 401 means the token or signature is invalid; note that Accurate also signals failure with HTTP 200 + {"s": false}, which is handled as an auth error.

GET requests retry up to 3 times with backoff on 502/503/504. Mutating requests are never retried — they may already have succeeded.

Schema cache

The OpenAPI spec is downloaded from https://account.accurate.id/open-api/json.do into schema/accurate_openapi.json on every server startup, overwriting the previous copy (first run simply creates it). The write is atomic — the spec is staged to a .tmp file and swapped in — and a response with no paths is rejected, so a bad download can't clobber a good cache. If the fetch fails and a cached copy exists, the server logs a warning and starts with the cache.

To refresh it by hand:

uv run python -m accurate_schema_mcp.fetch_schema --force

Environment variables

Variable

Required

Notes

ACCURATE_BEARER_TOKEN

yes

Accurate Online → Accurate Store → API Token

ACCURATE_API_SECRET

yes

Accurate Online → Developer Area

ACCURATE_ENABLE_DELETE

no

false by default; generic_call refuses delete endpoints until this is true

Project layout

accurate_schema_mcp/
├── server.py         MCP entrypoint (stdio)
├── tools_schema.py   the four tools + delete guard
├── client.py         HMAC auth, host resolution, HTTP
├── config.py         env vars / .env loader (no dependency)
├── schema_index.py   parses the OpenAPI spec into a flat index
├── fetch_schema.py   downloads the spec (refreshed every startup)
└── list_fields.json  verified list.do response fields (absent from the spec)
schema/
└── accurate_openapi.json   cached spec

Verifying it works

uv run python -c "from accurate_schema_mcp.client import get_client; c = get_client(); print(c.base_url)"

Printing a base URL like https://public.accurate.id/accurate confirms the credentials, the signature and host resolution all work. A 401 usually means a wrong secret, a wrong bearer token, or whitespace pasted into .env.

License

MIT

Available Tools

4 tools
generic_callA

Call any Accurate Online endpoint. Always run schema_lookup on the endpoint first so you know the correct field names, required fields, and types. For GET (list/detail) endpoints pass query params in params. For POST (save) endpoints pass the payload in body. For DELETE pass params (usually {'id': ...} or {'number': ...}).

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyNoJSON body, for POST (save/bulk-save) endpoints
paramsNoQuery params, for GET/DELETE endpoints
endpointYese.g. 'purchase-invoice/save', matches the key from schema_lookup

TDQS

A3.9/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 discloses the schema_lookup prerequisite and method-to-param mapping, but says nothing about destructive semantics (DELETE endpoints), auth/refresh_host usage, rate limits, error shapes, or whether POST save is upsert vs insert. For a tool that can mutate any resource, these omissions are notable.

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?

Four sentences, each carrying distinct required information (dependency, GET pattern, POST pattern, DELETE pattern). Front-loads the critical schema_lookup prerequisite. No waste.

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

Completeness3/5

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

No output schema and no annotations, so the description is the sole source of behavioral context. It covers the calling convention well but leaves mutation semantics, auth/refresh flow, and response handling unaddressed for a tool capable of arbitrary resource mutation.

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

Parameters3/5

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

Schema coverage is 100% and the schema already documents body as 'JSON body for POST' and params as 'Query params for GET/DELETE'. The description reinforces the mapping and adds the DELETE id/number example, but largely restates schema content. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ('Call any Accurate Online endpoint') with an explicit dependency, and it is distinguishable from siblings by being the invocation mechanism while schema_lookup is the discovery mechanism. Lacks specificity about which endpoint families exist, but the generic nature is intentional.

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 prerequisites ('Always run schema_lookup on the endpoint first') and routes by HTTP method to the correct parameter bucket (GET/DELETE -> params, POST -> body) with concrete examples including id vs number for DELETE. This is exactly the when/when-not guidance needed for a generic dispatcher.

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

list_resourcesA

List all Accurate Online API resources available (e.g. 'item', 'vendor', 'purchase-invoice', 'sales-order'). Call this first if you don't know the resource name for what the user is asking about.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/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 burden. It implies a side-effect-free enumeration with no arguments, which is meaningful context, but says nothing about authentication requirements, result size, or ordering. Adequate but not rich behavioral disclosure.

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?

Two sentences, zero filler. The verb and resource lead, examples follow, and the usage rule closes. Every clause earns its place.

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 zero-parameter discovery tool with no output schema or annotations, the description supplies what an agent needs to decide to call it and what to expect (a set of resource identifiers, illustrated by examples). Minor gap: it never states explicitly that the return value is a list of names to feed into subsequent calls.

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?

The tool takes zero parameters, so the baseline is 4. The description correctly signals that the call is parameterless by framing it as a pure enumeration step, adding a little context beyond the empty schema.

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 ("List") and resource ("Accurate Online API resources") and concretizes it with real examples ('item', 'vendor', 'purchase-invoice', 'sales-order'). The discovery framing ("if you don't know the resource name") distinguishes it from the sibling schema_lookup, which presupposes a known resource.

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

Usage Guidelines4/5

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

Gives an explicit trigger: "Call this first if you don't know the resource name for what the user is asking about," which implies the inverse condition (skip it when the resource is known). It does not name schema_lookup as the follow-up alternative, so it stops short of full when/when-not/alternatives guidance.

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

refresh_hostA

Re-resolve which Accurate host this API Token's database lives on. Only needed if requests suddenly start failing in a way that suggests the database migrated to a different host mid-session.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It conveys that this is a maintenance/recovery side-effect operation, not a normal read, and implies it mutates session routing state. It does not state permissions, cost, or whether it can fail, but the situational framing is strong.

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?

Two tight sentences: the action first, the narrow triggering condition second. Every clause earns its place.

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 no-param, no-output-schema recovery tool, the description gives enough for an agent to know exactly when and why to call it. Only minor gap is what happens on success/failure, which is acceptable given the scope.

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?

Zero parameters, so baseline is 4. The description correctly signals the tool takes no input and acts on the ambient token context, which is the only semantic needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action (re-resolve host) tied to a specific resource (this API Token's database host). It is clearly distinguishable from generic_call or schema_lookup, though the term 'Accurate host' assumes product-specific context that isn't defined.

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?

Explicitly states when it is needed ('only if requests suddenly start failing in a way that suggests the database migrated') and implicitly when it is not (normally unnecessary), which is exactly the routing guidance an agent needs.

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

schema_lookupA

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.

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

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv0.1.0
    • First observedgeneric_call
    • First observedlist_resources
    • First observedrefresh_host
    • First observedschema_lookup
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct phase: list_resources for discovery, schema_lookup for metadata, generic_call for execution, and refresh_host for a specific maintenance edge case. There is no meaningful overlap; an agent can easily pick the right tool based on intent.

Naming Consistency4/5

All names use consistent snake_case, which is a strong pattern. However, schema_lookup and generic_call are noun/adj+noun rather than the verb_noun pattern seen in list_resources and refresh_host, a minor deviation from an otherwise predictable convention.

Tool Count5/5

Four tools is well-scoped for a generic API gateway: discovery, schema, execution, and host refresh. Each tool earns its place, and no unnecessary tools bloat the surface.

Completeness4/5

The surface covers discovery, metadata lookup, and execution for any endpoint, enabling full CRUD via generic_call. Minor gaps exist, such as no explicit pagination or batch helper, but these can be handled through generic_call parameters.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • dataverse-mcp-server

    rededis
    A
    license
    A
    quality
    A
    maintenance
    MCP server for Microsoft Dataverse API with safe-by-default configuration. Works with any Dataverse / Dynamics 365 environment.
    23
    26 npm
    7
    MIT

  • MYOB Codex MCP

    jaeko44
    A
    license
    C
    quality
    B
    maintenance
    Codex-safe MCP server for MYOB Business/AccountRight cloud. Provides read-only tools by default and mutating actions that require explicit approval before commit.
    63
    MIT

  • Exact Online

    iwebdevnl
    A
    license
    Not graded
    quality
    B
    maintenance
    Hosted MCP server for Exact Online. Ask questions, pull reports, and prepare bookings you approve first.
    MIT