de en es ja ko ru zh

finary-mcp

Name: finary-mcp
Author: adagues

by adagues

Overview Schema Source Related Servers Discussions Admin

Python

Local

finary-mcp

Finary를 위한 의도적으로 읽기 전용으로 설계된 Model Context Protocol 서버로, 비공식 finary-uapi 클라이언트를 기반으로 합니다.

[!WARNING] 이 프로젝트는 Finary와 독립적이며 Finary의 보증, 지원 또는 유지 관리를 받지 않습니다. finary-uapi를 통해 비공개적이고 문서화되지 않은 엔드포인트에 의존합니다. 두 프로젝트 중 어느 하나라도 예고 없이 동작이 중단될 수 있습니다. 금융, 세금, 법률 또는 투자 조언이 아닙니다.

안전 모델

finary-mcp는 의도적으로 범위를 좁힌 읽기 전용 어댑터입니다:

프로필, 조직, 기관, 포트폴리오 및 거래 조회만 노출합니다.
로그인, 계정 가져오기, 생성, 업데이트, 삭제, 이체, 거래 또는 일반 CLI 도구가 없습니다.
고정된 허용 목록(allowlist)에서 셸 없이 finary-uapi 명령을 구성합니다.
필터 값은 실행 전에 검증됩니다.
요청이 실패하면 업스트림 stdout/stderr를 반환하지 않습니다. 업스트림 로그인 흐름이 세션 자료를 출력할 수 있기 때문입니다.
상태 디렉터리는 명시적입니다(FINARY_MCP_STATE_DIR). 임의의 작업 디렉터리에서 토큰을 찾지 않습니다.

이를 통해 MCP를 통한 의도치 않은 쓰기를 줄입니다. 그러나 다른 프로세스가 세션 파일을 읽을 수 있다면 머신을 안전하게 만들지 못합니다. 신뢰하는 계정과 프로필에서만 서버를 실행하세요.

중요한 인증 주의사항

“읽기 전용”은 Finary 포트폴리오 데이터를 의미합니다. finary-uapi는 요청 전에 Clerk 세션을 갱신하고 jwt.json을 재작성할 수 있습니다. 따라서 MCP 도구가 Finary 데이터를 변경하지 않더라도 개인 상태 디렉터리는 로컬 서비스 계정이 계속해서 쓸 수 있어야 합니다. 서버는 해당 파일, 쿠키 또는 하위 프로세스 진단 정보를 절대 반환하지 않습니다.

finary-uapi는 또한 fuzzywuzzy를 전이적 GPL-2.0 의존성으로 가져옵니다. 의도한 배포 또는 운영 방식에 대해 업스트림 의존성 그래프와 라이선스 영향을 검토하세요.

Related MCP server: monarch

사전 요구 사항

Python 3.10 이상.
finary-uapi로 이미 생성된 로컬 Finary 세션.
jwt.json과 localCookiesMozilla.txt를 모두 포함하는 개인 디렉터리. 디렉터리는 0700 모드, 파일은 0600 모드여야 합니다.

서버는 Google OAuth를 자체적으로 지원하지 않습니다. 로컬 세션을 생성하거나 갱신하려면 finary-uapi가 지원하는 인증 프로세스를 따르세요. 비밀번호, TOTP 코드, JWT, 쿠키 내보내기 파일 또는 세션 파일을 에이전트, 저장소, 이슈 트래커 또는 채팅에 절대 보내지 마세요.

설치

python -m venv .venv
. .venv/bin/activate
pip install finary-mcp

체크아웃에서 개발하는 경우:

pip install -e '.[dev]'
pytest -q

MCP 호스트 구성

FINARY_MCP_STATE_DIR을 Finary 세션이 저장된 디렉터리로 설정하세요. finary-uapi가 별도의 가상 환경에 설치된 경우 FINARY_UAPI_PYTHON을 해당 환경의 Python 실행 파일로 설정하세요.

일반적인 stdio 구성 예시:

{
  "mcpServers": {
    "finary": {
      "command": "/path/to/finary-mcp/.venv/bin/finary-mcp",
      "env": {
        "FINARY_MCP_STATE_DIR": "/private/path/to/finary-state",
        "FINARY_UAPI_PYTHON": "/path/to/finary-uapi/.venv/bin/python"
      }
    }
  }
}

