FinaShopping MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different financial products (loans, credit cards, guarantees, insurances, benefits), but 'search-loans' and 'compare-loans' could cause some confusion as both involve loan evaluation. Descriptions help clarify that 'search-loans' finds available options while 'compare-loans' analyzes multiple loans side-by-side.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with hyphens (e.g., calculate-loan-payment, search-credit-cards). The naming is predictable and readable throughout, with no mixing of conventions or styles.
Tool Count5/5
With 9 tools, the server is well-scoped for a financial shopping assistant covering loans, credit cards, guarantees, insurances, and benefits. Each tool earns its place by addressing a specific aspect of financial product research and comparison in Uruguay.
Completeness4/5
The tool set provides strong coverage for searching and comparing financial products, with minor gaps. For example, there are tools to search loans and credit cards but no explicit tools for applying or managing these products, which agents might need to work around. However, core research workflows are well-supported.
Average 3.1/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
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 full burden for behavioral disclosure. It only states what the tool does (search) and the resource scope, but doesn't describe how results are returned, whether there's pagination, what authentication is needed, rate limits, or error conditions. For a search tool with zero 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two parallel language versions, but the bilingual approach adds redundancy without adding information value. The structure is front-loaded with the core purpose, but the second sentence merely expands on the first without adding new guidance. Some waste exists in the repetition across languages.
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 search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns, how results are structured, whether there are filters beyond the 'type' parameter, or any limitations. The description should provide more context about the search behavior and expected outputs given the lack of structured metadata.
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%, so the schema already documents the single parameter. The description adds marginal value by listing example insurance types that align with the parameter description, but doesn't provide additional syntax, format details, or search behavior beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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: 'Search available insurance in Uruguay' with specific resource types listed (life, auto, home). It distinguishes itself from sibling tools like 'search-credit-cards' and 'search-loans' by focusing on insurance products. However, it doesn't explicitly differentiate from 'search-guarantees' which might be related.
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 use 'search-insurances' versus other search tools like 'search-guarantees' or when insurance searching is appropriate versus loan/credit card tools. There's no context about prerequisites 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves benefits but doesn't describe traits like whether it requires user authentication, rate limits, pagination, or error handling. For a read operation with zero annotation coverage, this is a significant gap, as it leaves the agent guessing about implementation details beyond the basic function.
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 appropriately sized and front-loaded, with the primary purpose stated first in English, followed by a Spanish translation. Both sentences are direct and waste no words, though the bilingual format adds minor redundancy. It earns a high score for efficiency, as every sentence contributes to clarity without unnecessary elaboration.
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 low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, or return values. Without annotations or output schema, the agent must infer more about the operation, making it incomplete for optimal tool selection, though it meets the minimum for a simple read 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?
The description adds no parameter-specific information beyond what the input schema provides. The schema has 100% description coverage for the single parameter 'category', including examples (Food, Entertainment, etc.). With high schema coverage, the baseline is 3, as the description doesn't compensate with additional semantics, but it also doesn't contradict or omit necessary details.
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: 'Get available benefits and discounts for financial product users.' It specifies the verb ('Get') and resource ('benefits and discounts'), and distinguishes it from sibling tools like 'calculate-loan-payment' or 'search-credit-cards' by focusing on benefits rather than products or calculations. However, it doesn't explicitly differentiate from all siblings (e.g., 'get-card-details' might overlap in scope), keeping it from 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. It doesn't mention prerequisites, context (e.g., user authentication), or compare it to sibling tools like 'search-credit-cards' that might also involve benefits. Usage is implied by the purpose but lacks explicit instructions, scoring low due to the absence of when/when-not statements or alternatives.
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 states it 'gets' details, implying a read-only operation, but doesn't clarify authentication needs, rate limits, error conditions, or what 'complete details' includes (e.g., fields returned). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic purpose.
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 front-loaded with the core purpose in a single, efficient sentence, followed by a Spanish translation that doesn't add informational value but may aid multilingual users. It avoids redundancy, but the translation slightly reduces conciseness without enhancing clarity for the primary English context, keeping it from a perfect score.
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 low complexity (single parameter, no nested objects) and high schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it fails to explain what 'complete details' returns or any behavioral traits. This leaves the agent with incomplete context for a read operation, though the simplicity mitigates severity.
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%, with the parameter 'cardId' clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain what a card ID is, how to obtain it, or valid ranges. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, though no extra value is added.
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 ('Get complete details') and resource ('for a specific credit card'), making the purpose unambiguous. It distinguishes from siblings like search-credit-cards (which lists/filters) by focusing on retrieving full details for a single card. However, it doesn't explicitly contrast with get-benefits or other siblings that might also retrieve card-related information, 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. It doesn't mention prerequisites (e.g., needing a card ID), exclusions (e.g., not for searching multiple cards), or direct comparisons to siblings like search-credit-cards. The agent must infer usage from the name and description alone, which is insufficient for optimal tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves requirements but does not specify if this is a read-only operation, requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 concise and front-loaded, with the primary purpose stated first in English followed by a Spanish translation. Both sentences are directly relevant, but the bilingual format slightly reduces efficiency without adding new information. Overall, it's appropriately sized with minimal waste.
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 lack of annotations and output schema, the description is incomplete. It does not explain what the tool returns (e.g., a list of requirements, eligibility criteria, or documentation needs), error handling, or behavioral traits. For a tool that likely provides critical financial information, more context is needed to ensure proper usage.
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 input schema has 100% description coverage, with the parameter 'loanId' fully documented. The description does not add any semantic details beyond what the schema provides (e.g., it doesn't explain what a loan ID is or how to obtain it). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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: 'Get the requirements to apply for a specific loan.' It specifies the verb ('get') and resource ('requirements'), but does not distinguish it from potential sibling tools like 'search-loans' or 'compare-loans', which might also provide loan-related information. The bilingual format adds clarity but doesn't affect the core 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a loan ID), exclusions, or comparisons to sibling tools like 'search-loans' (which might list loans) or 'get-benefits' (which might provide different loan details). Usage is implied only by the tool name and description.
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 what the tool does (search) without describing how it behaves: no information about response format, pagination, error conditions, rate limits, or authentication requirements. For a search tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but inefficiently structured. The bilingual repetition ('| Buscar opciones de garantía de alquiler disponibles en Uruguay.') adds no semantic value for an AI agent and wastes space. The first part is clear, but the second part is redundant noise that doesn't earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (searching financial products) and the complete lack of annotations and output schema, the description is insufficient. It doesn't explain what information is returned, how results are structured, or any behavioral aspects. For a search tool in a financial domain, more context about response format and limitations would be expected.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't mention parameters, which is correct for a parameterless tool. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any parameter documentation 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 tool's purpose: 'Search available rental guarantee options in Uruguay.' It specifies the verb (search), resource (rental guarantee options), and geographic scope (Uruguay). However, it doesn't explicitly distinguish this from sibling tools like search-insurances or search-loans, 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. It doesn't mention prerequisites, appropriate contexts, or exclusions. The bilingual repetition adds no usage information, leaving the agent with no help in selecting this tool over similar search tools in the sibling list.
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 states the tool searches and filters, but doesn't describe what the search returns (e.g., list of loans, institutions), whether it's read-only, requires authentication, has rate limits, or other behavioral traits. This leaves significant gaps for a search 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 extremely concise—two parallel sentences in English and Spanish with zero wasted words. It front-loads the core purpose and filtering capabilities efficiently, making every sentence earn 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?
For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., loan details, institutions), how results are structured, or any behavioral constraints. The high schema coverage doesn't compensate for these missing contextual elements.
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%, so the schema already documents all three parameters thoroughly. The description mentions filtering by amount, term, and type, which aligns with the schema but adds no additional semantic context beyond what's already in the structured fields.
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 searches for loans from Uruguayan financial institutions with specific filters (amount, term, type), providing a specific verb ('search') and resource ('loans'). However, it doesn't explicitly differentiate from sibling tools like 'compare-loans' or 'search-credit-cards', 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 'compare-loans' or 'get-loan-requirements', nor does it mention prerequisites or exclusions. It only lists filtering capabilities without contextual usage advice.
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 states the tool compares loans but doesn't describe what the comparison includes (e.g., interest rates, terms), how results are presented, whether it's read-only or has side effects, or any limitations like rate limits. For a tool with no annotations, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated first in a single sentence. The bilingual format (English and Spanish) adds redundancy but doesn't significantly detract from clarity. Every sentence earns its place by reinforcing the tool's utility, though it could be more structured for AI consumption.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (comparing multiple loans) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the comparison outputs (e.g., side-by-side table, summary metrics) or behavioral traits like error handling. For a comparison tool with no structured output documentation, this leaves the agent with insufficient context.
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 adds no parameter-specific information beyond what the schema provides. The schema has 100% description coverage, documenting that 'loanIds' is an array of numbers with min/max items. Since the schema does the heavy lifting, the baseline score is 3, as the description doesn't compensate with additional semantics like format examples or usage context.
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: 'Compare multiple loans side by side' specifies the verb (compare) and resource (loans). It distinguishes from siblings like 'search-loans' or 'get-loan-requirements' by focusing on comparison rather than searching or fetching requirements. However, it doesn't explicitly differentiate from all siblings (e.g., 'calculate-loan-payment' is also loan-related but for calculations).
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 implied usage guidance: 'Useful for choosing the best option' suggests it should be used when evaluating loan alternatives. It doesn't explicitly state when to use this tool versus alternatives like 'search-loans' or 'calculate-loan-payment', nor does it mention exclusions or prerequisites. The guidance is helpful but not comprehensive.
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 filtering but doesn't describe what the search returns (e.g., list of cards, details), whether results are paginated, if authentication is required, or any rate limits. For a search 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured as a single sentence in both English and Spanish, front-loading the core purpose and filtering criteria without unnecessary details. However, the bilingual repetition slightly reduces conciseness, though it may serve localization purposes.
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 (search with two optional filters), no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the purpose and parameters but lacks behavioral details like return format, error handling, or usage context, leaving gaps for an AI agent to infer.
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%, so the schema already documents both parameters ('network' with enum values and 'maxAnnualFee' with numeric constraints). The description adds no additional semantic context beyond what's in the schema, such as how filtering logic works or parameter interactions. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search available credit cards'), resource ('in Uruguay'), and scope ('Filter by payment network and maximum annual fee'), distinguishing it from sibling tools like 'get-card-details' or 'compare-loans'. The bilingual format reinforces the purpose without redundancy.
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 searching credit cards with filtering capabilities, but it doesn't explicitly state when to use this tool versus alternatives like 'get-card-details' or 'compare-loans'. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred.
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, the description carries full burden. It discloses the calculation method (French amortization) and output structure, but lacks details on error handling, precision, or limitations (e.g., rate/term bounds). It doesn't contradict annotations (none provided).
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 front-loaded with key information in a single bilingual sentence, with no redundant or verbose elements. Every part (calculation method, output) earns its place 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?
For a calculation tool with no annotations and no output schema, the description adequately covers purpose and method. However, it lacks details on output format, error cases, or example usage, which would enhance completeness given the tool's functional complexity.
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 100%, providing clear parameter details. The description adds context by specifying the amortization system and output values, but doesn't elaborate on parameter interactions or calculation nuances beyond what the schema implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('calculate monthly loan payment'), the method ('French amortization system'), and the output ('returns payment, total amount, and interest'). It distinguishes from siblings like 'compare-loans' or 'search-loans' by focusing on calculation rather than comparison or search.
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 loan payment calculation with fixed amortization, but provides no explicit guidance on when to use this tool versus alternatives like 'compare-loans' or 'get-loan-requirements'. It lacks context on prerequisites or exclusions.
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:

[![finashopping-mcp MCP server](https://glama.ai/mcp/servers/ismaeldosil/finashopping-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ismaeldosil/finashopping-mcp)

Score Badge

Copy to your README.md:

[![finashopping-mcp MCP server](https://glama.ai/mcp/servers/ismaeldosil/finashopping-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ismaeldosil/finashopping-mcp)

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/ismaeldosil/finashopping-mcp'

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