Skip to content

describe_class(): the family from the class, and a capabilities catalogue on the server - #802

Closed
lmoresi wants to merge 2 commits into
feature/transcript-mcpfrom
feature/class-describe
Closed

lmoresi wants to merge 2 commits into
feature/transcript-mcpfrom
feature/class-describe

Conversation

@lmoresi

@lmoresi lmoresi commented Sep 27, 2026

Copy link
Copy Markdown
Member

view() on a class rendered the docstring only, and the instance view rendered the description. Now every family describes itself with no instance: describe_class() reads the residual templates the class declares (symbols and descriptions), _solver_terms, the add_*_bc methods, a constitutive model's parameter descriptors (symbol, units, description), a history scheme's defaults, and the docstring as documentation. uw.systems.Stokes.view() renders that record; view(class_documentation=True) on an instance renders the family first. One renderer, two records.

The server gains uw_capabilities (every solver, constitutive model and history family, with equation templates, terms and conditions) and uw_capability(name) for one family in full. "Can Underworld solve this equation" is answered from the classes and cannot drift from them.

Stacked on #796. Tests in test_0017 (every solver family describes itself at the class level and renders in every format) and test_0019 (the catalogue).

🤖 Generated with Claude Code

https://claude.ai/code/session_01Na7qBenCp67rDTZhFGTh5V

lmoresi and others added 2 commits September 27, 2026 10:06
…e class; view() on a class renders it

view() on a class rendered the docstring and nothing else, and the
instance view rendered the description: two paths. Now a family describes
itself with no instance and no mesh. describe_class() reads what the
class declares: the residual templates with their symbols and
descriptions, the terms in _solver_terms, the add_*_bc methods it
accepts, a constitutive model's parameter descriptors with symbol, units
and description, a history scheme's defaults, and the docstring as its
documentation. view() on a class renders that record, and
class_documentation=True on an instance renders the family before the
instance, so the two views are one renderer over two records.

The MCP server gains uw_capabilities, the catalogue of every solver,
constitutive model and history family built from those records, and
uw_capability for one family in full. "Can Underworld solve this" is
answered from the classes and cannot drift from them.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Na7qBenCp67rDTZhFGTh5V
…rd for notebooks and the server

The class-level description exists for discovery, so the catalogue built
from it belongs in the library rather than in the MCP server. uw.capabilities(kind,
detail) gathers every solver, constitutive model and history family into
one description record, a child per group and a child per family, one line
each or the whole class record; uw.view renders any record, so a notebook
reads the same catalogue a tool does. The server's uw_capabilities and
uw_capability are now consumers of it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Na7qBenCp67rDTZhFGTh5V
@lmoresi

lmoresi commented Sep 27, 2026

Copy link
Copy Markdown
Member Author

Merged into #790 with the rest of the stack after review; nothing lost, the commits are there.

@lmoresi lmoresi closed this Sep 27, 2026
@lmoresi
lmoresi deleted the feature/class-describe branch September 27, 2026 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant