Opendata Koumoul
Server Details
Access to Koumoul platform datasets - diverse French open data
- 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
Score is being calculated. Check back soon.
Available Tools
7 toolsaggregate_dataAggregate data from a datasetARead-onlyInspect
Aggregate dataset rows by 1-3 columns with optional metrics (sum, avg, min, max, count). Defaults to counting rows per group. Use for grouped counts or grouped metrics (e.g., average salary per city). For a single global metric without grouping, use calculate_metric instead.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box filter (only for geolocalized datasets). Format: "lonMin,latMin,lonMax,latMax". Example: "-2.5,43,3,47". | |
| sort | No | Sort order for aggregation results. Use special keys: "count" or "-count" (by row count asc/desc), "key" or "-key" (by column value asc/desc), "metric" or "-metric" (by metric value asc/desc). Default: sorts by metric desc (if metric specified), then count desc. Example: "-count" to sort by most frequent values first | |
| metric | No | Optional metric to compute ON EACH GROUP. If not provided, defaults to counting rows per group. | |
| filters | No | Column filters as key-value pairs. Key format: column_key + suffix (see server instructions for available suffixes). All values must be strings, even for numbers/dates. If a column key has underscores (e.g., code_postal), just append the suffix: code_postal_eq. Example: { "nom_search": "Jean", "age_lte": "30", "ville_eq": "Paris" } | |
| datasetId | Yes | The exact dataset ID from the "id" field in search_datasets results. Do not use the title or slug. | |
| dateMatch | No | Temporal filter (only for temporal datasets with date fields). Accepts a single date "YYYY-MM-DD" to match that day, or a date range "YYYY-MM-DD,YYYY-MM-DD" to match an overlapping period. ISO datetimes also accepted. Example: "2023-11-21" or "2023-01-01,2023-12-31". | |
| geoDistance | No | Geographic proximity filter (only for geolocalized datasets). Restricts results to within a distance from a point. Format: "lon,lat,distance". Example: "2.35,48.85,10km". Use distance "0" for point-in-polygon containment. | |
| groupByColumns | Yes | Columns to GROUP BY (like SQL GROUP BY). These define the categories/buckets, NOT the column to compute metrics on. Use column keys from describe_dataset (min 1, max 3). |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | The total number of rows in the dataset |
| datasetId | Yes | The dataset ID that was aggregated |
| requestUrl | Yes | Direct URL to API results in JSON format (must be included in responses for citation and direct access to aggregated view) |
| aggregations | Yes | Array of aggregation results for each specified column (limited to 20 rows) |
| nonRepresented | Yes | Number of rows NOT included in the returned aggregations (only the top 20 groups are returned). Add this to the sum of all group totals to reconstruct the dataset total. |
| totalAggregated | Yes | The total number of different values aggregated across all specified columns |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true covering safety, description adds valuable behavioral context: default behavior ('Defaults to counting rows per group'), available metric types, and clarifies the 1-3 column grouping limit. Could optionally mention performance implications of large datasets.
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?
Four efficient sentences: purpose, default behavior, use cases, and alternative tool reference. Zero redundancy. Front-loaded with core functionality.
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 excellent schema coverage (100%) and existence of output schema, description appropriately focuses on core aggregation logic and sibling differentiation without redundantly documenting filter syntax or return formats.
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 (baseline 3). Description adds semantic value by explaining the relationship between parameters (grouping columns define buckets vs metric column being computed) and clarifying default counting behavior when metric is omitted.
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?
Specific verb 'Aggregate' with resource 'dataset rows' and clear scope 'by 1-3 columns'. Explicitly distinguishes from sibling 'calculate_metric' by contrasting grouped vs global metrics.
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 when to use alternative: 'For a single global metric without grouping, use calculate_metric instead.' Provides concrete use case examples (grouped counts, average salary per city).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calculate_metricCalculate a metric on a dataset columnARead-onlyInspect
Calculate a single metric (avg, sum, min, max, stats, value_count, cardinality, percentiles) on a dataset column. Supports filters to restrict the calculation to a subset of rows. Use for a single statistic on the whole dataset or a filtered subset. For per-group breakdowns, use aggregate_data instead.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box filter (only for geolocalized datasets). Format: "lonMin,latMin,lonMax,latMax". Example: "-2.5,43,3,47". | |
| metric | Yes | Metric to calculate. Available: avg, sum, min, max (for numbers); min, max, cardinality, value_count (for strings); value_count (for others); stats returns count/min/max/avg/sum; percentiles returns distribution. | |
| filters | No | Column filters as key-value pairs. Key format: column_key + suffix (see server instructions for available suffixes). All values must be strings, even for numbers/dates. If a column key has underscores (e.g., code_postal), just append the suffix: code_postal_eq. Example: { "nom_search": "Jean", "age_lte": "30", "ville_eq": "Paris" } | |
| fieldKey | Yes | The column key to calculate the metric on (use keys from describe_dataset) | |
| percents | No | Comma-separated percentages for percentiles metric (default: "1,5,25,50,75,95,99"). Only used when metric is "percentiles". | |
| datasetId | Yes | The exact dataset ID from the "id" field in search_datasets results. Do not use the title or slug. | |
| dateMatch | No | Temporal filter (only for temporal datasets with date fields). Accepts a single date "YYYY-MM-DD" to match that day, or a date range "YYYY-MM-DD,YYYY-MM-DD" to match an overlapping period. ISO datetimes also accepted. Example: "2023-11-21" or "2023-01-01,2023-12-31". | |
| geoDistance | No | Geographic proximity filter (only for geolocalized datasets). Restricts results to within a distance from a point. Format: "lon,lat,distance". Example: "2.35,48.85,10km". Use distance "0" for point-in-polygon containment. |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | Total number of rows included in the calculation |
| value | No | The calculated metric value. For avg/sum/min/max/value_count/cardinality: a single number. For stats: an object {count, min, max, avg, sum}. For percentiles: an object mapping percentage strings to values, e.g. {"25": 30000, "50": 42000, "75": 55000}. |
| metric | Yes | The metric that was calculated |
| fieldKey | Yes | The column key that was queried |
| datasetId | Yes | The dataset ID that was queried |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, confirming safe read access. The description adds context about calculation scope (whole dataset vs filtered) and metric categories, but does not disclose performance characteristics, potential timeouts on large datasets, or explicit return value structure (though an output schema exists).
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?
Three tightly focused sentences with zero waste: first establishes core function and metric options, second mentions filtering capability, third provides sibling distinction. Information is front-loaded and every sentence earns its place.
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 rich schema (100% coverage), output schema existence, and read-only annotations, the description provides adequate context by covering purpose, filtering, and sibling boundaries. Minor gap: could mention type restrictions for specific metrics (e.g., avg only for numbers) which appear only in the schema.
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?
With 100% schema description coverage, the baseline is 3. The description mentions filters and metric types generically but does not add syntax details, format constraints, or semantic clarification beyond what the comprehensive schema already provides for all 8 parameters.
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 provides a specific verb ('Calculate') and resource ('metric on a dataset column'), enumerates the available metric types, and clearly distinguishes from the sibling tool 'aggregate_data' by specifying this is for single statistics rather than per-group breakdowns.
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 when to use ('for a single statistic on the whole dataset or a filtered subset') and provides a clear alternative for other use cases ('For per-group breakdowns, use aggregate_data instead'), giving the agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_datasetDescribe DatasetBRead-onlyInspect
Get detailed metadata for a dataset: column schema, sample rows, license, spatial/temporal coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| datasetId | Yes | The exact dataset ID from the "id" field in search_datasets results. Do not use the title or slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique dataset Id (required for search_data tools) |
| bbox | No | Spatial bounding box of the dataset: [lonMin, latMin, lonMax, latMax]. Present only for geolocalized datasets. |
| link | Yes | Link to the dataset page (must be included in responses as citation source) |
| slug | No | Human-readable unique identifier for the dataset, used in URLs |
| count | Yes | Total number of data rows in the dataset |
| title | Yes | Dataset title |
| origin | No | Source or provider of the dataset |
| schema | Yes | Dataset column schema with types and metadata |
| topics | No | Topics/categories the dataset belongs to |
| license | No | Dataset license information (must be included in responses) |
| spatial | No | Spatial coverage information |
| summary | No | A brief summary of the dataset content |
| keywords | No | Keywords associated with the dataset |
| temporal | No | Temporal coverage information |
| frequency | No | Update frequency of the dataset |
| timePeriod | No | Temporal coverage of the dataset data. Present only for temporal datasets. |
| description | No | A markdown description of the dataset content |
| sampleLines | Yes | Array of 3 sample data rows showing real values from the dataset. Use these examples to understand exact formatting, casing, and typical values for _eq and _search filters. |
| geolocalized | No | Whether this dataset has geographic data. When true, geo filters (bbox, geoDistance) are available in search_data, aggregate_data, and calculate_metric. |
| temporalDataset | No | Whether this dataset has temporal data (date fields). When true, the dateMatch filter is available in search_data, aggregate_data, and calculate_metric. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation confirms this is a safe read operation, and the description adds valuable context by specifying what metadata components are returned (sample rows, license, etc.). However, it lacks details on sampling methodology, result limits, or caching behavior that would fully characterize the tool's behavior.
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, efficient sentence of appropriate length. It front-loads the action and resource, and the colon-separated list efficiently communicates return value categories without waste.
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's low complexity (single parameter), readOnly annotation, and existence of an output schema, the description is sufficiently complete. It appropriately delegates detailed return value documentation to the output schema while providing a high-level summary of metadata categories.
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?
With 100% schema description coverage, the baseline is 3. The description mentions 'for a dataset' implying the ID parameter but adds no semantic detail beyond the schema's explicit instruction that the ID must come from search_datasets results and not use titles/slugs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed metadata for a dataset') and enumerates the specific metadata components returned (column schema, sample rows, license, spatial/temporal coverage). While it clearly distinguishes from data extraction siblings like aggregate_data by focusing on metadata, it does not explicitly differentiate from search_datasets.
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 siblings like search_datasets, nor does it mention the prerequisite workflow of obtaining a datasetId from search results (though the parameter schema description does cover this).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
geocode_addressGeocode French AddressARead-onlyInspect
Convert a French address or place name into geographic coordinates using the IGN Géoplateforme geocoding service. Returns matching locations with coordinates, postal code, city, and relevance score.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Address or place name to search for in France. Examples: "20 avenue de Segur, Paris", "Mairie de Bordeaux", "33000" | |
| limit | No | Maximum number of results to return (default: 5) |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of results returned |
| results | Yes | Geocoding results ordered by relevance |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the readOnlyHint annotation by disclosing the external service dependency (IGN Géoplateforme) and detailing the return structure (coordinates, postal code, city, relevance score), which helps the agent understand what data to expect despite the presence of an output 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 consists of two dense, information-rich sentences with zero redundancy. It front-loads the core function and service provider, then efficiently describes return values.
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's simplicity (2 parameters), the presence of an output schema, and the inclusion of return value summaries and external service attribution, the description provides complete context for agent invocation.
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?
With 100% schema description coverage, the input parameters are fully documented in the schema itself. The description does not add additional parameter semantics (e.g., query syntax tips), meeting the baseline expectation for high-coverage schemas.
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 specific action (convert), input resource (French address or place name), output (geographic coordinates), and the specific external service used (IGN Géoplateforme). It clearly distinguishes from data-oriented siblings like aggregate_data or search_datasets.
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?
While the description implies usage through specificity (French addresses only, geocoding context), it lacks explicit guidance on when to select this tool versus alternatives or prerequisites like 'use when you need coordinates for mapping'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_field_valuesGet distinct values of a dataset columnARead-onlyInspect
List distinct values of a specific column. Useful to discover what values exist before filtering, or to populate a filter list. Always call this before using _eq or _in filters to get exact values and avoid case-sensitivity errors.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of values to return (default: 10, max: 1000) | |
| sort | No | Sort order for the values (default: asc) | |
| query | No | Optional text to filter values (prefix/substring match within this column) | |
| fieldKey | Yes | The column key to get values for (use keys from describe_dataset) | |
| datasetId | Yes | The exact dataset ID from the "id" field in search_datasets results. Do not use the title or slug. |
Output Schema
| Name | Required | Description |
|---|---|---|
| values | Yes | Array of distinct values for the specified column |
| fieldKey | Yes | The column key that was queried |
| datasetId | Yes | The dataset ID that was queried |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While readOnlyHint=true covers safety, the description adds critical behavioral context: case-sensitivity risks when filtering and the discovery workflow pattern. Does not mention potential truncation at max limit (1000), which would be useful given the size parameter exists.
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?
Three sentences with zero waste: core function (sentence 1), use case (sentence 2), imperative workflow rule (sentence 3). Front-loaded with the essential action and appropriately imperative with 'Always call this'.
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?
Complete given 100% schema coverage and existence of output schema (no need to describe return values). Covers purpose, workflow prerequisites (call before filtering), risk mitigation (case sensitivity), and parameter sourcing hints (from describe_dataset implicit in workflow).
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%, providing full parameter documentation including dataset sourcing (search_datasets) and field key sourcing (describe_dataset). Description mentions 'specific column' reinforcing fieldKey's purpose but adds no syntax or format details beyond the comprehensive 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?
Verbs 'List distinct values' clearly state the action and resource. Distinguished from siblings like search_data (finds records) and describe_dataset (describes schema) by focusing specifically on enumerating categorical values for filtering purposes.
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 'Useful to discover what values exist before filtering' and mandates 'Always call this before using _eq or _in filters to get exact values and avoid case-sensitivity errors.' Provides clear workflow integration and warns against direct filtering without discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_dataSearch data from a datasetARead-onlyInspect
Search for data rows in a dataset using full-text search (query) or precise column filters. Returns matching rows and a filtered view URL. Use to retrieve individual rows. Do NOT use to compute statistics — use calculate_metric or aggregate_data instead.
| Name | Required | Description | Default |
|---|---|---|---|
| bbox | No | Geographic bounding box filter (only for geolocalized datasets). Format: "lonMin,latMin,lonMax,latMax". Example: "-2.5,43,3,47". | |
| next | No | URL from a previous search_data response to fetch the next page of results. When provided, all other parameters (query, filters, select, sort, size) are ignored since the URL already contains them. | |
| size | No | Number of rows to return per page (default: 10, max: 50). Increase when you know you need more results upfront to avoid multiple pagination round-trips. | |
| sort | No | Sort order for results. Comma-separated list of column keys. Prefix with - for descending order. Special keys: _score (relevance), _i (index order), _updatedAt, _rand (random), _geo_distance:lon:lat (distance from point, for geolocalized datasets). Examples: "population" (ascending), "-population" (descending), "_geo_distance:2.35:48.85" (closest first) | |
| query | No | French keywords for full-text search across all dataset columns (simple keywords, not sentences). Can be combined with filters, but prefer filters alone when criteria target specific columns. Use query for broad keyword matching across all columns. Examples: "Jean Dupont", "Paris", "2025" | |
| select | No | Optional comma-separated list of column keys to include in the results. Useful when the dataset has many columns to reduce output size. If not provided, all columns are returned. Use column keys from describe_dataset. Format: column1,column2,column3 (No spaces after commas). Example: "nom,age,ville" | |
| filters | No | Column filters as key-value pairs. Key format: column_key + suffix (see server instructions for available suffixes). All values must be strings, even for numbers/dates. If a column key has underscores (e.g., code_postal), just append the suffix: code_postal_eq. Example: { "nom_search": "Jean", "age_lte": "30", "ville_eq": "Paris" } | |
| datasetId | Yes | The exact dataset ID from the "id" field in search_datasets results. Do not use the title or slug. | |
| dateMatch | No | Temporal filter (only for temporal datasets with date fields). Accepts a single date "YYYY-MM-DD" to match that day, or a date range "YYYY-MM-DD,YYYY-MM-DD" to match an overlapping period. ISO datetimes also accepted. Example: "2023-11-21" or "2023-01-01,2023-12-31". | |
| geoDistance | No | Geographic proximity filter (only for geolocalized datasets). Restricts results to within a distance from a point. Format: "lon,lat,distance". Example: "2.35,48.85,10km". Use distance "0" for point-in-polygon containment. |
Output Schema
| Name | Required | Description |
|---|---|---|
| next | No | URL to fetch the next page of results. Absent when there are no more results. Pass this value as the next input parameter to get the next page. |
| count | Yes | Number of data rows matching the search criteria and filters |
| lines | Yes | An array of data rows matching the search criteria (up to the requested size). |
| datasetId | Yes | The dataset ID that was searched |
| filteredViewUrl | Yes | Link to view the filtered dataset results in table format (must be included in responses for citation and direct access to filtered view) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true; description adds valuable behavioral context about return values ('matching rows and a filtered view URL') and search methodology. Could mention pagination behavior, but schema covers next/size parameters adequately.
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?
Four tightly-constructed sentences with zero waste: purpose, returns, positive usage, and negative guidance with alternatives. Perfectly front-loaded and efficient.
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 complex 10-parameter tool with nested objects and specialized capabilities (geo/temporal filters), the description provides sufficient high-level conceptual framework. Output schema exists, and input schema covers specialized parameters (bbox, geoDistance, dateMatch) at 100% coverage, so description need not enumerate them.
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% (baseline 3). Description adds crucial semantic mapping: 'full-text search (query)' and 'precise column filters' explains the conceptual model for using the query vs. filters parameters, aiding agent reasoning beyond raw schema definitions.
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?
Excellent specificity: states the action (Search), resource (data rows), mechanism (full-text search using 'query' parameter or precise column filters), and distinguishes from siblings by explicitly naming alternatives (calculate_metric, aggregate_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?
Explicit when-to-use ('Use to retrieve individual rows'), explicit when-NOT-to-use ('Do NOT use to compute statistics'), and names specific sibling alternatives to use instead. Perfect guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasetsSearch DatasetsARead-onlyInspect
Full-text search for datasets by French keywords. Returns matching datasets with ID, title, summary, and page link.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | French keywords for full-text search (simple terms, not sentences). If 0 results, try synonyms or broader terms. Examples: "élus", "DPE", "entreprises", "logement social" |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of datasets matching the full-text search criteria |
| datasets | Yes | An array of the top 20 datasets matching the full-text search criteria. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Supplements readOnlyHint annotation by disclosing return structure (ID, title, summary, page link) and language specificity (French). Does not mention pagination, rate limits, or result limits, but provides sufficient context for a read-only operation.
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, zero waste. First sentence establishes purpose and constraints; second discloses return values. Front-loaded and appropriately sized for the tool complexity.
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?
Adequate for a single-parameter search tool with complete input schema and existing output schema. Description appropriately focuses on search semantics and return fields rather than redundant output documentation. Minor gap: no mention of result pagination or maximum results.
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 detailed parameter description including examples. Main description reinforces 'French keywords' but adds no additional syntax or format details beyond the schema, warranting the baseline score for high-coverage schemas.
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?
States specific verb (full-text search), resource (datasets), and scope constraint (French keywords). Distinguishes from sibling 'search_data' implicitly by specifying 'datasets,' though explicit comparison would strengthen this.
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?
Implied usage through French keyword specificity and dataset focus. However, lacks explicit guidance on when to use versus sibling 'search_data' or other search tools. The schema description contains helpful hints about handling zero results, but main description omits alternativs.
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!