Summary
For stored-procedure entities, describe_entities now uses the database as the source of truth for parameters and treats config as an overlay (#3400). The same merge does not yet happen for tables and views: the fields array surfaced to MCP agents comes from entity.Fields in config alone, and the database columns are ignored.
Why this matters
Most users do not list every column under entities.<entity>.fields in config — that block is typically used only when a column needs an alias, a description, or a primaryKey override. As a result, today:
- A table or view entity with no
fields: block in config emits an empty fields array to MCP agents. The agent has no way to see what columns the entity actually has.
- A table or view entity with a partial
fields: block (e.g. only one column described for an alias) emits only that column — the rest of the table is hidden from the agent.
This is the same class of agent-can't-see-required-inputs bug that #3400 fixed for stored-procedure parameters.
Where the gap lives
DescribeEntitiesTool.BuildFieldMetadataInfo:
private static List<object> BuildFieldMetadataInfo(List<FieldMetadata>? fields)
{
List<object> result = new();
if (fields != null)
{
foreach (FieldMetadata field in fields)
{
result.Add(new
{
name = field.Alias ?? field.Name,
description = field.Description ?? string.Empty
});
}
}
return result;
}
The DB-side equivalent lives at SourceDefinition.Columns (a Dictionary<string, ColumnDefinition>) on the resolved DatabaseObject — same access pattern the SP parameter merge uses.
Proposed merge rules (mirroring #3400)
For table and view entities:
name: from DB (Columns.Keys); config Alias overrides for the surfaced name.
description: config-only (no reliable DB-side column description in MSSQL/PostgreSQL/MySQL metadata).
primaryKey: from DB (SourceDefinition.PrimaryKey); config PrimaryKey overrides if present.
- (Optional) type info: surface
ColumnDefinition.SystemType / DbType so agents know the column shape.
- DB columns not listed in config are still surfaced (with no alias/description) so agents see the full schema.
- Fall back to emitting config fields as-is when DB metadata is unavailable (same degraded path as the SP parameter merge).
Acceptance criteria
Related
Summary
For stored-procedure entities,
describe_entitiesnow uses the database as the source of truth for parameters and treats config as an overlay (#3400). The same merge does not yet happen for tables and views: thefieldsarray surfaced to MCP agents comes fromentity.Fieldsin config alone, and the database columns are ignored.Why this matters
Most users do not list every column under
entities.<entity>.fieldsin config — that block is typically used only when a column needs an alias, a description, or aprimaryKeyoverride. As a result, today:fields:block in config emits an emptyfieldsarray to MCP agents. The agent has no way to see what columns the entity actually has.fields:block (e.g. only one column described for an alias) emits only that column — the rest of the table is hidden from the agent.This is the same class of agent-can't-see-required-inputs bug that #3400 fixed for stored-procedure parameters.
Where the gap lives
DescribeEntitiesTool.BuildFieldMetadataInfo:The DB-side equivalent lives at
SourceDefinition.Columns(aDictionary<string, ColumnDefinition>) on the resolvedDatabaseObject— same access pattern the SP parameter merge uses.Proposed merge rules (mirroring #3400)
For table and view entities:
name: from DB (Columns.Keys); configAliasoverrides for the surfaced name.description: config-only (no reliable DB-side column description in MSSQL/PostgreSQL/MySQL metadata).primaryKey: from DB (SourceDefinition.PrimaryKey); configPrimaryKeyoverrides if present.ColumnDefinition.SystemType/DbTypeso agents know the column shape.Acceptance criteria
fields:config block surface all DB columns todescribe_entities.Alias,Description, andPrimaryKeyoverlay correctly when present.DescribeEntitiesStoredProcedureParametersTests.Related
McpMetadataHelper.TryResolveDatabaseObject, which this work can reuse)