Adapt to upstream gpf-schema-store v0.2.2

[LionelZoubritzky-IGN]

Main changes:

• Upgraded dependency from @ignfab/gpf-schema-store 0.1.x to 0.2.0.
• Migrated catalog usage to the new API (getCollectionSchema, search, CollectionSearchMatch).
• Refactored WFS/tool typing to OGC schema types (OgcCollectionSchema, OgcCollectionProperty) and adapted property/enum handling to oneOf.
• Updated gpf_describe_type and gpf_search_types to reflect the new schema model.

Close #142

[mborne]

Mainly 2 points :

• Handle date and date-time by checking the format instead of inspecting the name of the property
• Use the following fixture for geometry properties in tests :

"properties":{
    "geometrie" : {
      "x-ogc-role" : "primary-geometry",
      "format" : "geometry-multipolygon"
    }
}

[mborne]

Thanks

[esgn]

Uh ... code was peer reviewed but was it actually tested ? 🤔

1. https://github.com/ignfab/gpf-schema-store/blob/9cbc62f5611521f1281638ef2f5dd6b25b0c313b/src/ogc-api-feature/types.ts#L72 here properties are defined as record()
2. https://github.com/QuantGeekDev/mcp-framework does not support record and the output schema renders as string (default type). 🤦🏻‍♂️

"properties": {
  "type": "string"
},

3. A simple test of gpf_describe_type in mcp-inspector returns the following error

[LionelZoubritzky-IGN]

gpf_describe_type works fine when tested it with an actual LLM... which makes me notice that the LLM is completely skipping structured_content, duh. Sorry for missing this test in mcp-inspector.

Now we have a difficulty: the goal of the main change of gpf-schema-store was to use OGC API Features output schemas. Those inherently have a Record structure, which is incompatible with mcp-framework. Thus, I see four choices:

1. Just skip output validation of the properties field. In practice: copy the content of zOgcCollectionSchema without the properties field and patch a .catchall(z.unknown()) to cover for it.
2. Modify the OGC API Feature schema into something compatible with mcp-framework for the tool output. That means rewriting the Record as a list of properties with a name field, as it used to be.
3. Don't return the actual schema but a link to it, hosted by the proxy: Host upstream catalog's schemas in a dedicated page #186
4. Get rid of mcp-framework first: Evaluate replacing mcp-framework with the official MCP TypeScript SDK #112

Barring objections I'll start by implementing 1 because it is by far the simplest option. We can revisit this problem as a separate issue later.

[LionelZoubritzky-IGN]

Done in 3795617 and regression tested in edd9a81

[mborne]

@esgn tested locally npm run inspect:mcp and docker version with VSCode / Copilot. The following hack in GpfDescribeTypeTool.ts fixes the problem :

// FIXME: when mcp-framework is removed, remove this patch which is only here
// because mcp-framework does not accept z.record field types.
const gpfDescribeTypeOutput = zOgcCollectionSchema
  .omit({ properties: true })
  .catchall(z.unknown());

The lack of schema about properties doesn't seem the interpretation of the values ("Décrit moi la modélisation des bâtiments BDTOPO" use the available informations)

No problem found with geocontext-test ( except known issues ) :

GEOCONTEXT_DEV=1 MCP_SERVERS_PATH=config/mcp-servers-dev.json uv run scripts/run_tests.py config/models-anthropic.yaml --model=claude-haiku-4-5

# failures
# - test_geocode_address_not_found = random failures with small models
# -  test_concurrent_tool_calls_are_not_crossed = known with HTTP / pytest 

-> I think we can reference the FIXME in #112 and merge