Expense Tracker MCP Server

by simran-mehta

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 distinct purpose with no overlap: adding, deleting, updating, listing, summarizing, exporting expenses, and managing budgets. The descriptions specify unique actions (e.g., add vs. update) and resources (expenses vs. budget), eliminating ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., add_expense, delete_expense, get_budget_status). The naming is uniform across all eight tools, using snake_case and clear action verbs aligned with their functions.
Tool Count5/5
With 8 tools, the server is well-scoped for an expense tracker, covering core operations like CRUD for expenses, budget management, summarization, and export. Each tool earns its place without being excessive or sparse.
Completeness5/5
The tool set provides complete coverage for the expense tracking domain: full CRUD for expenses (add, delete, update, list), budget management (set and status), summarization, and export. There are no obvious gaps, enabling agents to handle typical workflows end-to-end.
Average 3.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

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 mentions 'Update fields' which implies mutation, but doesn't specify permissions needed, whether changes are reversible, rate limits, or error handling. It lacks details on what happens if fields are omitted or set to null, and the output schema exists but isn't described. This is a significant gap for a mutation 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 a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's function.
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 a mutation tool with 5 parameters, 0% schema coverage, no annotations, and an output schema (though not described), the description is incomplete. It doesn't explain behavioral aspects like side effects, error conditions, or parameter usage, and relies on the output schema for return values without context. For this complexity, more detail is needed to be fully helpful.
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 by explaining parameters. It only mentions 'ID' and 'fields' generically, without detailing the specific fields (amount, category, description, date) or their semantics (e.g., format for date, handling of null values). This leaves 5 parameters largely undocumented, failing to add meaningful context beyond the schema.
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 ('Update fields') and resource ('an existing expense by ID'), making the purpose unambiguous. It distinguishes from siblings like 'add_expense' (create) and 'delete_expense' (remove), though it doesn't explicitly contrast with them. The verb+resource combination is specific but lacks detail on which fields can be updated.
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. It doesn't mention prerequisites (e.g., expense must exist), exclusions, or comparisons to siblings like 'add_expense' for creation or 'list_expenses' for viewing. The description only states what it does, not when it's appropriate.
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 states the action ('Export') but doesn't clarify if this is a read-only operation, whether it requires specific permissions, or if it has side effects like generating files. The mention of 'CSV string' hints at output format but lacks details on rate limits, error handling, or data scope.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and output, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.
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 moderate complexity (3 parameters, no annotations) and the presence of an output schema, the description is minimally adequate. It specifies the output format ('CSV string'), which the output schema likely details further, but it doesn't address parameter meanings or behavioral traits, leaving gaps in contextual understanding.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain the meaning or usage of 'start_date', 'end_date', and 'category'. This leaves the agent with no semantic understanding beyond the schema's structural 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 clearly states the verb ('Export') and resource ('expenses') with the output format ('as a CSV string'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_expenses' or 'get_expense_summary', which might also retrieve expense data but in different formats or structures.
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 like 'list_expenses' or 'get_expense_summary'. It lacks context about scenarios where CSV export is preferred over other data retrieval methods, and doesn't mention prerequisites or exclusions.
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 the full burden of behavioral disclosure. While 'set or update' implies a mutation operation, it doesn't specify whether this requires admin permissions, if changes are reversible, what happens to existing budgets, or any rate limits. This leaves significant gaps in understanding the tool's behavior and risks.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 that there is an output schema (which handles return values), the description doesn't need to explain outputs. However, for a mutation tool with 3 parameters, 0% schema coverage, and no annotations, the description is incomplete—it lacks details on permissions, error cases, and parameter semantics, making it only minimally adequate.
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%, meaning none of the parameters are documented in the schema. The description mentions 'category' and 'monthly budget limit', which loosely map to the 'category' and 'monthly_limit' parameters, but it doesn't explain what a 'category' entails (e.g., predefined list or free text) or the format for 'monthly_limit' (e.g., positive number). The 'currency' parameter is not addressed at all, failing to compensate for the low coverage.
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 verb ('set or update') and resource ('monthly budget limit for a category'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_budget_status' or 'update_expense' which might also relate to budget management, preventing a perfect score.
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. For example, it doesn't clarify if this should be used instead of 'update_expense' for budget changes, or if it's for initial setup versus ongoing adjustments, leaving the agent with minimal context for selection.
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 full burden for behavioral disclosure. It mentions date format and default behavior, but doesn't address important aspects like whether this is a write operation (implied but not stated), what permissions are needed, how errors are handled, or what the response contains.
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 extremely concise with just two sentences that both add value. The first sentence states the core purpose, and the second provides important implementation detail about date formatting. There's zero wasted text.
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?
For a write operation with 5 parameters and no annotations, the description is minimal but covers the essential action. The existence of an output schema means the description doesn't need to explain return values, but it should provide more guidance about usage context and behavioral expectations for a mutation tool.
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?
With 0% schema description coverage, the description adds minimal value beyond the schema. It only provides information about the 'date' parameter (format and default), leaving the other 4 parameters (amount, category, description, currency) without additional semantic context beyond what the schema provides.
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 ('Add a new expense') and resource ('expense'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_expense' or explain how it differs from them.
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 like 'update_expense' or 'list_expenses'. It mentions date format but doesn't explain when this tool is appropriate versus other expense-related operations.
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 the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description doesn't specify whether this action is reversible, requires specific permissions, has side effects (e.g., on budget calculations), or returns confirmation details. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
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 zero wasted words, making it highly concise and front-loaded. Every word ('Delete an expense by ID') contributes essential information, achieving optimal efficiency for such a simple tool.
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 complexity (a destructive mutation), lack of annotations, and presence of an output schema (which reduces the need to describe return values), the description is minimally adequate. It states the core action but misses critical context like behavioral traits, usage guidelines, and parameter details, making it incomplete for safe and effective use by 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?
The schema description coverage is 0%, but the description adds minimal semantic context by specifying that the 'id' parameter is used to identify the expense to delete. However, it doesn't explain what format the ID should be (e.g., integer, string) or where to find it, leaving the schema to carry most of the parameter documentation burden. With one parameter, the baseline is 4, but the lack of detail reduces this to 3.
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 ('Delete') and target resource ('an expense by ID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'update_expense' or 'list_expenses' beyond the basic verb, which prevents a perfect score.
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 like 'update_expense' or 'list_expenses'. It lacks context about prerequisites (e.g., whether the expense must exist), exclusions, or recommended workflows, leaving the agent to infer usage from the tool 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 provided, the description carries the full burden of behavioral disclosure. It states the aggregation function but doesn't mention whether this is a read-only operation (implied but not explicit), what permissions are required, how date ranges work (inclusive/exclusive), whether null dates mean 'all time', or what the output format looks like. For a summary tool with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place: 'Summarize' (action), 'total spending' (resource), 'grouped by' (operation), and the two grouping options. There's no wasted verbiage or redundancy.
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 moderate complexity (aggregation with date filtering), no annotations, and the presence of an output schema (which handles return values), the description is minimally adequate. It covers the primary function but lacks important context about date parameter usage, behavioral constraints, and differentiation from sibling tools. The output schema existence prevents this from being a complete failure.
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 description mentions the 'group_by' parameter options ('category' or 'month'), which adds meaning beyond the schema's 0% description coverage. However, it doesn't explain the date parameters (start_date, end_date) at all - their purpose, format, or what happens when null. With 3 parameters total and only partial coverage in the description, this meets the baseline for moderate schema coverage compensation.
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's purpose with a specific verb ('Summarize') and resource ('total spending'), and specifies the grouping options ('by category or month'). It distinguishes this from siblings like list_expenses (which likely lists individual items) and get_budget_status (which focuses on budget metrics). However, it doesn't explicitly mention expense data as the resource, though this is 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_expense_summary over list_expenses (for aggregated vs detailed views) or get_budget_status (for spending vs budget comparison). There's no context about prerequisites, data scope, or typical use cases.
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 full burden for behavioral disclosure. It mentions optional filters and date format, but fails to address critical behavioral aspects: whether this is a read-only operation (implied but not stated), pagination behavior (limit parameter exists but not explained), authentication requirements, rate limits, or what happens when no filters are applied. For a tool with 4 parameters and no annotation coverage, this is insufficient.
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 extremely concise with only two sentences that each serve clear purposes: stating the tool's function and specifying date format. There's zero wasted language, and the most critical information (date format) is appropriately included. This is a model of efficient description writing.
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 has an output schema (which handles return values), 4 parameters with 0% schema coverage, and no annotations, the description is minimally adequate. It covers the basic purpose and date format but misses important context: no guidance on usage versus siblings, incomplete parameter semantics, and insufficient behavioral transparency for a filtering/list tool. The output schema reduces the burden, but significant gaps remain.
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. It adds value by specifying the date format (YYYY-MM-DD) for date parameters, which isn't in the schema. However, it doesn't explain the 'category' parameter's possible values, the 'limit' parameter's purpose (pagination vs result limiting), or the relationship between start_date and end_date. The description provides some semantic context but leaves significant 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 states the verb ('List') and resource ('expenses'), making the purpose immediately understandable. It distinguishes from siblings like 'add_expense' or 'delete_expense' by focusing on retrieval rather than modification. However, it doesn't specify whether this lists all expenses or has a default scope, which prevents a perfect score.
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 like 'get_expense_summary' or 'export_expenses'. It mentions optional filters but doesn't explain when filtering is appropriate or what scenarios warrant this tool over others. This leaves the agent without clear decision-making criteria.
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 the full burden of behavioral disclosure. It mentions the month parameter format and default, which is useful, but doesn't describe key behaviors such as what data is returned (e.g., comparison details, error handling), whether it's a read-only operation, or any performance considerations. For a tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two clear sentences that directly state the tool's purpose and parameter details without any wasted words. Every sentence earns its place by providing essential information efficiently.
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 moderate complexity (one parameter, no annotations, but with an output schema), the description is minimally adequate. It covers the basic purpose and parameter semantics, but since there's an output schema, it doesn't need to explain return values. However, for a tool with no annotations, it could benefit from more behavioral context to be fully complete.
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 description adds meaningful context for the single parameter by specifying the month format ('YYYY-MM') and default behavior ('defaults to current month'), which goes beyond the input schema's minimal coverage (0% schema description coverage). Since there's only one parameter, this effectively compensates for the schema's lack of detail, though it doesn't fully explain all possible semantics.
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's purpose with a specific verb ('Compare') and resources ('budget limits vs actual spend'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_expense_summary' or 'list_expenses', which might also involve budget/spend analysis, so it doesn't reach the highest 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 usage by specifying the month parameter format and default, suggesting it's for checking budget status in a given month. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'get_expense_summary' or 'list_expenses', nor does it mention prerequisites or exclusions, leaving usage context somewhat vague.
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:

[![Expense-Tracker-MCP-Server MCP server](https://glama.ai/mcp/servers/simran-mehta/Expense-Tracker-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/simran-mehta/Expense-Tracker-MCP-Server)

Score Badge

Copy to your README.md:

[![Expense-Tracker-MCP-Server MCP server](https://glama.ai/mcp/servers/simran-mehta/Expense-Tracker-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/simran-mehta/Expense-Tracker-MCP-Server)

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/simran-mehta/Expense-Tracker-MCP-Server'

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