Provides access to AccuWeather data for weather forecasts and current conditions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Expense-Tracker-MCP-Server add an expense of $50 for lunch today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Setting MCP server MCP https://github.com/abhiemj/manim-mcp-server
cmd:
pip install manim pip install mcp
cd desktop git clone https://github.com/abhiemj/manim-mcp-server.git cd manim-mcp-server
to configure the manim mcp server go to claude- settings - developer ->edit config > locate ->claude_sedktop_config.json -> paste this below code
inside config file give the path of python file" cmd: which python3 you get path add in configs: command key and also: cmd: which manim gives path for exe file cmd : go to clone file cd desktop cd manim-mcp-server cd src pwd give the path frm tht file
and then restart the claude desktop after any changes or adding any mcp server by closing it Integration with Claude To integrate the Manim MCP server with Claude, add the following to your claude_desktop_config.json file:
{ "mcpServers": { "manim-server": { "command": "/absolute/path/to/python", "args": [ "/absolute/path/to/manim-mcp-server/src/manim_server.py" ], "env": { "MANIM_EXECUTABLE": "/Users/[Your_username]/anaconda3/envs/manim2/Scripts/manim.exe" } } } }
check in claude - prompt:
"Use the manim-server to create an animation showing the concept of vector transformation in linear algebra.
Start with a 2D coordinate grid.
Show two basis vectors: $\hat{i} = (1,0)$ in red and $\hat{j} = (0,1)$ in blue.
Animate a transformation by applying a matrix $A = [[2,1],[1,1]]$ to the grid and the vectors.
Show the grid warping and the basis vectors moving to their new transformed positions.
Add a title above: 'Linear Algebra: Matrix Transformation Demo'."
connecting twitter mcp server: local https://github.com/EnesCinr/twitter-mcp paste the code in claude deverloper config file - add the code inside mcpServer dict developer console { "mcpServers": { "twitter-mcp": { "command": "npx", "args": ["-y", "@enescinar/twitter-mcp"], "env": { "API_KEY": "your_api_key_here", "API_SECRET_KEY": "your_api_secret_key_here", "ACCESS_TOKEN": "your_access_token_here", "ACCESS_TOKEN_SECRET": "your_access_token_secret_here" } } } } connecting remote mcp server connecting weather mcp server https://github.com/adhikasp/mcp-weather
to get api keys frm accuweather: https://developer.accuweather.com/home get apikey frm here
{ "mcpServers": { "weather": { "command": "uvx", "args": ["--from", "git+https://github.com/adhikasp/mcp-weather.git", "mcp-weather"], "env": { "ACCUWEATHER_API_KEY": "your_api_key_here" } } } }
================= to check for available mcp servers : google search : awesome mcp servers: check this below GitHub link: https://github.com/punkpeye/awesome-mcp-servers
Working with fastmcp:
pip install uv
create a dir - expense-tracker-mcp-server open in vs code
terminal: - initializing uv terminal in current directory
uv init .
uv add fastmcp fastmcp version ---note: close the vs code and restart after every install if its not working--- op:
FastMCP version: 3.4.4 MCP version: 1.28.1 Python version: 3.12.6 Platform: Windows-11-10.0.26200-SP0 FastMCP root path: C:\Users\Lenovo\OneDrive\Desktop\MCP\expense-tracker-mcp-server.venv\Lib\site-packages
writing fastmcp code
to test server if its running to debug: we get a mcp inspector tool on search engine: it is by anthropic:
uv run fastmcp dev main.py
to run server: uv run fastmcp run main.py
connecting mcp to claude desktop: uv run fastmcp install claude-desktop main.py
configure the json file on claude desktop setting: change the paths accordingly
Add a new expense to DB
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| note | No | ||
| amount | Yes | ||
| category | Yes | ||
| subcategory | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It states this is a DB insert, but does not mention permissions, idempotency, validation, side effects, or return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It is concise, though it sacrifices useful detail in favor of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 undocumented parameters, no annotations, and no output schema, the description is not complete enough for an agent to invoke the tool confidently. It conveys the high-level action but omits required input semantics and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage, and the description adds no parameter-level meaning. The agent must infer semantics solely from parameter names like 'amount' and 'category'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Add a new expense') that clearly identifies the operation. It is distinct from the sibling tools by nature, but it does not explicitly call out the differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus list_expenses or summarize. The verb 'Add' implies creation, but no context, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listing all expense entries between startdate to enddate
| Name | Required | Description | Default |
|---|---|---|---|
| enddate | Yes | ||
| startdate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It discloses that this is a read-only listing operation and that it returns all entries rather than a filtered or aggregated subset, but it does not clarify date inclusivity, ordering, pagination, or the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant wording or repeated schema information. Every phrase contributes: the action, the resource scope, and the date constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool, the description gives the core invocation intent, but there is no output schema and no annotation safety information. An agent would still need to infer the return format and the accepted date representation, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions, so the description is the only semantic source. It names both startdate and enddate and states that they define the range boundaries, which adds real meaning beyond the empty schema entries. However, it does not specify date format or whether the bounds are inclusive/exclusive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Listing') with a clear resource ('all expense entries') and a date-range constraint, so an agent immediately knows what the tool does. It is also distinguishable from the sibling tools add_expense and summarize, which are write/aggregation actions rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Listing all expense entries between startdate to enddate' clearly implies the tool is for retrieving every expense record in a specified range. It does not explicitly name alternatives or exclusion criteria, but the sibling tools are so different in purpose that the intended context is still obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize expenses by category for that date range.
| Name | Required | Description | Default |
|---|---|---|---|
| enddate | Yes | ||
| category | No | ||
| startdate | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool summarizes expense data by category, but it does not clarify whether the category parameter filters or groups results, what happens when category is null, whether the operation is read-only, or what the returned summary looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with no filler. It front-loads the operation and grouping dimension, though the word 'that' is slightly ambiguous and could have been replaced with 'specified' or 'given'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% parameter coverage, the description is not complete enough for an agent to invoke the tool confidently. It leaves the category behavior ambiguous and omits date format and output-shape details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and startdate/enddate have empty schemas, so the description must compensate. It adds only the notions of 'date range' and 'category', but it does not explain parameter formats, the meaning of the optional category default, or how the date range boundaries are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('summarize'), a resource ('expenses'), and the grouping dimension ('by category') with a date range, which clearly conveys an aggregation purpose. It is distinct from list_expenses and add_expense by its verb, though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for aggregate reporting on expenses within a date range, rather than listing individual expenses or adding them. However, it gives no explicit when-to-use or when-not-to-use guidance and does not mention the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_expenselist_expensessummarizeEach tool has a clearly distinct purpose: adding an expense, listing expenses in a date range, and summarizing expenses by category. There is no meaningful overlap or confusion between them.
add_expense and list_expenses follow a clear verb_noun pattern, though one uses singular and the other plural. summarize is readable but omits a noun object, creating a minor inconsistency.
Three tools is a well-scoped set for a focused expense tracker. Each tool serves a distinct and necessary part of the basic workflow: recording, viewing, and summarizing expenses.
The core add/list/summarize workflow is covered, but there are no update or delete expense operations. This is a notable gap because users cannot correct or remove mistaken entries without direct database access.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Log, query, and edit expenses, budgets, and accounts in Manilo from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
Corporate travel booking and expense management for TripGain, exposed as an MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SyedaNaziaGit/Expense-Tracker-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
