mcp-colombia

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific domains (finances, real estate, e-commerce, travel) with no overlap in functionality. For example, finanzas_comparar_cdt and finanzas_comparar_cuentas serve different financial comparison needs, while ml_buscar_productos and ml_detalle_producto handle distinct e-commerce tasks.
Naming Consistency5/5
All tools follow a consistent snake_case pattern with a clear domain_prefix_verb_noun structure (e.g., finanzas_comparar_cdt, inmuebles_buscar). This predictable naming convention makes it easy to understand each tool's purpose and category at a glance.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose as a Colombia-focused utility covering multiple domains (finance, real estate, e-commerce, travel). Each tool earns its place by addressing a specific, common use case without redundancy or excessive fragmentation.
Completeness4/5
The tool set provides solid coverage for key consumer domains in Colombia, with clear CRUD-like operations where applicable (e.g., search and detail for products, search for flights/hotels). Minor gaps exist, such as no tool for comparing flight or hotel options directly, but agents can work around this by using the provided search tools effectively.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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
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.
This repository includes a glama.json configuration file.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it requires authentication, has rate limits, returns real-time or cached data, or how it handles errors. For a tool with no 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 concise and well-structured, consisting of a single sentence that efficiently conveys the tool's purpose and key outputs. Every word earns its place, with no redundant or vague language, making it easy to understand at a glance.
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 with full schema coverage) and lack of annotations or output schema, the description is minimally complete. It explains what the tool does but doesn't compensate for missing behavioral details or output information, resulting in an adequate but incomplete context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'tipo' fully documented in the schema (including enum values and default). The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for adequate but not enhanced parameter 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: comparing savings accounts and digital wallets in Colombia, with specific metrics like performance, management fees, and GMF. It uses specific verbs ('Compara', 'Muestra') and identifies the resource, though it doesn't explicitly differentiate from sibling tools like 'finanzas_comparar_cdt' or 'finanzas_simular_credito' beyond the different financial products.
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. While it specifies the types of accounts compared, it doesn't mention when to choose this over other financial tools like 'finanzas_comparar_cdt' (for CDs) or 'finanzas_simular_credito' (for loans), nor does it indicate any prerequisites or exclusions for its use.
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 simulates credit and outputs key metrics (monthly payment, total cost, credit cost), which is useful. However, it lacks details on behavioral traits such as rate limits, authentication needs, data sources, or whether the simulation is real-time or based on cached data. For a tool with no annotations, this leaves significant gaps in understanding its operation.
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 appropriately sized and front-loaded, consisting of two concise sentences. The first sentence states the tool's purpose and scope, and the second specifies the outputs. There is no wasted language, and every 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.
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 (simulation with 3 parameters), no annotations, and no output schema, the description is moderately complete. It covers the purpose and outputs but lacks behavioral context and detailed usage guidelines. Without an output schema, it should ideally explain return values more thoroughly, but it does specify key metrics. This makes it adequate but with clear gaps for a simulation 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 input schema has 100% description coverage, with clear parameter definitions (monto, cuotas, proposito). The description adds no additional semantic meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Since schema coverage is high, the baseline score is 3, 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: 'Simula un crédito de consumo o libre inversión en los principales bancos y fintechs de Colombia' (simulates a consumer or free investment credit across major Colombian banks and fintechs). It specifies the action (simulate), resource (credit), and scope (Colombian financial institutions). However, it doesn't explicitly differentiate from sibling tools like 'finanzas_comparar_cdt' or 'finanzas_comparar_cuentas', which are also financial comparison tools but for different products.
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 mentions the tool's function but doesn't specify scenarios, prerequisites, or exclusions (e.g., when to use 'finanzas_comparar_cdt' for certificates of deposit instead). Usage is implied only through the tool's name and description, with no explicit context for selection among siblings.
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 'obtiene' (gets) details, implying a read-only operation, but does not mention error handling, rate limits, authentication needs, or response format. This leaves gaps in understanding how the tool behaves beyond its 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose and includes a helpful example. There is no redundant or unnecessary information, making it appropriately concise and well-structured for its purpose.
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 (1 parameter, no annotations, no output schema), the description is adequate but incomplete. It covers the basic operation but lacks details on behavioral aspects like error conditions or output structure, which are important for a tool without annotations or output schema.
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 'item_id' fully documented in the schema. The description adds minimal value by providing an example format ('MCO123456789'), but does not elaborate on semantics beyond what the schema already states. This meets the baseline for high schema 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 tool's purpose: 'Obtiene el detalle completo de un producto de MercadoLibre por su ID' (Gets the complete detail of a MercadoLibre product by its ID). It specifies the verb ('obtiene'), resource ('producto de MercadoLibre'), and scope ('detalle completo'), but does not explicitly differentiate from sibling tools like 'ml_buscar_productos', which likely searches for products rather than fetching details by ID.
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 mentions the parameter ('por su ID') but does not specify use cases, prerequisites, or exclusions. For example, it does not clarify if this is for single-product lookups versus bulk searches, or how it differs from 'ml_buscar_productos'.
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 the tool returns links to Avianca, LATAM and Skyscanner, which is useful output information. However, it doesn't disclose important behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, or what happens with invalid inputs. For a flight search tool with no annotations, this leaves significant 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 and front-loaded with essential information in just two sentences. The first sentence states the core purpose, and the second sentence adds crucial output information. Every word earns its place with zero waste 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 (6 parameters, flight search functionality) and the absence of both annotations and output schema, the description provides basic but incomplete context. It covers what the tool does and what it returns (links to specific providers), but doesn't address behavioral aspects, error conditions, or detailed usage scenarios. For a tool with no output schema, mentioning the return format is helpful but insufficient for 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%, so the schema already documents all 6 parameters thoroughly with examples and constraints. The description adds no additional parameter semantics beyond what's in the schema. According to guidelines, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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: 'Busca vuelos domésticos e internacionales desde/hacia Colombia' (searches domestic and international flights to/from Colombia). It specifies the verb ('busca') and resource ('vuelos') with geographic scope. However, it doesn't explicitly differentiate from its sibling 'viajes_buscar_hotel' beyond the obvious flight vs. hotel distinction.
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 the sibling hotel search tool or any other flight search options. The only implicit context is that it's for flights rather than hotels, but there's no explicit when/when-not guidance or alternative recommendations.
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 mentions the tool returns suggestions and a direct link to Booking.com, but lacks details on rate limits, authentication needs, error handling, or the format of returned suggestions, which is insufficient for a search tool with external integration.
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 and concise, consisting of two efficient sentences that directly state the tool's function and output without any wasted words or unnecessary details.
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 (6 parameters, no output schema, no annotations), the description is partially complete but lacks details on behavioral aspects like integration with Booking.com, result formatting, or error scenarios, which are important for effective tool use.
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 does not add meaning beyond what the input schema provides, as schema description coverage is 100% and all parameters are well-documented in the schema. The baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
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 tool's purpose with specific verbs ('Busca hoteles') and resources ('en ciudades colombianas'), and distinguishes it from sibling tools like 'viajes_buscar_vuelos' by focusing on hotel searches rather than flights or other travel services.
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 'inmuebles_buscar' or 'viajes_buscar_vuelos', nor does it mention any prerequisites or exclusions for its use, leaving the agent without context for 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?
With no annotations provided, the description carries full burden but only states what information will be shown ('tasas, rendimiento real y links al banco'). It doesn't disclose behavioral traits like whether this is a read-only operation, if it requires authentication, rate limits, data freshness, or what happens with invalid inputs. The description is functional but lacks operational context.
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 (one sentence) and front-loaded with the main purpose. It efficiently communicates the core functionality without unnecessary words, though it could be slightly more structured by explicitly mentioning all three parameters.
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 comparison tool with 3 parameters and no output schema, the description adequately covers the purpose but lacks details about the return format, error handling, or data sources. With no annotations and no output schema, more context about what the comparison results look like would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions 'según monto y plazo' which aligns with the first two parameters but doesn't add meaning beyond what the schema already provides. The 'top' parameter isn't mentioned at all in the description.
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 ('Compara' - compares), resource ('CDTs disponibles en Colombia'), and scope ('según monto y plazo'). It distinguishes from sibling tools by focusing specifically on CDTs rather than accounts, loans, properties, products, or travel services.
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 context (when comparing CDTs by amount and term) but doesn't explicitly state when to use this vs. alternatives like 'finanzas_comparar_cuentas' or 'finanzas_simular_credito'. No guidance on prerequisites or exclusions is provided.
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 what information is returned (precios, vendedor, envío gratis, link de compra), but does not cover important aspects like rate limits, authentication needs, error handling, or pagination behavior for a search tool with up to 10 results.
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, efficient sentence that front-loads the core functionality. Every part earns its place by specifying the action, target, and key return values 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?
For a search tool with 6 parameters, 100% schema coverage, and no output schema, the description adequately covers the basic purpose and return values. However, it lacks details on behavioral aspects like result format, error cases, or limitations, which would be helpful given the absence of annotations and output schema.
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 6 parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as explaining how query terms are matched or the meaning of 'relevancia' sorting. 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.
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 ('Busca productos') and resource ('en MercadoLibre Colombia'), distinguishing it from sibling tools like 'ml_detalle_producto' which likely provides detailed product information. It explicitly mentions the scope of the search and the key information returned.
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 products on MercadoLibre Colombia, but does not explicitly state when to use this tool versus alternatives like 'ml_detalle_producto' or other search tools. It provides basic context but lacks explicit exclusions or comparative 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. It mentions searching two sources and filtering, but doesn't disclose behavioral traits like rate limits, authentication needs, response format, pagination, or error handling. For a search 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 concise and front-loaded, stating the core purpose in the first sentence and listing key filters in the second. Every sentence earns its place with no wasted words, making it easy to scan and understand 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 no annotations and no output schema, the description is incomplete for a 7-parameter search tool. It covers the what and where but lacks details on behavioral aspects, return values, or error cases. It's adequate as a basic overview but has clear gaps for agent 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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value by listing some filter criteria (ciudad, precio, habitaciones, zona), but doesn't provide additional semantics beyond the schema. With high coverage, baseline is 3, but the description slightly enhances context, warranting a 4.
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 tool searches for apartments and houses for rent or sale in Colombia, specifying the sources (FincaRaíz and MetroCuadrado) and filtering criteria. It uses specific verbs ('busca', 'filtra') and distinguishes itself from sibling tools which are about finance, e-commerce, and travel, not real estate.
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 real estate searches in Colombia with specific filters, but doesn't explicitly state when to use this tool versus alternatives or when not to use it. No sibling tools overlap in functionality, so differentiation isn't needed, but guidance on prerequisites or constraints is absent.
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:

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

Score Badge

Copy to your README.md:

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

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/manuelariasfz/mcp-colombia'

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