절대 경로를 사용하세요. 상태 디렉터리는 개인 데이터이므로 절대 커밋해서는 안 됩니다. 제공된 .gitignore는 알려진 세션 파일을 제외합니다.

Hermes Agent 예시

mcp_servers:
  finary:
    command: /path/to/finary-mcp/.venv/bin/finary-mcp
    env:
      FINARY_MCP_STATE_DIR: /private/path/to/finary-state
      FINARY_UAPI_PYTHON: /path/to/finary-uapi/.venv/bin/python
    tools:
      include:
        - finary_me
        - finary_organizations
        - finary_institution_connections
        - finary_portfolio
        - finary_transactions

자격 증명을 공개 구성 파일에 복사하지 말고 Hermes의 MCP/구성 워크플로를 통해 이 구성을 추가하세요. 서버를 추가한 후 도구 검색이 다시 실행되도록 Hermes 프로세스를 다시 시작하세요.

도구

Tool	읽기 전용 목적
`finary_me`	인증된 프로필을 읽습니다.
`finary_organizations`	접근 가능한 Finary 조직을 나열합니다.
`finary_institution_connections`	금융 기관 연결을 나열합니다.
`finary_portfolio`	허용된 포트폴리오 클래스를 읽습니다: 투자, 증권, 암호화폐, 유로 펀드(fonds euro), SCPI, 부동산 또는 지주회사 계좌.
`finary_transactions`	페이지네이션과 날짜/계좌 필터를 사용하여 당좌, 투자 또는 신용 거래를 읽습니다.

의존성: `finary-uapi`

이 프로젝트는 Finary API의 재구현이 아니라 어댑터입니다. lasconic/finary _uapi 프로젝트의 finary-uapi CLI를 호출하며, 해당 패키지는 현재 pyproject.toml에 finary-uapi>=0.2.3,<0.3으로 선언되어 있습니다.

이 의존성은 문서화되지 않은 Finary 엔드포인트를 사용하고 로컬 세션을 유지합니다. 이 서버를 사용하기 전에 해당 소스와 라이선스를 검토하세요. 업스트림 업그레이드가 필요하면 먼저 별도의 환경에서 테스트한 후 여기에 호환되는 버전을 고정하세요.

개발

pytest -q
python -m build

테스트는 실제 Finary 계정을 사용하지 않으며 세션 파일을 생성해서는 안 됩니다. 게시 전에 스테이징된 파일에서 jwt.json, localCookiesMozilla.txt, 자격 증명, 이메일, 쿠키 및 토큰을 검사하세요.

라이선스

MIT. LICENSE를 참조하세요.

Available Tools

5 tools

finary_institution_connectionsA

List connected financial institutions and their connection status.

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the action. It does not mention read-only nature, response format, pagination, or any caveats about connection status semantics.

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, concise sentence with no filler. The key action and object are front-loaded, making it easy to scan.

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 listing tool, the description is reasonably complete. However, without an output schema or any mention of response fields (e.g., what 'status' values look like), an agent lacks some context about the expected result.

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 the baseline is 4. The description correctly adds no unnecessary parameter detail, and there is nothing to compensate for since the schema is trivially complete.

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 ('List') and a clear resource ('connected financial institutions') along with a relevant detail ('connection status'). It clearly distinguishes this tool from siblings like finary_portfolio or finary_transactions by focusing on institution connections.

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?

The description provides no indication of when to use this tool versus alternatives, nor any exclusions or prerequisites. An agent is left to infer the use case from the name alone.

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

finary_meA

Read the authenticated Finary profile. Does not modify Finary.

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. It explicitly states 'Does not modify Finary', which is a key behavioral trait for a read operation. It does not mention return format or errors, but for a simple profile read this is acceptable. Adding 'Read' reinforces the non-destructive nature.

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 sentences, front-loaded with the core action and a clear non-modification statement. No fluff or redundancy. 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 zero-parameter, read-only tool, the description covers the essential purpose and side-effect behavior. It does not explicitly state return data format (no output schema exists), but an agent can reasonably infer it returns the profile object. Minor gap, but adequate for this simplicity.

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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameters because none exist. Schema coverage is 100% vacuously, and no parameter documentation is required.

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 the verb 'Read' with a specific resource, 'authenticated Finary profile', and explicitly states it does not modify. This distinguishes it from sibling tools like finary_transactions or finary_portfolio without ambiguity. The purpose is clear and specific.

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?

