qbo-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct area: OAuth, company read, employee listing, salary update, payroll status, and payroll preview. The only potential confusion is qbo_payroll_status vs qbo_payroll_preview, since both concern the dry-run payroll path, but the descriptions clarify that one reports run status while the other produces preview totals and output artifacts.
Naming Consistency4/5
All tools share the qbo_ prefix and snake_case style, and most follow a verb_noun pattern (read_company, list_employees, update_employee_salary). Minor deviations exist: qbo_oauth is a bare noun and the two payroll tools are noun phrases, but the overall pattern remains predictable and readable.
Tool Count5/5
Six tools is well-scoped for a QuickBooks employee/payroll integration. Each tool earns its place, covering a step in the auth → company → employees → payroll workflow without padding or bloat.
Completeness4/5
The core workflow is covered: authenticate, read company, list employees, update salary, preview payroll, and check status. Minor gaps like employee creation/deletion, company update, and actual payroll submission are absent, but the payroll submission omission appears intentional given the repeated 'never submits payroll' notes, so agents can still complete the intended workflow.
Average 3.8/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key invariant: 'Door 1 is always dry-run / not submitted,' which adds behavioral context beyond a simple status fetch. However, with no annotations provided, the description carries the full burden of explaining side effects, output structure, or other behavioral nuances. It does not clarify whether this is a read-only operation or describe the response format, though 'fetch' implies read-only.
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?
The description is two short sentences with no redundant filler. The primary action is stated upfront, and the Door 1 caveat is a concise but essential addition that earns its place. Every word contributes value.
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?
Given no output schema, the description would need to clarify what the tool returns to make it fully complete. It mentions 'status' and the Door 1 rule, but does not describe the overall return shape, possible statuses, or whether multiple doors are included. Without that, an agent may struggle to correctly interpret the response, though the simplicity of the tool mitigates the gap. The description is adequate for initiating a call but leaves some ambiguity for downstream use.
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 has zero parameters and the input schema is empty, so there is no parameter complexity to document. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description adds no parameter information because none is 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?
The description uses the specific verb 'fetch' with resource 'payroll run status', clearly identifying the tool's function. The additional note about Door 1 provides scoping detail, but it does not explicitly differentiate from the sibling qbo_payroll_preview, leaving some ambiguity about the exact boundary between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like qbo_payroll_preview. The Door 1 note is a behavioral caveat, not a usage directive. Without explicit 'use when' or 'instead of' information, an agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully disclose behavior, but it only states the action 'List'. It does not explicitly confirm read-only safety, mention output format, or note any error conditions (e.g., missing connection). While 'List' implies a non-mutating operation, the lack of explicit disclosure leaves significant gaps.
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?
The description is a single, focused sentence with no wasted words. It front-loads the core action and scope, and the additional parenthetical about fixture names is relevant context. This is appropriately concise.
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?
For a simple parameterless list tool, the description is mostly adequate, but it omits prerequisites (authentication/connection setup) and any details about the response. The mention of 'prove path' is ambiguous without further explanation, and the tool's behavior in error cases is unaddressed.
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 has zero parameters, so there is no schema or description burden to explain parameter meaning. A baseline of 4 is appropriate because the description correctly reflects the parameterless nature without adding unnecessary detail.
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?
The description explicitly states the verb 'List' and the resource 'employees', making the primary action unambiguous. It also names the specific context ('connected company') and test fixture ('Acme Bookkeeping'), clearly distinguishing it from sibling tools like qbo_update_employee_salary or qbo_oauth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description only implies a prerequisite ('connected company') but does not mention that OAuth may be required first, nor does it contrast with other listing/reading tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does explain the difference between placeholder env behavior (completes fixture) and live mode (returns authorize URL), which is valuable. However, it omits potential side effects, required credentials, or what the flow entails beyond the URL response.
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 concise sentences convey the purpose, behavior, and mode distinction with no filler. The key information is front-loaded and every word 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 simple tool with one parameter and no output schema, the description covers the essential behavioral modes. Minor gaps like required environment variables or how to use the returned URL are not critical for invocation, so the description is reasonably complete.
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%, so the parameter is already documented. The description adds context about fixture vs live mode but does not directly explain the 'fixture' parameter beyond implying its role. The schema already provides a clear description, so the 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?
The description clearly states a specific action ('Connect OAuth') and the resource, distinguishing it from sibling tools that read/update payroll data. However, it does not explicitly compare itself to siblings, so it misses the full differentiation mark.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains two modes (fixture sandbox vs live mode) with conditions implied by the environment, but it does not explicitly state when to use this tool over alternatives or provide any when-not-to-use guidance. Some context is given, but no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It transparently discloses the dry-run nature, the side effect of writing files, the default behavior ('Confirm-screen defaults ON'), and the critical safety guarantee ('Never submits payroll'). This is strong transparency for a payroll-related 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?
Three short sentences, front-loaded with the primary action, followed by critical safety and default info. Every sentence earns its place; no filler or repetition.
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?
The description is concise yet covers the essential behavior, safety, default settings, and output artifacts. It lacks explicit mention of return values, but no output schema exists and the tool's purpose is clear enough for an agent to invoke it correctly.
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?
The input schema already fully documents the 'write' parameter with its default and description. The tool description adds context about writing markdown/html but does not directly explain the parameter's effect beyond what the schema states. Baseline 3 applies since schema coverage is 100%.
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?
The description uses specific verbs ('Fetch', 'write') and names the resource (dry-run payroll preview totals, markdown/html). It clearly distinguishes itself from siblings by emphasizing it never submits payroll, so the agent knows exactly what this tool does and does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use case (dry-run preview before actual submission) and states a key exclusion ('Never submits payroll'), but does not explicitly say when to choose this tool over alternatives or mention any prerequisites. Usage context is implied rather than directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. 'Read' clearly signals a non-mutating operation, and 'connected' hints at an authentication prerequisite, but the description does not disclose what the profile contains, what happens if no connection exists, or any other runtime behavior.
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?
A single, front-loaded sentence states the verb, object, and connection context with zero filler. Every word contributes meaning, making this appropriately concise for such a simple tool.
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 read operation with no output schema and no annotations, the description provides enough information for an agent to select and invoke the tool correctly. Minor gaps are the lack of explicit return-value detail and any statement about ordering relative to qbo_oauth, but neither is necessary for basic invocation.
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 input schema has zero parameters, so schema-description coverage is vacuously 100%. With no parameters to document, the description does not need to add parameter-level detail, and the 0-parameter baseline of 4 applies.
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?
The description uses a specific verb ('Read') and a specific resource ('connected QuickBooks Online company profile'), making the tool's purpose immediately obvious. The resource is distinct from the sibling tools, which target OAuth, employees, salary, and payroll, so there is no ambiguity about what this tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'connected' implies this tool should be used after OAuth has been established, but the description does not explicitly state when to use it versus alternatives or mention any exclusions. For a simple read-only tool, the usage context is reasonably implied, but no explicit routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses the most important behaviors: default confirm-screen state, the confirm=true requirement to apply, and the 'never submits payroll' limitation. It doesn't discuss auth, side effects, or return values, but the key operational traits are covered.
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 short, front-loaded sentences with no filler. It states the action, then the confirmation requirement, then the key non-payroll boundary. Every sentence 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 simple 3-parameter tool with no annotations or output schema, it provides essential context: what is updated, that it's an example salary, the confirm gate, and that it never submits payroll. It omits return behavior and auth requirements, but the confirmation-flow disclosure makes the call behavior sufficiently clear.
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 description coverage is 100%, so the schema already documents employee_id, annual_salary, and confirm. The description's confirm wording largely restates the schema's 'Must be true to apply. Default false (confirm screen).' and adds little beyond what is already structured.
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?
Clear verb ('Update') plus resource ('one employee's example annual salary') and an explicit boundary ('Never submits payroll'), which distinguishes it from the payroll-related sibling tools. An agent can tell exactly what this tool does and what it is not for.
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?
Provides clear operational guidance: confirm screen is default behavior, pass confirm=true to apply, and never submit payroll. It gives a useful when-not-to-use signal, though it doesn't explicitly name a sibling alternative for payroll submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![qbo-mcp MCP server](https://glama.ai/mcp/servers/ortizl20/qbo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ortizl20/qbo-mcp)

Score Badge

Copy to your README.md:

[![qbo-mcp MCP server](https://glama.ai/mcp/servers/ortizl20/qbo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ortizl20/qbo-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ortizl20/qbo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server