cattle-market
Server Details
Datos del mercado ganadero argentino: precios INMAG, remates, consignatarias y alertas de precio.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4/5 across 10 of 10 tools scored. Lowest: 3.3/5.
Each tool targets a distinct aspect of the Argentine cattle market—searching entities, retrieving prices, calculating rentals, and setting alerts. Descriptions clearly differentiate similar tools like get_indice_novillo (daily index) and get_precios_hacienda (weekly categorical prices).
Tool names mix Spanish verbs (buscar_, calcular_, crear_) and English verbs (get_, list_). While readable, the lack of a uniform convention (e.g., all Spanish or all English verb_noun) reduces predictability.
10 tools is well-scoped for the domain—covering search, pricing, alerts, and context without bloat. Each tool serves a clear purpose and no tool seems redundant.
The tool surface covers major data needs: broker/cold-storage search, price indices, macro context, historical trends, and auctions. A minor gap is no direct tool for feedlot-specific metrics, but the existing tools enable derived calculations.
Available Tools
10 toolsbuscar_consignatariaAInspect
Busca consignatarias/casas de remate del directorio argentino por nombre, localidad o provincia. Devuelve nombre, ubicación, categoría, contacto y el perfil en consignatarias.com.ar.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Nombre, localidad o razón social a buscar | |
| limite | No | Máximo de resultados (default 8) | |
| provincia | No | Filtra por provincia (opcional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the tool returns specific fields (name, location, category, contact, profile URL), but there are no annotations provided. It does not disclose behavioral traits like authentication requirements, rate limits, or data freshness. The description partially covers behavior but is minimal.
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 concise with two sentences, no unnecessary words, and clearly structured to convey purpose and return values. Every part adds value.
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 search tool with three parameters and no output schema, the description provides clear purpose and return fields. It could mention pagination or default limit, but the schema already covers 'limite' default. Overall adequately 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?
Schema coverage is 100% with descriptions for all three parameters. The description largely repeats the schema's parameter descriptions (e.g., query can be name, locality, business name). It adds no additional semantics beyond what the schema provides, so baseline 3 is appropriate.
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 clearly states the verb 'Busca' (search), the resource 'consignatarias/casas de remate', and the search criteria (name, locality, province). It also lists the returned fields, distinguishing it from sibling tools like buscar_frigorifico.
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?
No explicit guidance on when to use this tool versus alternatives or when not to use it. While the sibling tools have different purposes, the description lacks context-specific usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
buscar_frigorificoBInspect
Busca frigoríficos habilitados MAGYP/SENASA (1.100+ plantas) por nombre, provincia o CUIT. Devuelve nombre, provincia, CUIT, matrícula y ciclo. Filtro por provincia.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Nombre o CUIT a buscar (opcional si se pasa provincia) | |
| limite | No | Máximo de resultados (default 10) | |
| provincia | No | Filtra por provincia |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Busca frigoríficos habilitados' (a read/search operation) but does not disclose behavioral traits such as authentication needs, rate limits, or what happens if no results are found. The description lacks detail on the nature of the operation (e.g., non-destructive).
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 short (two sentences, one a fragment) and front-loaded with the main action. However, there is slight redundancy between the two sentences. It is efficient but not maximally concise.
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 search tool with 3 parameters (none required) and no output schema, the description provides adequate context: search criteria, return fields, and a filter. It mentions the scale (1,100+ plants). Missing guidance on when to use vs. other search tools, but overall complete for its complexity.
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 100%, so baseline is 3. The description adds some context by stating search criteria (name, province, CUIT) and the province filter, but does not significantly augment the schema's parameter descriptions. The limite parameter is not elaborated beyond the schema.
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 clearly states the tool searches for registered meatpacking plants (frigoríficos) by name, province, or CUIT, and returns specific fields. It is distinct from sibling tools like buscar_consignataria, but does not explicitly differentiate itself.
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 usage for searching by name, province, or CUIT, but does not provide guidance on when to use this tool versus siblings (e.g., buscar_consignataria) or when not to use it. No explicit alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calcular_arrendamientoAInspect
Calcula el canon de arrendamiento rural argentino en pesos: kg de novillo por hectárea × hectáreas × precio del novillo. Por defecto usa el ÍNDICE SUGERIDO PARA ARRENDAMIENTOS RURALES oficial del MAG (haciinfo000013); si no está disponible, el INMAG del día.
| Name | Required | Description | Default |
|---|---|---|---|
| kg_ha | Yes | Kg de novillo por hectárea por mes (típico 3-6) | |
| hectareas | Yes | Cantidad de hectáreas | |
| precio_novillo | No | Precio del novillo ARS/kg (default: INMAG actual) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the formula, default index, and fallback. Missing details on potential errors (e.g., if both indexes unavailable) but sufficient for a calculation tool.
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?
Two sentences, no wasted words, front-loads purpose and formula. Efficient and clear.
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 simple calculation, 3 params, no output schema, description fully explains formula, defaults, and fallback. Sufficient for agent to use correctly.
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 has 100% coverage; description adds value by providing typical range for kg_ha (3-6) and clarifying price default. Reinforces schema info concisely.
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 clearly states the tool calculates a specific rural lease fee in pesos using a formula with kg per hectare, hectares, and price. It distinguishes from siblings by focusing on a specific calculation, not searching or listing.
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?
Explains when to use (calculate lease fee) and describes default behavior with official index and fallback. Does not explicitly state when not to use or mention alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
crear_alerta_precioAInspect
Crea una alerta de precio por umbral: cuando el precio de una categoría cruza el valor dado, se notifica por webhook (POST price.threshold_crossed). REQUIERE API KEY de un plan Enterprise. Autenticá de una de dos formas: (a) header del cliente MCP "headers": {"Authorization": "Bearer cnsg_live_..."}, o (b) el parámetro api_key de esta tool. Conseguí la key en https://www.consignatarias.com.ar/cuenta/api-keys
| Name | Required | Description | Default |
|---|---|---|---|
| umbral | Yes | Umbral en ARS/kg vivo (ej. 5000) | |
| api_key | No | API key del plan (cnsg_live_...). Opcional si ya la pasás por el header Authorization: Bearer. | |
| categoria | Yes | ||
| direccion | No | Cruzar hacia arriba o abajo (default above) | |
| webhook_url | Yes | URL https pública que recibe el POST cuando cruza |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Sin anotaciones, la descripción asume toda la carga de transparencia. Detalla que la operación crea una alerta, requiere autenticación, y que al cruzar el umbral se envía un POST a una URL webhook. También explica dos métodos de autenticación. Falta mencionar efectos secundarios como duplicados, pero es aceptable.
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?
La descripción es concisa: cuatro oraciones que cubren propósito, requisitos, autenticación y obtención de clave. No hay redundancia ni información innecesaria. La información más importante aparece primero.
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?
Para una herramienta con 5 parámetros, 3 requeridos y sin esquema de salida, la descripción cubre los aspectos clave: qué hace, cómo autenticar, unidades de umbral y destino del webhook. Faltaría mencionar el formato de la respuesta (ej. éxito/error), pero no es crítico para la operación.
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?
Aunque la cobertura de descripción del esquema es alta (80%), la descripción agrega valor significativo: especifica que 'umbral' está en ARS/kg vivo, que 'api_key' es opcional si se pasa por header, y proporciona la URL para obtener la clave. También aclara el evento del webhook. Esto va más allá del esquema.
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?
El nombre y la descripción indican claramente que la herramienta crea una alerta de precio por umbral. Se especifica el recurso (alerta de precio) y la acción (crear), además de detallar el comportamiento cuando se cruza el umbral y la notificación por webhook. No hay herramientas hermanas similares, por lo que se distingue fácilmente.
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?
La descripción proporciona instrucciones claras sobre cuándo usar la herramienta (para crear alertas de precio por umbral) y los requisitos (API key de plan Enterprise, autenticación por header o parámetro). Aunque no menciona alternativas explícitas, no existen herramientas hermanas con funcionalidad similar, por lo que la guía es suficiente.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contexto_macroAInspect
Contexto macro del mercado ganadero argentino: dólar blue y oficial (ARS), maíz FOB (USD/tn), y el spread novillo/maíz (kg de maíz que compra un kg de novillo — proxy de rentabilidad de feedlot).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the exact data points returned (dollar rates, corn price, spread), but does not state that the tool is read-only or discuss any side effects. There are no annotations to contradict, and the description is sufficient for a simple data retrieval tool.
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 sentence, efficiently conveying the tool's purpose and outputs. It is front-loaded with 'Contexto macro del mercado ganadero argentino' and includes necessary detail without extraneous information.
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 the tool has no parameters and no output schema, the description fully explains the returned data. It lists all key indicators and explains the spread, leaving no ambiguity about what the tool provides.
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 no parameters, so description does not need to add parameter meaning. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool returns.
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 clearly specifies the tool returns macro context of the Argentine livestock market, listing specific indicators (dollar rates, corn price, steer/corn spread). It distinguishes itself from sibling tools by focusing on macro context rather than individual prices or indices.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention common use cases, prerequisites, or conditions where other tools might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indice_novilloAInspect
Índice Novillo (INMAG) del Mercado Agroganadero argentino: precio de referencia hoy en ARS/kg vivo, con variación diaria, volumen y tendencia. Es el índice DIARIO ponderado por volumen del canal formal MAG (métrica distinta de los precios por categoría de get_precios_hacienda, que son observación semanal).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the tool returns price, variation, volume, and trend, is daily, and volume-weighted. It does not mention authentication or rate limits, but the nature is read-only and such details are not critical for a simple data retrieval tool.
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?
Two sentences efficiently convey the tool's purpose, data provided, and differentiation from a sibling tool. No redundant information.
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 parameters, no output schema, and no annotations, the description sufficiently explains the tool's purpose and output. It could be improved by specifying if the data is for the current date only, but 'hoy' implies that. Overall, it provides enough context for an agent to decide to use it.
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 tool has zero parameters, so baseline is 4. The description adds value by explaining what data is returned (price, variation, volume, trend) and the index characteristics, which goes beyond the empty schema.
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 clearly states the tool returns the Índice Novillo (INMAG) reference price today in ARS/kg live weight with daily variation, volume, and trend. It distinguishes itself from sibling tool get_precios_hacienda, which provides weekly category prices.
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 explains that this tool gives a daily volume-weighted index from the formal MAG channel, contrasting it with get_precios_hacienda's weekly observations. This provides clear context for when to use this tool, though it doesn't explicitly list when not to use it or name alternatives beyond one sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_inmag_historicoAInspect
Evolución histórica del Índice Novillo (INMAG) en ARS/kg vivo. Devuelve valor inicial/final, variación, mínimo y máximo del período, y una muestra de la serie. Sirve para tendencia.
| Name | Required | Description | Default |
|---|---|---|---|
| dias | No | Ventana en días hacia atrás (default 30, máx 730) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists return fields but does not disclose behavioral traits such as data freshness, error handling, or side effects. The description adds minimal insight beyond the return schema.
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 concise with two sentences, front-loading the main purpose and output. No redundant information, but could be slightly more structured with visual separation.
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 tool with one parameter and no output schema, the description covers purpose, output, and use case. However, it lacks examples, edge case behavior, and prerequisites, making it adequate but not fully comprehensive.
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 coverage is 100%, and the description does not add information beyond the schema's parameter description. Baseline 3 is appropriate as the schema already documents the parameter adequately.
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 clearly states the tool returns historical evolution of the INMAG index in ARS/kg vivo, including specific metrics (initial/final value, variation, min/max, sample). It distinguishes from siblings like 'get_indice_novillo' by focusing on historical data.
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 indicates the tool is for trend analysis ('Sirve para tendencia'), providing clear context. However, it does not explicitly mention when not to use or compare to alternatives like 'get_indice_novillo'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_precios_detalladosAInspect
Precios por SUBCATEGORÍA del Mercado Agroganadero (ej. "NOVILLOS Regular +430", "VACAS Conserva Buena") con mínimo, promedio y máximo en ARS/kg vivo. Más granular que get_precios_hacienda. Filtro opcional por grupo (novillos/novillitos/vaquillonas/vacas/toros).
| Name | Required | Description | Default |
|---|---|---|---|
| grupo | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses output format (min, avg, max, units) but does not explicitly state read-only nature or any safety implications. Adequately transparent but could be more explicit.
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?
Two sentences, front-loaded with core purpose, no wasted words. Every sentence adds value.
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?
No output schema, but description details return values (min, avg, max, units) and provides examples. Covers the tool's functionality adequately for its complexity (1 param, no nested objects).
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 coverage 0%, but description compensates by explaining the optional group filter and listing enum values. Adds meaning beyond raw schema by clarifying purpose and optionality.
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?
Description clearly states it retrieves prices by subcategory from Mercado Agroganadero with min, avg, max in ARS/kg live weight. It explicitly distinguishes itself from sibling get_precios_hacienda by noting higher granularity.
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?
Describes when to use (more granular than get_precios_hacienda) and mentions optional filter. Lacks explicit when-not-to-use or alternative tools beyond one sibling, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_precios_haciendaAInspect
Precios de hacienda por categoría (novillos, novillitos, vaquillonas, vacas, toros, terneros) en ARS/kg vivo — observación SEMANAL del SIO/Mercado Agroganadero. Es una métrica distinta del índice INMAG diario (get_indice_novillo): no comparar 1:1. Sin argumento devuelve todas.
| Name | Required | Description | Default |
|---|---|---|---|
| categoria | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds the weekly frequency and data source, but does not state rate limits, authentication needs, or what happens with invalid categories (though schema handles via enum). Still, the transparency is high.
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?
Two sentences, no wasted words. The purpose is stated first, followed by a clear usage distinction. Perfectly concise and structured.
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 the tool has only one optional parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, parameter meaning, default, time resolution, source, and differentiation from a sibling. Completely adequate.
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 has 0% description coverage for the parameter. The description lists all enum values and explains that omitting the parameter returns all categories, fully compensating for the lack of schema documentation.
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 clearly states it returns livestock prices by category in ARS/kg live weight, weekly observation from SIO/Mercado Agroganadero, and distinguishes from the daily index (get_indice_novillo).
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?
Explicitly states the time resolution (weekly), contrasts with the sibling tool (daily index), warns against direct comparison, and explains default behavior (returns all categories when no argument).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rematesAInspect
Próximos remates de hacienda en Argentina. Filtros opcionales: provincia y límite. Devuelve fecha, consignataria, ubicación, categoría y transmisión en vivo si hay.
| Name | Required | Description | Default |
|---|---|---|---|
| limite | No | Máximo de remates (default 10) | |
| provincia | No | Filtra por provincia (ej. "Buenos Aires") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description does not disclose any behavioral aspects such as read-only nature, side effects, or required permissions. The lack of safety information is a gap.
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 only two sentences, concise and front-loaded with the main purpose. It efficiently covers filters and return information without unnecessary words.
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?
Without an output schema, the description adequately describes return fields. However, it omits potential details like pagination, ordering, or performance considerations.
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 coverage is 100%, so parameters are already documented. The description adds value by mentioning optional filters and listing return fields, but does not enhance parameter meaning beyond the schema.
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 clearly states the tool lists upcoming livestock auctions in Argentina and specifies optional filters (province, limit) and return fields (date, auctioneer, location, category, live transmission). It distinguishes itself from sibling tools that focus on searching or calculating other aspects.
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 when to use (to get upcoming auctions) but does not provide explicit guidance on when not to use or how it compares to siblings like 'buscar_consignataria' or 'get_precios_hacienda'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!