The description indicates the tool retrieves the user's own Finary profile, which sets clear context for when it applies. However, it does not explicitly mention alternatives or conditions for when not to use it, though the resource is so distinct that usage is implied. Missing explicit routing to siblings, but adequate.

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

finary_organizationsB

List Finary organizations available to the authenticated user.

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/5

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. It only says 'List' and mentions 'authenticated user', which implies a read-only operation but does not state side effects, rate limits, response format, or any required authentication details. The lack of explicit behavioral context is a significant gap.

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, direct sentence with no redundant words. It is perfectly concise and front-loads the core action, making it efficient for an agent to parse.

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

Completeness2/5

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

Given the tool's simplicity (no parameters, no output schema), the description is minimal but lacks important context. It does not explain pagination, what an 'organization' entails, or how this relates to sibling tools. For a tool with no annotations, more behavioral and situational details are needed for complete understanding.

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 schema coverage is trivially 100%. The description adds nothing about parameters because none exist, but the baseline for zero-parameter tools is a 4, and the tool meets this baseline as there is nothing to clarify.

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 the function: 'List Finary organizations' with the scope 'available to the authenticated user.' The verb 'list' is specific and the resource is clear. It doesn't explicitly differentiate from sibling tools, but the name and context make the intent obvious, so it earns a 4.

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 on when to use this tool versus alternatives like finary_portfolio or finary_transactions. An agent is left to infer usage from the name and generic phrasing. There are no exclusions or specific scenarios mentioned, so this dimension is weakly addressed.

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

finary_portfolioB

Read a portfolio class: investments, securities, cryptos, fonds_euro, scpis, real_estates, or holdings_accounts.

Name	Required	Description	Default
`org_id`	No
`asset_type`	No		investments

TDQS

B3.4/5.0

Behavior2/5

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. It only states the verb 'Read', implicitly indicating a non-mutating operation, but it does not mention permissions, rate limits, return format, or any side effects. The list of asset types adds domain context but not behavioral transparency. This is a significant gap for a tool with zero annotation coverage.

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, well-structured sentence with no unnecessary words. The verb is front-loaded, and the enumeration of asset types is compact and informative. Every part earns its place.

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

Completeness2/5

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

Given there is no output schema and no annotations, the description should explain what the tool returns and any other usage context, but it does not. It omits any mention of the return structure, error handling, or the org_id parameter, which is essential to know when calling the tool. The enumeration of asset types covers only part of the invocation requirements, leaving the definition incomplete for an agent.

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 0%, so the description must compensate for parameter meaning. It explicitly lists the valid values for asset_type, which is useful and goes beyond the schema (where no descriptions exist). However, it completely ignores org_id, leaving its purpose and usage undocumented. The partial compensation leads to a middling score.

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 clearly states a specific action ('Read') applied to a well-defined resource ('portfolio class'), and enumerates all valid asset types (investments, securities, cryptos, etc.), making the tool's purpose unambiguous. It naturally distinguishes itself from sibling tools by naming a resource category not covered by any sibling (e.g., me, organizations, transactions).

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 usage for reading portfolio holdings of a given asset type, but it provides no explicit guidance on when to choose this tool over siblings. Since siblings are clearly different domains (me, organizations, connections, transactions), the context is somewhat clear, but the description does not explicitly state scenarios or exclusions, so it remains at the 'implied' level.

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

finary_transactionsB

Read transactions for checking, investment, or credit accounts with optional filters.

Name	Required	Description	Default
`page`	No
`query`	No
`marked`	No
`account`	No
`perpage`	No
`end_date`	No
`start_date`	No
`institution`	No
`account_type`	Yes

TDQS

B3.3/5.0

Behavior2/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. It only states 'read', which implies a non-mutating operation, but it does not disclose pagination semantics, filter behavior, response structure, or any side effects. For a tool with 9 parameters, this is insufficient behavioral disclosure.

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

Conciseness3/5

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

The description is a single sentence, which is concise but arguably too sparse for a tool with 9 parameters. It front-loads the core purpose, but lacks structure to organize the various optional filters, making it under-specified rather than appropriately concise.

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

Completeness2/5

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

