This server has 39 tools with significant structural inconsistencies. While tool names follow verb_noun convention (positive), most tools lack visible input schemas in the source code provided. The descriptions are present but often generic and minimal (10-30 chars). Critical issue: The source code provided shows only barrel exports and high-level file structure, actual tool definitions with full schemas are not visible in the provided code sample. Per the rubric's hard rules, if tool definitions are inferred rather than directly visible, they must be capped at 50. Tools marked as 'Input: {}' (get_company_info, get_profit_loss, get_balance_sheet, get_trial_balance, get_report, receive_payment, create_transfer, create_journal_entry, edit_journal_entry, create_bill, edit_bill, create_expense, edit_expense, create_sales_receipt, edit_sales_receipt, create_invoice, edit_invoice, create_deposit, edit_deposit, create_vendor_credit, edit_vendor_credit, create_bill_payment, create_customer, edit_customer) have zero visible schema in the source, these tools receive a schema score of 0. Only 3 tools show any input schema in the metadata (query, get_journal_entry, get_bill, get_expense, get_sales_receipt, get_invoice, get_deposit, get_vendor_credit, get_bill_payment, get_customer, qbo_authenticate). Descriptions are universally under 100 chars and lack actionable context (e.g., 'Create a journal entry in QuickBooks Online' does not explain when to use it vs edit_journal_entry, what parameters are required, or what the tool returns). No output schemas are documented. No error recovery guidance is provided. The code shows a clean architecture with separate handlers and credential providers, but tool-level quality cannot be verified from the provided sample.
26 of 39 tools have no visible input schema in provided source code. Per hard scoring rule: 'If tool definitions are inferred rather than directly visible, cap that tool's overall at 50.' Tool definitions show only names and descriptions in the metadata provided; actual schema objects in src/tools/index.ts are not visible in the sample.
URGENT: Provide complete, visible input schemas for all 39 tools in src/tools/index.ts. Each schema must include type declarations and descriptions for every parameter. Tools with empty schemas ({}) must be updated to include all required and optional fields.
Expand all tool descriptions from current 20-50 chars to 100-200 chars. Each description must answer: (1) WHAT does this tool do? (2) WHEN should the LLM call it? (3) WHAT does it return? Example: 'Create a bill in QuickBooks Online' should become: 'Create a bill to record a vendor's invoice. Use this when you need to record an expense from a vendor and plan to pay it later. Returns bill ID, vendor info, and total amount. Bills can be edited or paid via create_bill_payment.'
Document output schemas for all tools. For read operations (get_*, query, list_*), specify the returned fields and their types. For write operations, document what is returned (e.g., entity ID, updated record, confirmation). Include IDs and references needed for chaining (e.g., if get_customer returns a customer_id, subsequent tools must accept it).
Add error recovery guidance to all tools. For example: 'If the query fails with a syntax error, check that the query follows QuickBooks SQL syntax (use Help to discover valid fields). If the API returns 'Insufficient permissions', ensure the OAuth token has the required scopes.'
Implement Multi Round-Trip Request (MRTR) confirmation for destructive operations. delete_entity should return { result: 'input_required', action: 'confirm', message: 'Delete entity {id}? This cannot be undone.' } to let the user confirm before execution.
All tool descriptions are generic and under 50 characters. None explain WHEN to use the tool (vs similar tools), WHAT parameters are required, or WHAT the tool returns. Example: 'Create a bill in QuickBooks Online' does not distinguish it from create_expense or create_invoice.
No output schemas are documented for any tool. LLMs cannot determine what fields to expect or plan downstream tool calls. For example, get_company_info, list_accounts, and query should each document their return structure.
No error recovery guidance. Tools like delete_entity (DESTRUCTIVE) should document what happens on failure, how to undo, and what the agent should do next. No error classification (retryable vs user-fixable vs fatal) is provided in any tool.
delete_entity (DESTRUCTIVE) has no confirmation step or dry-run option. Agents make mistakes, destructive operations should require explicit user confirmation or return a confirmation request via MRTR. Current description provides no safety guidance.
WRITE and DESTRUCTIVE tools lack idempotency guidance. If an agent retries due to ambiguous failure, will create_invoice, create_bill, etc. produce duplicate records? Descriptions should clarify idempotency behavior or warn of side effects.
qbo_authenticate accepts authorization_code and realm_id as optional parameters. Best practice: if the server accepts OAuth tokens as tool parameters, credentials leak into logs and traces. Token management should be server-side and not expose tokens in tool parameters.
list_accounts accepts 'account_type' as a free-form string. If the API supports only specific types (e.g., 'Asset', 'Liability', 'Equity', 'Revenue', 'Expense'), these should be declared as an enum in the schema, not a free-form string, to guide the LLM.
Tools like get_report, query, and query_account_transactions likely need pagination parameters (limit, offset, next_cursor). No such parameters are visible in the provided schemas.
Tool composition issues: edit_journal_entry, edit_bill, edit_expense, edit_invoice, edit_sales_receipt, edit_deposit, edit_vendor_credit, edit_customer exist but lack documentation of which fields they accept or how they differ from create variants. This forces LLMs to guess at parameters.
Declare required vs optional parameters explicitly in schemas. Tools like create_journal_entry likely require certain fields (e.g., lines, date) but may have optional fields (e.g., memo). Use 'required: [...]' in JSON Schema.
Constrain free-form parameters with enums or regex patterns. For list_accounts, account_type should be an enum: ['Asset', 'Liability', 'Equity', 'Revenue', 'Expense', 'Other']. For query, document allowed fields and operators.
Add pagination support to list-returning tools. Schemas should include 'limit' (default 20, max 100) and 'offset' or 'cursor' parameters. Responses should include 'total' count and 'next_cursor' to enable continued fetching.
Document idempotency for write operations. For create_invoice, state: 'Idempotent if called multiple times with the same external_id. If no external_id is provided, repeated calls may create duplicate invoices.' Provide an external_id or similar deduplication field.
Move credential handling server-side. qbo_authenticate should not expose authorization_code or tokens as tool parameters. Instead, initiate OAuth flow internally and store credentials securely; tools should use implicit authentication.
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to the tool definitions in src/server.ts. Mark get_* and query tools with readOnlyHint: true. Mark delete_entity with destructiveHint: true. Mark create_* with idempotentHint: false unless deduplication is supported.
Clarify edit_* tool behavior. For each edit tool (edit_journal_entry, edit_bill, etc.), document: (1) which fields can be edited after creation? (2) which fields are immutable? (3) must you provide all fields or only changed ones? (4) does it support partial updates?
Add 'scope' declarations to tools. For example, get_company_info requires 'read:company', create_invoice requires 'write:sales', delete_entity requires 'write:delete'. This enables least-privilege agent configurations.
Test parameter naming consistency. If create_invoice expects 'customer_id', ensure get_customer returns 'customer_id' (not 'id' or 'customerId'). Verify all ID field names match across tools to enable seamless chaining.