geocontext

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct geographic domain or WFS operation. There is no ambiguity between tools like adminexpress, cadastre, urbanisme, etc. They all have clearly separated purposes.
Naming Consistency4/5
Most tools use lowercase with underscores (adminexpress, assiette_sup, gpf_wfs_*), but a few are single words (geocode, altitude, urbanisme). The gpf_wfs_ prefix provides consistency for WFS-related tools. Minor deviations prevent a perfect score.
Tool Count5/5
9 tools is well-scoped for a geographic context server. It covers essential data sources (administrative, elevation, cadastre, urbanism, WFS discovery) without being excessive.
Completeness4/5
The tool surface covers major geographic queries: administrative units, elevation, servitudes, cadastre, geocoding, urban planning, and WFS metadata. Missing are update/delete capabilities, but that aligns with the read-only nature. Slight gap in batch or spatial queries beyond point-based, but sufficient for the domain.
Average 4.4/5 across 9 of 9 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 16 of 21 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on May 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations indiquent déjà que l'outil est en lecture seule et idempotent. La description ajoute des informations comportementales utiles : les résultats sont des objets typés avec propriétés administratives et un feature_ref réutilisable. Il n'y a pas de contradiction avec les annotations.
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?
La description est concise et place l'objectif principal en début de phrase. Elle est légèrement longue mais sans information redondante. Les phrases sont bien structurées.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Avec un schéma de sortie existant (non affiché mais indiqué comme présent), la description explique la structure du retour (liste d'objets typés avec propriétés et feature_ref) et la source. Pour un outil simple à 2 paramètres, c'est complet.
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?
Le schéma couvre à 100 % les paramètres (lon, lat) avec descriptions. La description ne fait que répéter qu'il s'agit de longitude et latitude, sans ajouter de détails sémantiques supplémentaires. Score de base 3.
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?
Le titre et la description indiquent clairement que l'outil renvoie la liste des unités administratives pour un point donné par longitude/latitude, avec une distinction claire par rapport aux outils frères comme gpf_wfs_get_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description explique quand utiliser l'outil (obtenir les unités administratives pour un point) et mentionne que le feature_ref peut être réutilisé dans d'autres outils. Elle ne mentionne pas explicitement quand ne pas l'utiliser, mais le contexte est suffisant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly (true), destructiveHint (false), idempotentHint (true). The description adds the data source (Géoplateforme) and output fields (altitude, accuracy), providing value beyond the structured information.
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?
Two sentences, no wasted words, includes source citation. Efficient and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (context signal), the description need not detail return format. It mentions altitude and accuracy, and annotations cover safety. Complete for a simple lookup 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?
Schema description coverage is 100%, so the schema already documents lon/lat fully. The description adds minimal extra meaning ('longitude' and 'latitude' are implicit). Baseline 3 is appropriate.
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 it returns altitude and accuracy for a geographic point given longitude and latitude, distinguishing it from sibling tools like geocode (address to coordinates) and cadastre (parcel data).
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?
No explicit guidance on when to use this tool vs alternatives. The context signals (readOnly, idempotent) imply it's safe but don't specify scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint, destructiveHint false, idempotentHint true, openWorldHint true. The description adds behavioral details beyond annotations: mentions return types (ponctuelles, linéaires, surfaciques), exposure of feature_ref, and the source. It does not cover performance or rate limits, but the annotations already handle safety. The description adds moderate 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 concise with three sentences including a parenthetical source. It efficiently conveys purpose, examples, and usage of feature_ref. Well-structured and front-loaded, though could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of SUP concepts and the existence of an output schema, the description is complete. It explains what a SUP is, gives examples, mentions return types, and references a sibling tool. It could include an example response but output schema likely covers that.
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 'lon' and 'lat' clearly described. The description confirms the parameters are for specifying a point but does not add new semantics beyond what the schema provides. Baseline 3 is appropriate.
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 it returns the list of servitudes d'utilité publique (SUP) for a given point. It explains the concept of SUP, lists examples, and distinguishes from sibling tools like geocode and gpf_wfs_get_feature_by_id. The verb 'Renvoie' and the resource 'assiettes de servitudes d'utilité publique' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides an alternative tool for retrieving the exact object via feature_ref: 'Pour récupérer exactement l'objet correspondant au feature_ref, utiliser gpf_wfs_get_feature_by_id.' This gives clear when-not-to-use and directs to a sibling tool. The context of being a point-of-interest query for SUP is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open world. Description adds that it is text-based mini-search returning ordered candidates with id, title, description, relevance score, and notes default max_results. No contradictions.
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?
Description is concise: purpose stated first, then details, then bolded important usage notes. Every sentence earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with output schema, the description fully covers what the tool does, return fields, and usage context. No gaps given the available 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 covers both parameters with descriptions and constraints. Description adds that query is text search and max_results defaults to 10, but this is minimal beyond schema. With 100% schema coverage, baseline 3 is appropriate.
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 it searches for WFS types using keywords to find valid type identifiers. It distinguishes itself from siblings by explicitly positioning itself as a prerequisite to gpf_wfs_describe_type and gpf_wfs_get_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: before describe_type or get_features when typename unknown. Suggests using French business terms. Does not explicitly state when not to use, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotent and read-only behavior, but the description adds critical context: search distance fixed at 10 meters, empty result if no object found, and deduplication by type. The source is also noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action, but the structure is a single dense paragraph. Minor improvement could be achieved with bullet points or shorter sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 read-only parameters), the description fully covers purpose, behavior, edge cases, and integration with sibling tools. Output schema exists, so return values need not be detailed.
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 coverage is 100% with clear descriptions for lon and lat. The description reiterates them in context but adds no new semantics beyond the schema. Baseline 3 is appropriate.
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 returns cadastral objects near a given longitude/latitude, with details and a reusable feature_ref. It distinguishes from siblings by mentioning alternative tools for specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for cadastral data near a point) and how to reuse the feature_ref in other tools like gpf_wfs_get_features and gpf_wfs_get_feature_by_id. However, it lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Les annotations couvrent déjà la sécurité (readOnlyHint, idempotentHint, etc.). La description ajoute des détails comportementaux comme les champs retournés (kind, city, zipcode) et la source, ce qui est utile au-delà des annotations.
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?
La description est concise, en deux paragraphes bien structurés, sans information superflue. Le verbe d'action et le résultat sont placés en premier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Avec un schéma de sortie présent et des annotations riches, la description est suffisamment complète. Elle couvre l'essentiel des informations nécessaires à l'utilisation (résultats, coordonnées, source). Pourrait mentionner les limites de la source, mais reste adéquate.
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?
Le schéma couvre 100% des paramètres, donc la baseline est de 3. La description ajoute des exemples de texte libre ('lieu, adresse, POI'), ce qui enrichit la sémantique du paramètre 'text'.
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?
La description indique clairement que l'outil renvoie des résultats d'autocomplétion géocodés avec coordonnées, libellé et informations de localisation. Elle mentionne aussi que les coordonnées sont réutilisables dans d'autres outils, ce qui précise l'usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
La description ne donne pas de directives explicites sur quand utiliser cet outil par rapport à ses alternatives, mais elle précise que les coordonnées retournées sont réutilisables dans tous les autres outils, ce qui indique un cas d'usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds unique behavioral details: strict cardinality guarantee (error on zero or multiple results) and the effect of result_type on output. No contradictions.
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?
Three sentences, each providing essential info: core action, usage context with sibling references, cardinality guarantee, and additional result_type guidance. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main aspects: purpose, usage context, cardinality, result_type usage. Lacks explicit mention of output format for 'results' (FeatureCollection) but it is implied and described. Enough for a focused retrieval tool without output schema.
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 coverage is 100%, so baseline is 3. The description adds context: clarifies 'sans filtre attributaire ni spatial' (no filters) and explains the result_type enum and select behavior (geometry auto-added for request).
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 states 'Récupère exactement un objet WFS' and specifies the parameters (typename, feature_id) and the absence of filters, clearly distinguishing it from sibling tools like gpf_wfs_get_features that retrieve multiple objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when you already have a feature_ref from another tool, and warns about strict cardinality (error on zero or multiple results). It also explains when to use result_type='request' for debugging or visualization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. Description adds context on the nature of results and the feature_ref reuse, enhancing transparency without contradiction.
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?
Description is informative but slightly lengthy; could be more concise. It is front-loaded with the core action and provides necessary details, though some repetition exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and presence of an output schema, the description covers all essential aspects: what it does, what it returns, how to link to other tools, and provides URL templates. Sufficient for an agent to invoke correctly.
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?
Input schema has 100% coverage with clear descriptions for lon and lat. Description does not add significant meaning beyond what schema already provides, so baseline of 3 is appropriate.
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 it returns a list of urban planning objects for a given point, specifying source and types (documents, zones, prescriptions). It differentiates itself from siblings by mentioning compatibility with gpf_wfs_get_features and gpf_wfs_get_feature_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (for urban planning info at a point) and references sibling tools for further queries, plus URL models for accessing documents on Géoportail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. The description adds that output includes property types, descriptions, and enums, plus a strong warning about errors on incorrect names.
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?
Concise, front-loaded with purpose, then usage, then output details, then important note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with output schema present, the description provides sufficient context: purpose, workflow position, output highlights, and critical error warning.
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 coverage is 100% with a description for the only parameter. The description adds context by giving an example value (BDTOPO_V3:batiment) and reinforcing the requirement for exact names.
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 returns the detailed schema of a WFS type (identifiers, description, list of properties) from a typename. It distinguishes itself from siblings by positioning itself between gpf_wfs_search_types and gpf_wfs_get_features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use after gpf_wfs_search_types and before gpf_wfs_get_features. Also warns that an incorrect property name causes an error, implying when-to-use and caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent, but the description adds critical behaviors: geometry auto-added for request mode, error on missing describe_type, and result_type differences.
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?
Description is long but well-structured with examples and warnings. Each sentence adds value; however, it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18 parameters, spatial operators), the description is comprehensive: covers mandatory prerequisite, error conditions, result formats, and parameter usage. No output schema, but result_type explanations suffice.
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 has 100% coverage, so baseline is 3. The description adds value by grouping spatial operators with their parameters, providing examples, and explaining the purpose of each parameter beyond the schema.
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 queries a WFS type and returns structured results without requiring the model to write CQL or WFS. It distinguishes from sibling tools like gpf_wfs_get_feature_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after calling gpf_wfs_describe_type) and when not to (use get_feature_by_id for the same typename). Provides examples and mandatory prerequisites.
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:

[![geocontext MCP server](https://glama.ai/mcp/servers/ignfab/geocontext/badges/card.svg)](https://glama.ai/mcp/servers/ignfab/geocontext)

Score Badge

Copy to your README.md:

[![geocontext MCP server](https://glama.ai/mcp/servers/ignfab/geocontext/badges/score.svg)](https://glama.ai/mcp/servers/ignfab/geocontext)

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/ignfab/geocontext'

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