With 9 parameters, no output schema, and no annotations, the description is incomplete for an agent to call the tool correctly. It does not explain date formats, pagination behavior, query syntax, or how filters interact, leaving too much to guesswork.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It only generically mentions 'optional filters' and names account types, which maps loosely to the 'account_type' parameter, but it does not explain any of the other parameters (page, query, marked, account, perpage, dates, institution). The added value over the raw schema is minimal.

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 clearly states the verb 'read', the resource 'transactions', and scopes to specific account types (checking, investment, credit). This distinguishes it from sibling tools that deal with user, org, connections, and portfolio data, making the purpose unambiguous.

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?

The description clearly implies this is the tool for transaction data, and since no sibling tool covers transactions, the usage context is evident. It does not explicitly mention alternatives, but given the sibling set, the division of responsibility is clear enough.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Aug 27, 2026
- First observedfinary_institution_connections
- First observedfinary_me
- First observedfinary_organizations
- First observedfinary_portfolio
- First observedfinary_transactions

Deploy Server

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

TDQS

A3.8/5.0

Scored 2026-08-27 01:00 across 5 tools

Disambiguation5/5

Each tool addresses a clearly distinct domain: user profile, organizations, institution connections, portfolio classes, and transactions. No overlap in purpose, and the descriptions make the boundaries obvious.

Naming Consistency5/5

All tools use a consistent 'finary_' prefix followed by a descriptive noun (me, organizations, institution_connections, portfolio, transactions). The naming pattern is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a read-only financial data API. Each tool covers a major data category without redundancy, and the count is neither sparse nor bloated.

Completeness4/5

The surface covers the core read operations for a personal finance platform: user, orgs, connections, portfolio, and transactions. Minor gaps exist, such as no detailed per-asset breakdown beyond portfolio class, but the essential workflows are supported.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Related MCP Connectors

FinchOAuth
ch.fjnch
Read-only access to your Finch finances: accounts, transactions, spending, net worth, goals.
Finance
1
https://api.fjnch.ch/mcp
Fillfolio MCPOAuth
com.fillfolio
Read-only Fillfolio portfolios, holdings, cash, liabilities, activity, spending and budgets.
Finance
1
https://fillfolio.com/api/mcp
Genie Expense TrackerOAuth
io.github.osamaadam
Read-only access to Genie accounts, transactions, investments, and financial summaries.
Finance
1
https://genie-mobile.duckdns.org/mcp
Synci AOAuth
io.synci
Read-only access to your bank, investment, and crypto accounts: balances, transactions, holdings.
Finance
52
https://api.synci.io/mcp

Related MCP Servers

questrade-mcp
Finance Research & Data
agustinsacco
A
license
B
quality
C
maintenance
Enables read-only access to Questrade accounts, portfolios, market data, transactions, technical analysis, and order history through MCP.
Updated 2 months ago (2026-09-15 17:57 UTC)
11
MIT
monarch
Finance
simplemind-dev
A
license
Not graded
quality
A
maintenance
Enables read-only access to Monarch Money financial data, including accounts, transactions, cash flow, spending, and income, via MCP, with secure local credential storage.
Updated a month ago (2026-10-03 16:00 UTC)
1
MIT
Fillfolio MCPofficial
Finance Data Platforms
fillfolio
A
license
Not graded
quality
B
maintenance
Enables read-only access to a Fillfolio account's normalized portfolio data, including net worth, holdings with cost basis, cash and liabilities, activity, and exact asset details, plus optional bank spending summaries, transactions, and budgets for eligible accounts. Clients can query stored data only — they cannot trade, move money, modify holdings, or access credentials.
Updated 15 days ago (2026-10-17 08:50 UTC)
9 npm
MIT
LunchMoney MCP Server
Finance Cryptocurrency
Margaux0469
A
license
Not graded
quality
A
maintenance
Enables AI assistants and other MCP clients to access and manage personal finance data, including transactions, categories, tags, budgets, recurring items, accounts, crypto, and balance history through the provider's API.
Updated 12 days ago (2026-10-20 05:03 UTC)
22 npm
MIT

finary-mcp

안전 모델

중요한 인증 주의사항

사전 요구 사항

설치

MCP 호스트 구성

Hermes Agent 예시

도구

의존성: finary-uapi

개발

라이선스

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Fillfolio MCPofficial

의존성: `finary-uapi`