Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@genpark-complex-financial-formula-audit-validator-skill Check if this balance sheet balances and redact any SSNs."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Arithmetic consistency checks for supplied financial statement data.
This checks supplied numbers and a simplified income-statement model. It does not extract PDFs, verify source authenticity, check accounting compliance, or provide an audit opinion. Monetary values must use consistent units; tolerance defaults to 0.5 of those units.
Python 3.9 or newer. The library and stdio MCP server have no runtime dependencies.
python -m pip install https://github.com/Alpha-Park/genpark-complex-financial-formula-audit-validator-skill/releases/download/v1.0.1/genpark_financial_audit-1.0.1-py3-none-any.whlPyPI publication is pending account setup. The intended PyPI project is genpark-financial-audit;
do not assume pip install genpark-financial-audit is available until the project is published.
Related MCP server: genpark-hybrid-bounding-box-ocr-table-reconstructor-skill
from genpark_financial_audit import FinancialFormulaAuditValidator
client = FinancialFormulaAuditValidator()
print(client.run_benchmark_financial_audit())After installing the wheel, configure your MCP client with the installed command:
{
"mcpServers": {
"genpark-financial-audit": {
"command": "genpark-financial-audit",
"args": []
}
}
}If the command is not on PATH, use its absolute path or python -m genpark_financial_audit
with the same interpreter where you installed the wheel.
The GitHub release also contains a .mcpb bundle for clients supporting desktop extensions.
That bundle requires a Python 3.9+ interpreter on PATH; it bundles the server source.
Available tools: audit_balance_sheet, audit_income_statement, audit_cross_footing, run_benchmark_financial_audit.
tools/list returns required arguments and JSON schemas.
Each MCP process holds its own state. Benchmark tools use isolated instances.
python -m unittest discover -s tests
python -m pip install mcp
python tests/check_mcp.py
python -m pip install build twine
python -m build
python -m twine check dist/*python mcp_server.py --test runs the deterministic example; it is not a protocol conformance test.
The MCP client check exercises initialize, tools/list, tools/call and ping over stdio.
GitHub source and release artifacts are the primary distribution until PyPI is configured. Registry submissions are tracked separately; a manifest is not proof of registry acceptance. See PUBLISHING.md for the repeatable PyPI workflow.
MIT license. Maintained by GenPark.
audit balance sheet
| Name | Required | Description | Default |
|---|---|---|---|
| balance_sheet_dict | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden, and it discloses nothing: not whether the check is a read-only validation, what rules are applied, what errors or flags result, or what happens with malformed input. An agent cannot predict behavior at all.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-word phrase is terse but this is under-specification rather than conciseness; there is no front-loaded purpose or scope to anchor the call. Brevity here costs rather than earns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a nested-object parameter with zero schema coverage, no annotations, and no output schema, the description needs to explain input shape and audit behavior and does none of it. It is wholly inadequate for even the minimum viable call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter is a nested object keyed by string with numeric values, which is entirely undocumented. The description adds no meaning about expected keys (e.g., account names, amounts) or structure, leaving the agent unable to construct a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Audit balance sheet' is a bare restatement of the tool name with no elaboration. It identifies a verb and resource, but gives no hint of what an 'audit' checks, what the balance_sheet_dict should contain, or how it differs from siblings like audit_income_statement or audit_cross_footing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to use this tool versus audit_income_statement, audit_cross_footing, or run_benchmark_financial_audit. No prerequisites, no input format expectations, no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates that row sums and column sums align (footing and cross-footing). matrix_rows is a 2D float list where the last column is row total and last row is col total.
| Name | Required | Description | Default |
|---|---|---|---|
| matrix_rows | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It usefully discloses the matrix contract (last column = row total, last row = column total), but says nothing about failure behavior, tolerance thresholds, or what the caller receives on a mismatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the purpose comes first, the input contract second, with no filler. Slightly telegraphic but front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the input contract but never indicates the return shape (boolean, list of mismatched cells, error) or how failures are reported. Adequate but leaves a real gap for the calling agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by defining matrix_rows as a 2D float list with the total column and total row in fixed positions. It stops short of clarifying whether the corner cell is included or whether the totals are validated as data, leaving minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (validates) and a specific check (row sums/column sums alignment, footing and cross-footing), so an agent can tell it is a numeric consistency validator. It does not explicitly distinguish itself from the audit siblings, which is the only gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to prefer this over audit_balance_sheet, audit_income_statement, or run_benchmark_financial_audit, nor any prerequisites. Usage is only inferable from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
audit income statement
| Name | Required | Description | Default |
|---|---|---|---|
| income_stmt_dict | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. It doesn't state whether this is a read-only operation, what output to expect, whether it modifies data, or any error conditions. For a tool that likely performs complex financial analysis, this is severely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse at just three words, which fails to provide necessary information rather than being efficiently concise. It is essentially a tautology that adds no value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of financial auditing, nested object parameter, lack of output schema, and no annotations, the description is completely incomplete. It provides no information about the audit process, expected inputs, outputs, or how it relates to other financial audit tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'income_stmt_dict' with 0% description coverage. The description doesn't explain what this dictionary should contain, its expected structure, or any constraints. While the parameter name is somewhat self-explanatory, the tool provides no additional semantic guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description simply restates the tool name without adding any detail about what auditing an income statement entails, what checks are performed, or what compliance standards are applied. It doesn't distinguish this tool from sibling tools like audit_balance_sheet, leaving the user guessing about its specific functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are no guidelines for when to use this tool versus alternatives such as audit_balance_sheet, audit_cross_footing, or run_benchmark_financial_audit. The description provides zero context about appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run benchmark financial audit
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It reveals nothing about what the benchmark audits, what data source is used, whether it's read-only or mutating, or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It's very short — only four words — but that's under-specification, not conciseness. The single phrase is front-loaded but leaves the agent with nothing actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no annotations and no output schema, the description is the only source of information, and it provides none. An agent cannot know what this does, when to call it, or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so there are no parameter semantics to document. Baseline 4 applies for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name as a lowercase phrase, providing no additional specificity. It doesn't clearly distinguish from siblings like audit_balance_sheet or audit_income_statement — 'financial audit' is too broad to separate it from those targeted audits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no context, no alternatives mentioned. With siblings performing specific audits, an agent has no basis for choosing this tool over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.1audit_balance_sheetaudit_cross_footingaudit_income_statementrun_benchmark_financial_auditScored across 4 tools
Balance sheet, income statement, and cross-footing audits are clearly distinct targets. run_benchmark_financial_audit is a meta/benchmark tool that could be confused with the specific audits, but its description separates it adequately.
Three tools use the audit_ prefix and one uses run_benchmark_, all in snake_case with a verb_noun structure. The verb choice deviates slightly but the pattern remains readable and predictable.
Four tools is well-scoped for a focused financial audit validator, with each tool targeting a distinct audit operation. It is neither bloated nor trivially thin for the stated purpose.
The set covers balance sheet, income statement, and cross-footing checks, but omits other core financial statements such as cash flow and equity/retained earnings. The benchmark tool is meta-level rather than filling a domain gap.
Messy spreadsheets in, clean checkable tables out. Every result carries its arithmetic proof.
Deterministic signed verification of numeric & financial claims for AI agents & spreadsheets.
Primary-source SEC filing intelligence and financial/disclosure reconciliation for AI agents.
Structured financial modeling for AI agents: build, version, audit models, export to Excel.
