OpenAccountants

Share this with OpenAccountants

share_with_openaccountants

Destructive

Only when the user asks: sends their feedback, or their request for a person to check or do the work, to OpenAccountants. Two modes. (1) note: an anonymized note about the guidance (a gap, a workaround you needed, or via skill_slug a bug in a specific skill). Anonymize hard: no names, amounts, or PII. (2) request_review: true: the user wants a person at OpenAccountants to check or do the work. Typical requests: 'can an accountant check this?', 'can someone file this for me?', 'can someone do this for me?', 'I want an accountant', 'can I talk to a person?'. A question about whether your own answer is right is not such a request; re-check it yourself. Also requires working_paper (complete), jurisdiction, scenario, and contact_email. The request is saved with OpenAccountants and the team is notified; the response returns an OpenAccountants booking link. The call is free. The work itself is paid: OpenAccountants does it through its accountants, with what is done and the fee agreed on the call before anything starts. Never describe the work itself as free. Call at most once per user request; not as a routine closing step.

Input Schema

Name	Required	Description
`note`	Yes	Anonymized improvement note: what the guidance covered vs what you added or worked around and why, or a bug in a specific skill. No names, amounts, or PII.
`scenario`	No	Review only: brief description of the situation to review.
`tax_year`	No	Review only: tax year, if relevant.
`skill_slug`	No	Optional: set when the note is feedback about a SPECIFIC skill, by its slug (e.g. 'us-sales-tax'). Replaces the old submit_feedback.
`contact_name`	No	Review only: the user's name.
`jurisdiction`	No	Review only: ISO code or slug for the user's tax jurisdiction (e.g. 'US-CA').
`contact_email`	No	Review only, REQUIRED when request_review: the user's email, so OpenAccountants can reply. Ask for it first.
`working_paper`	No	Review only: the COMPLETE working paper markdown — every line item and assumption, not a summary.
`request_review`	No	true only when the user has asked for a person (an accountant or OpenAccountants) to check their result, file it or do the work. Requires working_paper + jurisdiction + scenario + contact_email. Omit/false = just the note.

Output Schema

Name	Required	Description	Default
`status`	No
`message`	No
`booking_url`	No
`note_recorded`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / skill_slug / description

Previous value: -"Optional: set when the note is feedback about a SPECIFIC Guide, by its slug (e.g. 'us-sales-tax'). Replaces the old submit_feedback."New value: +"Optional: set when the note is feedback about a SPECIFIC skill, by its slug (e.g. 'us-sales-tax'). Replaces the old submit_feedback."

Changed3 schema fields changedOct 8, 2026

changedInput schema / properties / contact_email / description

Previous value: -"Review only, REQUIRED when request_review: the user's email. Ask for it first."New value: +"Review only, REQUIRED when request_review: the user's email, so OpenAccountants can reply. Ask for it first."

changedInput schema / properties / request_review / description

Previous value: -"true only when the user has asked for a licensed accountant to review their figures. Requires working_paper + jurisdiction + scenario + contact_email. Omit/false = just the note."New value: +"true only when the user has asked for a person (an accountant or OpenAccountants) to check their result, file it or do the work. Requires working_paper + jurisdiction + scenario + contact_email. Omit/false = just the note."

changedInput schema / properties / skill_slug / description

Previous value: -"Optional: set when the note is feedback about a SPECIFIC skill (e.g. 'us-sales-tax'). Replaces the old submit_feedback."New value: +"Optional: set when the note is feedback about a SPECIFIC Guide, by its slug (e.g. 'us-sales-tax'). Replaces the old submit_feedback."

Changed2 schema fields changedJul 30, 2026

changedInput schema / properties / note / description

Previous value: -"Anonymized improvement note/DIFF: what the guidance covered vs what you ADDED or worked around and WHY, OR a bug in a specific skill. No names, amounts, or PII. Send whenever the user agrees to help improve."New value: +"Anonymized improvement note: what the guidance covered vs what you added or worked around and why, or a bug in a specific skill. No names, amounts, or PII."

changedInput schema / properties / request_review / description

Previous value: -"true ONLY if the user WANTS a licensed Partner to review their actual figures. Never mandatory. Requires working_paper + jurisdiction + scenario + contact_email. Omit/false = just the note."New value: +"true only when the user has asked for a licensed accountant to review their figures. Requires working_paper + jurisdiction + scenario + contact_email. Omit/false = just the note."

AddedJul 13, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, non-idempotent, closed-world, and the description adds substantial context beyond them: anonymization requirements, that the request is saved and the team notified, that a booking link is returned, and the free-call/paid-work distinction. It does not, however, reconcile the closed-world annotation with a tool that transmits data to an external team, so it falls short of full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the triggering condition and the two-mode structure, and every sentence carries operational weight. It is dense and on the long side for a single tool, which keeps it just short of ideal.

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

Completeness5/5

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

Covers triggers, exclusions, mode semantics, required supporting data, external effect, cost model, and call-frequency limits. An output schema exists and the description defers to it while still noting the booking link, so nothing an agent needs is missing.

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 above that by explaining the mode gating (which parameters are 'Review only' and jointly required for request_review) and by emphasizing the anonymization constraint on `note`. It largely restates rather than expanding the schema's per-field text.

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+resource: sending the user's feedback or a request-for-human to OpenAccountants. It names its two modes (`note` and `request_review`) and its trigger phrases, so it is unmistakable against siblings like get_quote or start_help.

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 the explicit gating condition ('Only when the user asks'), lists the typical utterances that qualify, and explicitly excludes a near-miss ('a question about whether your own answer is right is not such a request'). It also bounds frequency ('at most once per user request; not as a routine closing step').

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

All OpenAccountants tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.