finledger

by anikam13

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly defined role within its domain: expenses, investments, income, savings, or general ledger management. The distinct prefixes (expenses_, investments_, income_) prevent cross-domain confusion, and within domains, tools like spend vs. outstanding vs. runway vs. review_queue are semantically distinct. Even the less prefixed tools (reconcile, sync, accounts) are obviously separate from the financial queries.
Naming Consistency4/5
The dominant pattern is domain-prefix + descriptive noun (e.g., expenses_spend, investments_balances, income_summary), which is highly consistent. However, a few tools like reconcile, sync, accounts, and savings_rate do not follow the prefix scheme, creating minor inconsistency. The syntax is all snake_case with no verb conjugations, so the deviation is not jarring.
Tool Count4/5
Eighteen tools is on the higher end of typical MCP servers, but the breadth of the domain—expenses, investments, income, savings, notes, accounts, sync—justifies the count. Each tool addresses a specific financial question or action, and none feel redundant. The size is slightly above the ideal 3-15 range but well within the acceptable limit for a comprehensive financial ledger service.
Completeness4/5
The tool surface covers the core lifecycle of financial data aggregation: reading balances, transactions, and summaries, plus actions like reconciliation and decision resolution. There are minor gaps, such as no direct way to create or edit transactions or notes, but these are likely handled externally or intentionally read-only. The inclusion of sync and review queues ensures operational completeness for the stated purpose.
Average 3.1/5 across 18 of 18 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/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 of disclosing behavior. It fails to mention even basic traits such as whether the tool returns a list, how results are ordered, whether partial date ranges matter, or if there are any limits. The phrase 'in a window' only hints at a date range, but no further behavior is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is technically concise, but it is under-specified rather than efficiently informative. The sentence wastes no words, yet it also fails to convey essential meaning, so it does not earn its place. It is too short to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a description that provides almost no context. For a tool that likely returns investment transactions, the description lacks critical details like the nature of the activity, the response format, pagination, or any distinctions from sibling tools. It is completely inadequate for an agent to understand or use the tool correctly.
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 100%—both 'start' and 'end' are documented with their defaults and inclusivity. The description adds no additional meaning beyond the schema, which already specifies date types and defaults. Therefore, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Investment activity in a window' is vague and does not clearly state what the tool does. While the name implies transactions, the description uses the ambiguous noun 'activity' without specifying that it lists transactions or what form the output takes. It does not distinguish itself from siblings like investments_balances, investments_holdings, or investments_summary, so an agent cannot tell what this tool uniquely provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus its siblings. The description offers no conditions, exclusions, or alternatives. Given the many investment-related sibling tools, the absence of any routing information makes it impossible for an agent to choose this tool correctly based on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 does not state whether the tool is read-only, has side effects, or what the output format is. The only hint is that it involves 'annualized cost', but it never clarifies the tool's behavior or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and concise in length, but it is not structured to convey the tool's function. It lacks an action verb and does not front-load the purpose. The sentence reads as a definition of recurring charges rather than a tool description, so it fails to be useful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is the only source of guidance. It is incomplete because it does not state what the tool returns or how an agent should invoke it. An agent has no idea what to expect from this tool, making it inadequate for even a simple call.
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 the empty input schema fully covers parameter requirements. Per the calibration baseline for zero parameters, a 4 is appropriate; the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lacks a verb and does not state what action the tool performs. It describes a category of charges ('Charges repeating...') rather than an operation such as 'list' or 'retrieve'. This is more than a tautology but still vague; an agent cannot tell whether the tool returns recurring expenses, creates them, or computes annualized costs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings like expenses_spend, expenses_outstanding, or reconcile. No context, prerequisites, or exclusions are provided. The description gives no hint of how it differs from its peers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior itself. It only states 'Individual pay statements' without indicating read-only nature, result format, pagination, or any side effects. This is essentially no behavioral transparency, failing the minimal disclosure expected for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It lacks a verb and clear scope, making the brevity ineffective. Every sentence should earn its place; this one states the obvious but not enough.
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 no output schema, no annotations, and only two optional parameters, the description still leaves critical ambiguities: what constitutes a 'pay statement', whether results are aggregated, and what the response looks like. An agent cannot fully determine the tool's behavior from this description.
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 coverage is 100%: both parameters (start and end) have clear descriptions (ISO date, inclusive, defaults). The tool description adds no extra meaning beyond the schema, so the baseline score of 3 applies despite the thin description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('pay statements') and a timeframe ('in a window'), but it omits a clear verb (e.g., 'list', 'retrieve') and does not distinguish from sibling tools like income_summary. The phrase 'in a window' is vague without specifying the range semantics beyond what the parameters imply.
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 guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or scenarios where another tool (e.g., income_summary) would be more appropriate, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. It only describes the content (deductions and classifications) but says nothing about behavior such as sorting, aggregation, default year handling, read-only nature, or any side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. It communicates the core idea efficiently. However, it omits critical details, so it's concise but under-specified, not a model of well-structured completeness.
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?
For a tool with one optional parameter and no output schema, the description is insufficient. It doesn't clarify what 'year-to-date' means, how the optional year affects results, what the return format looks like, or any edge cases. An agent would likely need to trial-and-error to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'year', has zero schema description coverage. The tool description does not mention 'year' at all, so an agent cannot infer its purpose (e.g., filters by year, defaults to current year). The description fails to add any meaning beyond the schema's bare type definition.
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 states the tool lists payroll deductions year-to-date with classifications and employer contributions. It is specific about the resource (payroll deductions) and the verb (lists). It partially distinguishes from siblings like income_summary or income_statements by focusing on deductions and contributions, but doesn't explicitly name alternatives, so it's not a 5.
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 income_summary, income_statements, or other siblings. There is no mention of prerequisites, exclusions, or typical scenarios. The description implies it's about payroll deductions but lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 aggregation behavior and 'by default' but does not disclose the effect of the 'by_symbol' parameter, whether the output is a list or summary, or any other side effects. This is minimal and does not bridge the gap left by 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the core purpose and aggregation. However, its brevity sacrifices necessary detail, but for conciseness alone it is effective and well-structured.
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, no annotations, and a single parameter with no description, the tool description is insufficient for an agent to fully understand what to expect or how to use the parameter. It does not describe the return format (e.g., array of objects, fields), the effect of 'by_symbol', or differentiate clearly from sibling tools. This is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'by_symbol' is a boolean with no schema description (0% coverage). The tool description does not explain what this parameter does or how it modifies the output. It only mentions 'by default', which is vague and does not clarify the parameter's role. Since schema coverage is zero and the description adds nothing, this is a critical gap.
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 indicates it provides current holdings, aggregated by ticker across accounts by default. It distinguishes from balances (account-level) and transactions (activity) implicitly, but does not explicitly name alternatives or contrast with sibling tools like investments_balances. The verb 'holdings' plus aggregation context is specific enough.
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?
There is no guidance on when to use this tool versus alternatives. The phrase 'by default' hints at behavior but does not explain when to choose this over investments_balances or investments_summary. No exclusions or conditions are given, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It only states content ('Every connected account...') without revealing whether the operation is read-only, what exactly is returned (e.g., names, balances), or if any side effects exist. This is insufficient for an agent to anticipate the tool's behavior.
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?
The description is a single, brief sentence with no wasted words. It is concise and the key qualifier ('split by domain') is placed at the end, which is acceptable given its brevity. It could arguably carry more information, but as written it is efficient.
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 absence of an output schema and annotations, the description should clarify what the agent receives when calling this tool. It only says 'Every connected account' without specifying the structure or content of the response (e.g., list of account names, balances). This is a notable gap for a tool that is likely an overview endpoint, leaving the agent to guess the return format.
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 there is nothing to explain beyond what the schema already conveys (empty properties). The description does not need to add parameter semantics, and the baseline for a parameter-less tool is appropriately high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource (connected accounts) and a distinguishing attribute (split by domain), but it lacks a clear verb stating what the tool does (e.g., lists, retrieves, summarizes). This makes the action vague, though it does suggest an overview role compared to the more specific sibling tools.
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 given on when to use this tool versus the many specific siblings like expenses_spend or investments_balances. The description implies it provides a broad account view, but does not explicitly tell the agent when this is preferred over the domain-specific tools, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 output concept (balances + net burn) but does not disclose any side effects, return format, or requirements such as authentication or data freshness. There's no indication of whether this is a read-only operation, which is a notable gap given the lack of annotations.
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?
The description is extremely concise—a single noun phrase with no wasted words. It front-loads the two key outputs. However, it is so terse that it relies entirely on the reader's prior knowledge of financial runway concepts, and the lack of a verb makes it less clear as an instruction.
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 alone must explain what the tool returns and when to use it. It fails to clarify the meaning of 'runway' or how this differs from other expense tools. An agent cannot confidently determine the return format, the units of the burn, or whether 'spending-account' includes all cash accounts. It is under-specified for a tool with no required parameters and a single optional one.
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?
The schema documentation covers the 'months' parameter at 100% (it has a description and default value). The tool description adds no additional semantics beyond what the schema already provides, which matches the baseline score of 3. There is no extra context about how months affects the calculation or what values are appropriate.
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 identifies the resource as 'spending-account balances' and specifies the data type 'trailing monthly net burn', which distinguishes it from siblings like expenses_spend (which likely returns raw spending) and expenses_outstanding. However, it uses a noun phrase rather than an explicit verb like 'get' or 'calculate', leaving the action implied.
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?
There is no guidance on when to use this tool versus the many expense-related siblings. The description does not state that this aggregates balances and burn for runway analysis, nor does it contrast this with tools like expenses_spend or expenses_recurring. An agent would have to infer its purpose 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It states that confirmed decisions are preserved, implying re-processing may alter unconfirmed ones, but it does not disclose whether the operation is destructive, what side effects occur, whether it requires specific permissions, or what the return value looks like. The description is insufficient for an agent to understand the full impact of invoking this tool.
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 two short sentences with no wasted words. The core action is front-loaded, and the constraint about preserved decisions is stated clearly. This is an exemplary level of conciseness for a tool with no parameters.
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?
For a tool with no output schema and no annotations, the description should cover essential operational details. It only mentions the action and one behavioral constraint, leaving out crucial context such as what happens to non-confirmed payments, whether the operation is reversible, any prerequisites, or expected results. This incompleteness makes it difficult for an agent to call the tool with confidence.
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 the schema provides no meaningful information. The description doesn't need to explain parameters, but it also doesn't add any parameter-specific context. Given the 0-parameter baseline rule, a 4 is appropriate—the description is not lacking any necessary parameter semantics because there are none.
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 action (re-run the matcher) and the object (inbound payments), and adds that confirmed decisions are preserved. This distinguishes it from typical expense/income tools, though it does not explicitly name a sibling alternative. The verb and resource are specific enough for an agent to understand the purpose.
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?
There is no guidance on when to use this tool versus any alternative. The description does not mention any conditions, prerequisites, or scenarios where reconciliation is appropriate, nor does it reference any sibling tools. This is a clear absence of usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'Decisions survive re-runs', which hints at idempotency or persistence, but it does not explain the side effects of recording a decision, whether it is reversible, what permissions are needed, or what the response looks like. For a write operation with no annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, with the primary purpose in the first sentence. It front-loads the core action and then explains key parameter semantics. There is no fluff, and every sentence contributes. It could be slightly more structured, but it is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 params, no nested objects) and no output schema, the description covers essential usage logic for the disposition and charge_ids. However, it leaves questions about return values, error handling, and the exact meaning of the 'linked' disposition. With no annotations and no output schema, an agent may need more context to call this correctly in all scenarios.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning to charge_ids ('link reimbursements', empty means not a reimbursement) and clarifies the disposition enum (specifically charge_missing). It does not explicitly describe 'linked' but the context implies it. The description provides meaningful semantic information beyond the bare schema definition, covering most parameters adequately.
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 states a specific verb ('Record a decision') and a specific resource ('an inbound payment'), which is clear and unambiguous. It also hints at the distinction from sibling tools by focusing on decisions and reimbursements, but it does not explicitly differentiate from alternatives like reconcile or expenses_review_queue. The purpose is clear enough for an agent to understand what the tool does, but not why to choose it over siblings.
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 provides explicit guidance on parameter usage: 'Pass charge_ids to link reimbursements', 'Empty charge_ids = not a reimbursement', and 'disposition=charge_missing when it is a repayment but the parent charge(s) are not in the ledger.' This tells an agent when to set specific dispositions, which is valuable. However, it does not give guidance on when to use this tool versus alternatives (e.g., reconcile vs expenses_resolve). The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 output content, not whether the operation is read-only, the freshness of the data, or any error conditions. For a balance query, read-only behavior is implied but not explicit, and no other behavioral traits are disclosed.
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, tightly-worded sentence that communicates the essential output without any waste. It is front-loaded with the core purpose and includes the total as a secondary element. Every word contributes to understanding.
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 simple, parameterless tool, the description is reasonably complete. It indicates the result is a per-account breakdown plus a total, which implies a structured response. However, it doesn't specify the return format (e.g., JSON object vs. array) or any nuances like sorting or currency, but those are minor gaps given the 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?
The tool has zero parameters, so the schema is trivially covered. The baseline for 0 params is 4, and since the description doesn't need to explain parameters, there is no penalty. The description adds no parameter semantics because there are none to explain.
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 tool returns 'latest balance per investment account, plus the total.' It specifies the resource (investment balances) and the output (per-account and total), which distinguishes it from sibling tools like investments_transactions or investments_holdings. However, it doesn't explicitly differentiate itself from investments_summary, which might also return balances, so it falls short of a 5.
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 guidance on when to use this tool versus alternatives. It doesn't mention any conditions that would favor this over investments_summary or holdings, nor does it state any prerequisites or typical use cases. Agents are left to infer usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the result covers a trailing window and specifically that BUY/SELL are excluded from cash figures because they are internal transfers. This is useful, non-obvious behavioral context. It omits other potential behaviors (e.g., output format, defaults), but for a summary read tool this is reasonable.
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 sentences, no filler. The core purpose is front-loaded, and the crucial exclusion is explained clearly in the second sentence. Every word 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?
Although the tool is simple (one optional parameter, no output schema), the description fails to explain the months parameter at all, which is essential for correct invocation. It also does not describe the return format or whether there are any edge cases. The description is insufficient for an agent to use the tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, months, receives zero explanation in the description. The schema provides only a type of integer with no description, so an agent has no idea what 'months' does (period length? trailing window duration?). The description does not compensate for this 0% schema coverage, leaving the tool ambiguous to invoke.
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 what the tool reports: portfolio value and cash inflows/outflows over a trailing window. It also clarifies the exact scope by excluding BUY/SELL from cash figures. This is a specific and meaningful purpose, but it does not explicitly differentiate from sibling tools like investments_balances or investments_transactions, so it misses the top score.
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 when to use the tool (to see net cash movement and portfolio value) and explains a key exclusion (BUY/SELL). However, it gives no explicit guidance on when to prefer this over the many sibling investment tools, nor does it mention any conditions or alternatives. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states 'Idempotent and additive; never deletes,' which gives critical safety information. However, it doesn't mention potential side effects like network timeouts, data volume, or whether existing data is overwritten (though additive implies it isn't). This is adequate but not exhaustive.
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 exactly two sentences, front-loading the main purpose in the first sentence and key behavioral traits in the second. There is zero waste, and every word contributes to understanding the tool's function and safety.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional param, no output schema, no annotations), the description covers the core purpose and safety profile. However, it lacks any mention of when to invoke sync relative to other operations or what happens if the parameter is omitted. This is a noticeable gap that prevents full completeness.
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 100% because the only parameter (card_csv_path) is already described as 'Optional Ramp-style CSV to backfill.' The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
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 primary action: 'Pull every source into the store.' This is a specific verb and resource, making the tool's purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like reconcile, though the phrasing is distinctive enough that an agent can infer its role.
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. The description doesn't mention any prerequisites, conditions, or exclusions. An agent is left to guess whether sync should be run before reconcile or other expense tools, which is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations to rely on, so the description carries the full burden. It does not state whether this is a read-only operation, whether it requires any authentication, or what side effects (if any) exist. The phrasing 'inbound payments the matcher would not auto-match' implies a read/list operation, but this is not explicit. The description provides no behavioral details beyond the content, leaving the agent to guess about safety and effects.
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 sentences with zero waste. The first sentence states the tool's purpose and sorting, the second gives the immediate next action. All key information is front-loaded and no redundant details are present.
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?
The tool is simple (one optional parameter, no output schema), and the description provides the essential context: what the queue contains, how it's ordered, and what to do with the items. It does not describe the output structure, but that may be implied as a list of payments. Missing explicit read-only status is a minor gap but not critical for usage in a review context. Overall, the description covers the core needs despite omitting parameter details.
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?
The schema has a single parameter 'limit' with 0% description coverage and no description in the tool description. The description says nothing about 'limit'—its meaning, default, allowed values, or behavior. While 'limit' is a common term for pagination or result size, the tool description does not clarify it, and with no schema description the agent must infer. This is a gap given the description had room to explain it.
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 is specific: it identifies the tool as a queue of inbound payments that the matcher did not auto-match, sorted by best candidate. This clearly distinguishes it from the sibling expenses_resolve (the action tool) and other expense tools. The verb 'review' is implicit in 'queue' and the context is 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?
It explicitly states that these payments need a decision via expenses_resolve, telling the agent the intended follow-up action. This differentiates the tool from others and gives clear 'when to use' context. However, it does not explicitly discuss when NOT to use it (e.g., auto-matched payments are handled elsewhere), nor does it weigh alternatives like reconcile or expenses_spend. Still, the guidance is strong enough for a clear call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds a valuable nuance: net subtracts only CONFIRMED reimbursements, and unreviewed auto-matches are proposals, not facts. It also indicates a read-only nature by saying 'Returns...' but does not mention additional behaviors like pagination or performance. This is a meaningful disclosure for a query tool.
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 two crisp sentences. The first states the core purpose in five words, and the second adds a critical behavioral detail. There is no redundant wording, and the most important information is front-loaded.
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?
Given no output schema, the description explains the return values (gross, reimbursed, net) and the key nuance about confirmed reimbursements. It does not detail the output structure (e.g., array of groups) or expand on grouping, but for a simple query tool this is adequate. The sibling set is large, yet the description's focus on window+grouped is sufficient to disambiguate from most alternatives.
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?
The schema already describes start and end (ISO dates, inclusive) but leaves group_by undocumented. The description adds nothing beyond the schema; it mentions 'grouped' but does not explain the grouping options or their implications. With schema coverage at 67%, the description does not compensate for the missing group_by semantics, so a baseline of 3 is appropriate.
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 tool reports spend over a time window, grouped, with gross, reimbursed, and net figures. It is specific enough to distinguish from siblings like expenses_recurring or expenses_outstanding, though it does not explicitly name an alternative. The verb 'spend' and the scope 'window, grouped' make 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for grouped spend summaries over a date range, but it provides no exclusions or explicit alternatives. An agent might infer when to use it but is not told when not to use it or which sibling tool would be better for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It discloses that imputed_offset_ytd nets to zero and explains the semantics of net_pay_ytd (only banked amount) and payroll_savings_ytd. This is useful and transparent about data meaning, but it does not state that the tool is read-only or mention any constraints/permissions, which is a gap given the lack of annotations.
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 efficiently written, with the core purpose front-loaded first, followed by critical caveats. Every sentence carries meaningful information—no filler. The structure guides the reader from the general function to the specific calculation and the offset nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it explains key fields and the disposable calculation, it omits the meaning of the 'year' parameter and does not explicitly describe the full set of returned fields (though they are partially listed). It also lacks any comparison to sibling tools, leaving the agent uncertain about when to choose this over income_statements or income_contributions. Partial completeness only.
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?
The single parameter 'year' is completely undocumented in the schema (coverage 0%). The description does not mention 'year' at all, though the phrase 'year-to-date' might imply its purpose. This is insufficient: the agent is left to infer that 'year' filters the summary, and the description fails to compensate for the schema gap.
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 states a specific verb ('earnings from payroll') and the resource ('income_summary'). It clearly indicates the tool provides a year-to-date summary, and the mention of specific fields (net_pay_ytd, payroll_savings_ytd, imputed_offset_ytd) further distinguishes it from sibling tools like income_statements or income_contributions.
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?
Provides explicit guidance for using the output ('Use disposable_ytd = net_pay + payroll_savings when judging whether income covers spending'), which tells the agent how to interpret the data. However, it does not explicitly mention alternative tools or conditions for preferring this over income_statements or income_contributions, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states that only charges with at least one confirmed reimbursement are counted, and transparently explains the data limitation that excludes unpaid charges. This provides concrete behavioral context beyond the tool name.
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 well-structured sentences: the first immediately states the purpose, and the second explains the filtering rule. Every clause adds value without redundancy or wasted words.
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, no-output-schema tool, the description provides sufficient context: it tells the agent what data is returned (charges owed) and the rationale for exclusions. The only minor ambiguity is whether the output is a list or a sum, but the phrase 'charges' implies a list. An agent can confidently invoke this tool.
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 the description correctly adds nothing about them. Per the rubric, a zero-parameter tool receives a baseline 4, and the description appropriately avoids unnecessary parameter-related information.
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 states the tool lists charges still owed to the user, and clarifies the specific subset (shared charges with confirmed reimbursement) by explaining the exclusion of ordinary purchases. It gives a clear purpose but does not explicitly name sibling tools for other expense views.
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 when to use this tool (to see outstanding shared charges) and explains why certain charges are excluded due to data limitations. However, it does not mention alternative tools or provide explicit when-not-to-use scenarios beyond the exclusion logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses that the content is user-authored intent rather than derived figures. It also warns against treating the notes as data, preventing misuse. The behavior is simple (returns the notes), and the description sufficiently conveys the nature of what is returned.
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, dense sentence that front-loads the purpose ('Free-text goals, career plans, and constraints') and then immediately provides the crucial caveat about not treating them as data. No wasted words; every clause 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 simple, parameterless tool with no output schema, the description is essentially complete. It tells the agent what the tool returns and how to interpret it. One could argue it could explicitly state 'returns the full set of notes,' but the implication is already strong. The warning about non-data usage adds important context.
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 the schema provides no constraint information. Per the rubric, the baseline for 0 parameters is 4, and the description adds no parameter-related meaning because there are none to describe. The description does not need to compensate for parameter coverage gaps.
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 identifies the resource as user-written free-text notes about goals, career plans, and constraints. It distinguishes itself from the sibling financial tools by explicitly contrasting with ledger-derived figures, so an agent can tell it apart without opening schemas.
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 provides implicit usage guidance: these notes are qualitative intent, not quantitative data, so they should not be used for financial calculations. This effectively tells the agent when to use this tool (for context) and when not to (for numeric analysis). It stops short of naming alternatives but the sibling list makes the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the ratio is an estimate due to mismatched time windows (YTD income vs trailing spend) and instructs reading the caveats array. This adequately conveys the estimation trait, though it doesn't list specific caveats.
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?
Two sentences with no waste: the first defines the metric, the second captures the estimation nuance and directs attention to caveats. Front-loaded definition, though slightly more structuring around usage could improve scannability.
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, no-annotation tool, the description effectively communicates purpose, estimation nature, and the caveats array. It does not specify return format or units, but the mention of caveats implies output structure. Complete enough for correct invocation.
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 accepts no parameters, so the description correctly adds nothing about parameter behavior. The baseline for zero-param tools is 4, and the description sufficiently explains the tool's computation without needing parameter details.
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 states a specific computation: 'share of earnings being kept' combining payroll savings and post-spending survival. It clearly distinguishes from sibling tools like income_summary or expenses_spend by focusing on the ratio, not raw amounts.
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 implies the tool is for estimating savings rate and explicitly warns to read caveats before quoting. It does not name alternatives or exclusions, but the context (zero parameters, focused purpose) makes when-to-use clear from its definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![finledger MCP server](https://glama.ai/mcp/servers/anikam13/finledger/badges/card.svg)](https://glama.ai/mcp/servers/anikam13/finledger)

Score Badge

Copy to your README.md:

[![finledger MCP server](https://glama.ai/mcp/servers/anikam13/finledger/badges/score.svg)](https://glama.ai/mcp/servers/anikam13/finledger)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anikam13/finledger'

If you have feedback or need assistance with the MCP directory API, please join our Discord server