基于同一引擎构建的两个工具。选择适合你的入口。
了解你是否准备好申请商业贷款——免费，仅需 5 分钟。
上传你的银行对账单和信用报告。获取 0-100 分的准备度评分，了解哪些因素对你不利，学习如何改进，找出你有资格申请的贷款，并获取一份银行所需材料清单。
无需账户。无需费用。没有推销。
你将获得：
基于银行评估标准的准备度评分
用通俗易懂的语言说明哪些因素对你有帮助，哪些因素对你不利
适合你情况的贷款类型（SBA 贷款、信用额度、设备融资等）
在申请前需要优先解决的问题清单
与银行经理会面时所需携带的材料清单
如何使用：
点击上方链接
点击 "See a Demo Score" 查看其工作原理
在侧边栏切换到 "Upload My Files"
上传你的银行对账单、信用报告或财务文档
查看你的评分和行动计划
Related MCP server: Sablier MCP Server
为你完成准备工作的投资组合仪表板。
搜索客户、调取资料、查看整个客户群的融资准备情况。相同的评分引擎，专为客户经理工作流打造——一个搜索栏即可获取任何客户的全貌。
你将获得：
包含所有客户搜索功能的投资组合视图
包含信用、现金、契约和准备度评分的客户资料
9 种分析工具：现金头寸、预测、营运资金、信用评估、契约监控、外汇风险、闲置现金、支付优化
与 Claude Desktop 集成的 MCP 服务器，用于人工智能驱动的分析
快速入门 (Claude Desktop)：
git clone https://github.com/GPBK-STUY/treasury-mcp-os.git ~/Desktop/treasury-mcp-os
bash ~/Desktop/treasury-mcp-os/setup.sh查看 QUICKSTART.md 获取完整设置说明。
一个分析引擎驱动一切。三个应用程序服务于不同的受众。
六大类别，每项评分 0-100：
类别 | 衡量指标 |
个人信用 | FICO 分数、信用卡使用率、还款记录、查询记录 |
企业信用 | Paydex 分数、经营年限、供应商付款速度、留置权 |
现金头寸 | 现金总额、账户数量、90 天预测 |
营运资金 | 流动比率、收款速度、现金周期、运营资金储备 |
现有债务 | 契约合规性、违约情况、预警 |
文档资料 | 已上传的关键文档类型 |
Cash Position Aggregator Credit Report Parser
Idle Cash Scanner Credit Position Assessor
Cash Flow Forecaster Covenant Monitor
Working Capital Analyzer FX Exposure Scanner
Payment Optimizer支持 CSV、Excel (.xlsx)、Word (.docx) 和 PDF 格式。通过扫描列标题自动检测内容类型，并映射到正确的数据格式。
git clone https://github.com/GPBK-STUY/treasury-mcp-os.git
cd treasury-mcp-os
pip install -r requirements.txt
streamlit run smb_app.py # Business owner app
streamlit run rm_dashboard.py # RM dashboard
streamlit run app.py # Full dashboardtreasury-mcp-os/
├── smb_app.py ← Business owner app
├── rm_dashboard.py ← RM portfolio dashboard
├── app.py ← Full dashboard (all 11 pages)
├── server.py ← MCP server for Claude Desktop
├── tools/ ← Shared analysis engine (9 tools)
├── sample_data/ ← Demo data (Apex Manufacturing Corp)
├── portfolio_data/ ← Multi-client data for RM dashboard
└── setup.sh ← One-command Claude Desktop installer由 Grant Page 构建——拥有 5 年商业银行从业经验，致力于打造本应早就存在的工具。
MIT
Analyze working capital health. All values in same currency (USD).
| Name | Required | Description | Default |
|---|---|---|---|
| current_assets | Yes | ||
| current_liabilities | Yes | ||
| annual_revenue | Yes | ||
| accounts_receivable | Yes | ||
| accounts_payable | Yes | ||
| annual_cogs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but reveals almost nothing about the analysis behavior. It does not specify what metrics are calculated (current ratio, cash conversion cycle, etc.), whether the operation is read-only, or what the return format looks like. Only the currency constraint is disclosed.
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 two sentences are efficient and front-loaded with the primary purpose stated first. However, given the complexity (6 undocumented financial parameters, no output schema), the description is inappropriately brief rather than truly concise—key information is missing.
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?
With 6 required parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It omits what analysis is performed, what outputs are returned, and definitions for the financial metrics, leaving significant gaps for an AI agent to use the tool correctly.
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% (only titles, no descriptions), requiring the description to compensate. While it adds the critical constraint that 'All values in same currency (USD)', it fails to explain any of the 6 financial terms, their relationships to one another, or expected value formats beyond 'number'.
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?
States the core action ('Analyze') and resource ('working capital health') clearly enough for domain users. However, it fails to differentiate from close siblings like 'assess_credit_position' or 'get_cash_position', leaving ambiguity about when to select this specific financial analysis tool.
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?
Provides no guidance on when to use this tool versus alternatives like 'assess_credit_position' or 'forecast_cash_position'. The only constraint mentioned ('All values in same currency') is an input requirement, not a usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess combined credit + cash flow lending readiness. Integrates credit reports with cash position and covenant data to produce an overall credit rating, risk factors, lending capacity estimate, and cross-sell opportunities. Args: annual_gross_income (combined guarantor income for DTI calc, 0 to skip).
| Name | Required | Description | Default |
|---|---|---|---|
| annual_gross_income | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the computational synthesis performed and the outputs produced (credit rating, risk factors, lending capacity, cross-sell opportunities), but omits critical behavioral traits: whether this triggers live credit inquiries vs. cached data, persistence of results, or idempotency.
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?
Three efficiently structured sentences: purpose statement first, integration details second, and parameter documentation third. The 'Args:' inline documentation is slightly informal but appropriately concise given the single parameter and complete lack of schema descriptions. No wasted text.
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 no output schema, the description commendably lists expected return values (credit rating, risk factors, lending capacity, cross-sell opportunities). It also clarifies implicit inputs (external data sources). Minor gap: doesn't explain the impact of 'skipping' income calculation on output quality.
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%, leaving the description to carry full documentation load. It excellently compensates by explaining the parameter's semantic meaning ('combined guarantor income'), its computational purpose ('for DTI calc'), and control flow ('0 to skip')—adding complete semantic value beyond the bare 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?
Specific verb sequence ('Assess' + 'Integrates') and clear resource scope ('credit + cash flow lending readiness'). Explicitly distinguishes from siblings like parse_credit_report and get_cash_position by emphasizing the integration of multiple data sources (credit reports, cash position, covenant data) into a unified assessment.
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?
Provides clear contextual positioning by listing the specific data sources it synthesizes (credit reports, cash position, covenant data), implying this is the holistic assessment tool versus specialized alternatives. However, lacks explicit 'when not to use' or prerequisite guidance (e.g., whether parse_credit_report must be called first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forecast cash position using historical transaction patterns. Args: horizon_days (default 90, max 365).
| Name | Required | Description | Default |
|---|---|---|---|
| horizon_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the methodology (historical patterns) and max constraint (365 days), but omits output format, what happens with insufficient data, or whether results are cached/persisted.
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-sentence structure with purpose front-loaded. 'Args:' notation is slightly informal but efficient. No redundant text, though default value repeats schema information.
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 single parameter and lack of output schema, description covers core functionality but insufficient for full agent operation. Missing return value description and error conditions despite having siblings with potentially overlapping use cases.
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 has 0% description coverage. Description compensates partially by noting the max constraint (365) not present in schema, but only minimally explains semantics of horizon_days (doesn't clarify it represents the forecast time window into the future).
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?
Clear verb (Forecast) + resource (cash position) + methodology (historical transaction patterns). 'Forecast' implicitly distinguishes from sibling get_cash_position (current state), though explicit sibling differentiation would strengthen this further.
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 guidance on when to use this tool versus siblings like get_cash_position or analyze_working_capital. No mention of prerequisites for historical data or when forecasting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregated cash position across all bank accounts. Returns balances by currency and account type.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It explains aggregation behavior ('aggregated', 'by currency and account type') but omits critical behavioral traits: read-only safety confirmation, data freshness (real-time vs. end-of-day), authentication requirements for banking data, and error conditions.
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 efficient sentences with zero waste. The first states the action and scope; the second describes the return structure. Information is front-loaded and appropriately sized for a parameter-less tool.
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 zero parameters and no output schema, the description adequately explains the return value structure ('balances by currency and account type'). However, for a financial data tool accessing bank accounts, it could note the read-only nature or data scope to achieve full completeness.
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 input schema contains zero parameters. According to the rubric, zero-parameter tools baseline at 4. The description appropriately requires no parameter clarification.
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 uses specific verbs ('Get') and resources ('cash position', 'bank accounts') and specifies the aggregation scope ('across all bank accounts'). However, it does not explicitly distinguish from the sibling tool 'forecast_cash_position' (current vs. future state) or 'scan_idle_balances' (comprehensive vs. targeted).
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?
The description provides no guidance on when to use this tool versus alternatives, particularly 'forecast_cash_position' or 'scan_idle_balances'. It omits prerequisites (e.g., connected bank accounts) and conditions where this retrieval might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor debt covenant compliance across credit facilities. Flags breaches and warnings (within 10% of threshold).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It successfully discloses the warning threshold logic ('within 10% of threshold'), explaining how warnings differ from breaches. Missing side effects, idempotency, or data persistence details.
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 sentences, zero waste. First sentence establishes purpose and scope; second sentence details specific behaviors (breaches vs warnings). Perfectly front-loaded.
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?
Adequate for a zero-parameter monitoring tool. Explains scope (across facilities) and logic (10% buffer). Would benefit from noting whether this requires pre-existing facility setup or returns real-time vs cached data.
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?
Zero parameters baseline score applies. Schema coverage is vacuously 100%. Description wisely avoids inventing parameter documentation where none exist, focusing instead on behavioral semantics.
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?
Clear specific verb ('Monitor') + resource ('debt covenant compliance'). Explicitly scopes to 'credit facilities' and distinguishes from sibling 'assess_credit_position' by focusing specifically on covenant thresholds rather than general creditworthiness.
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?
Describes what the tool does (flags breaches/warnings), implying use for compliance checking, but lacks explicit 'when to use vs alternatives' guidance. Does not clarify relationship to 'assess_credit_position' or prerequisites like configured facilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find early-payment discounts that beat cost of capital. Args: available_cash budget (0 = show all opportunities).
| Name | Required | Description | Default |
|---|---|---|---|
| available_cash | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While it explains the business logic (discounts vs cost of capital), it fails to disclose operational traits: whether read-only, return format, side effects, or rate limits.
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?
Extremely concise two-sentence structure. Front-loaded with purpose statement; every word earns its place with no redundancy.
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?
Adequate for a single-parameter analysis tool: explains the parameter and core logic. However, lacking annotations or output schema, it should mention read-only status or return value hints to be complete.
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?
With 0% schema coverage and no parameter descriptions in the JSON schema, the description compensates by explaining 'available_cash' is a budget constraint and clarifying the semantics of the default value 0.
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?
States a specific action (Find), resource (early-payment discounts), and filtering logic (beat cost of capital) that distinguishes this from general working capital siblings. However, it doesn't explicitly map these distinctions to the sibling list.
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?
Provides only parameter documentation ('0 = show all opportunities') rather than tool selection guidance. No when-to-use/when-not-to-use, prerequisites, or sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse personal and business credit reports already on file. Extracts FICO scores, Paydex, utilization, payment history, derogatories, and public records from credit data pulled during the application process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It successfully establishes data source constraints ('already on file', 'pulled during application') and read-only implications of 'parse'/'extracts', but omits safety confirmations, rate limits, or caching behavior that would fully compensate for missing annotations.
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 efficiently structured sentences with no redundancy. First sentence establishes operation and scope; second details specific extractions. Every word earns its place.
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?
Lists extracted fields which partially substitutes for missing output schema, but doesn't describe return structure, data formats, or error handling. Adequate for a zero-parameter tool but lacks completeness regarding output contract.
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?
Input schema has zero parameters (baseline 4). The description correctly implies no inputs are needed while conveying that reports must already exist in the system, effectively documenting the implicit prerequisite without contradicting the empty 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?
Clearly states the tool parses existing credit reports and specifies exact data points extracted (FICO, Paydex, utilization, etc.). Distinguishes scope by mentioning 'already on file' and 'pulled during application process', though it doesn't explicitly differentiate from sibling assess_credit_position.
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?
Provides implicit usage constraint through 'already on file', indicating prerequisite data must exist. However, lacks explicit when-to-use guidance versus siblings (e.g., when to parse raw data vs. assess credit position) and doesn't mention failure modes if no reports exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for unhedged FX exposures in vendor payables. Calculates Value at Risk and recommends hedging strategies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Implies read-only behavior through verbs 'scan', 'calculates', and 'recommends', and discloses analytical outputs (VaR, strategies). However, missing explicit safety declarations (read-only confirmation), scope limitations, or side effects. Does not contradict any annotations.
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 sentences, zero waste. First sentence establishes core action and domain; second sentence elaborates value-add outputs. Front-loaded with essential information, no filler text.
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 zero parameters and no output schema, description adequately covers functional scope by explaining inputs (implied: current vendor payables data) and outputs (VaR calculations, hedging recommendations). Sufficient for a simple analytical tool, though formal output schema would improve completeness.
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?
Input schema has zero parameters. Description correctly makes no parameter claims. With zero parameters, baseline is 4 as per rubric guidelines for empty parameter sets.
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?
Specific verb 'Scan' with clear resource 'unhedged FX exposures in vendor payables'. Second sentence adds capabilities (VaR calculation, hedging recommendations). Clearly distinguishes from sibling 'scan_idle_balances' by specifying FX domain vs. cash balances, and from other financial analysis tools like 'analyze_working_capital' by focusing specifically on foreign exchange risk.
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?
Provides implied usage through specific domain context (vendor payables FX exposure), but lacks explicit guidance on when to use vs. alternatives like 'analyze_working_capital' (which may also touch payables) or 'optimize_payment_timing'. No mention of prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for idle cash that could earn higher yields. Args: operating_reserve_pct (default 0.20), target_yield_bps (default 450).
| Name | Required | Description | Default |
|---|---|---|---|
| operating_reserve_pct | No | ||
| target_yield_bps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While 'scan' implies a read-only analysis, the description does not confirm whether this tool merely reports opportunities or initiates actual yield optimization transactions. It also fails to describe the return format or data sources despite having no output schema.
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 efficiently structured with two short sentences. The first sentence front-loads the core purpose effectively. The second sentence listing arguments is concise but somewhat informal ('Args:'), which slightly detracts from professional clarity but remains readable.
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 two simple parameters and no output schema, the description covers the essential purpose and parameter defaults. However, it lacks explanation of return values (critical without an output schema) and operational details like rate limits or data scope, making it minimally viable but incomplete.
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%, requiring the description to compensate heavily. While it lists parameter names and defaults, it fails to explain semantics: what 'operating_reserve_pct' calculates (excluded liquid cash percentage?) or what 'target_yield_bps' represents (minimum basis points threshold?). The 'Args:' format is minimal documentation.
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 provides a specific verb ('Scan') and clear resource ('idle cash') with a distinct purpose ('earn higher yields'). It implicitly differentiates from siblings like get_cash_position by focusing on yield optimization opportunities rather than merely reporting balances, though it does not explicitly clarify when to use this versus analyze_working_capital.
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 guidance provided on when to use this tool versus alternatives like get_cash_position or analyze_working_capital. There are no 'when-to-use' conditions, prerequisites (e.g., account types needed), or explicit exclusions mentioned.
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.
v0.1.0analyze_working_capitalassess_credit_positionforecast_cash_positionget_cash_positionmonitor_debt_covenantsoptimize_payment_timingparse_credit_reportscan_fx_exposurescan_idle_balancesScored across 9 tools
Each tool has a clearly distinct purpose targeting specific financial analysis tasks, such as cash position forecasting, credit assessment, covenant monitoring, and FX exposure scanning. There is no overlap in functionality; for example, analyze_working_capital focuses on liquidity health, while assess_credit_position integrates credit and cash flow data, making misselection unlikely.
All tool names follow a consistent verb_noun pattern using snake_case, such as analyze_working_capital, forecast_cash_position, and monitor_debt_covenants. This uniformity makes the tool set predictable and easy to navigate, with no deviations in naming conventions.
With 9 tools, the server is well-scoped for treasury and financial management, covering key areas like cash analysis, credit, risk, and optimization. Each tool earns its place by addressing a specific need without redundancy, fitting the typical range of 3-15 tools for such a domain.
The tool set provides comprehensive coverage for treasury operations, including monitoring, forecasting, and optimization tasks. Minor gaps exist, such as the lack of tools for direct transaction execution or detailed reporting generation, but agents can likely work around these with the available analysis and scanning tools.
Personal finance for AI agents — onboard, import statements, categorize & budget over MCP.
MCP server for Modern Treasury — payment orders, transactions, counterparties and ledgers.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
MCP server for VC pitch-deck scoring, thesis-fit matching, and deal-flow management.
