QuickBooks Online MCP Server

create_attachable

Uploads a file attachment to QuickBooks Online from a local path, HTTPS URL, or base64 content, optionally linking it to an invoice, bill, or other entity.

Instructions

Create an attachable (file attachment) in QuickBooks Online. File content can come from file_path (a file on the machine running this server — preferred for local files of any size), file_url (an https URL the server downloads), or base64_content (inline bytes — only practical for small files). Precedence: file_url/file_path (mutually exclusive) win over base64_content. With no file source, creates a metadata-only attachment record. Max file size 100 MB (QBO limit).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "params": "<params>"
    },
    "name": "create_attachable"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.4/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 and does disclose non-obvious behavior: source precedence, that omitting all sources silently produces a metadata-only record rather than an error, and the 100 MB QBO limit. It does not describe required OAuth scopes, whether the referenced entity must already exist, or error behavior, leaving a few behavioral gaps for a mutation tool.

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, front-loaded with the purpose, then source selection and precedence, then the metadata-only edge case, then the size ceiling. No filler and no repetition — every sentence adds a decision-relevant fact.

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 create tool with no annotations and no output schema, the description covers the hard parts: where bytes can come from, precedence, the metadata-only fallback, and the size limit. It stops short of stating permissions/auth requirements or what the created record returns, which an agent would still need 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?

Top-level schema description coverage is reported as 0% (the 'params' wrapper itself is undocumented), so the description must compensate — and it does, explaining the three mutually exclusive content sources and their precedence in a single compact paragraph. The remaining parameters (file_name, note, category, content_type, attachable_ref) are only covered by the nested schema, not the description, so it isn't fully compensating.

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 — 'Create an attachable (file attachment) in QuickBooks Online' — with a clarifying gloss on what an attachable is. The create/get/update/delete/search attachable sibling set makes the operation unambiguous, and the following sentences pin down exactly what 'create' entails here (file-backed vs metadata-only).

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 explicit when-to-use guidance for each content source: file_path for local files of any size, file_url for web-reachable files, base64_content only for small files, and no source at all to make a metadata-only record. It also states mutual exclusivity and precedence. It does not point to update_attachable or search_attachables as alternatives, so it falls short of a full 5.

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

Deploy Server