OODS Foundry

Read Object Registry

object_registry

Read-onlyIdempotent

Read objects from the pinned registry. action list returns names, traits and field counts; domain, trait and maturity filter them, and includeInternal adds internal objects. action show requires name and returns its composed definition; context narrows view extensions. registry_snapshot provides an overview; design_preview looks up recorded screens.

Input Schema

Name	Required	Description
`name`	No	Object name to look up (e.g. 'User', 'Product', 'Invoice')
`trait`	No	Filter to objects composing a given trait (e.g. 'Priceable', 'lifecycle/Stateful')
`action`	Yes	List objects or show one composed definition.
`domain`	No	Filter to objects in a specific domain (e.g. 'core.identity', 'saas.billing')
`context`	No	Optional: filter view_extensions to a single context (e.g. 'detail', 'list', 'form', 'timeline', 'card', 'inline')
`maturity`	No	Filter by metadata maturity level
`reproduce`	No	Include the command and calls for reproducing this result.
`includeInternal`	No	Also list OODS Foundry's internal (non-business) objects, after the business objects. Without it they are left out and hiddenInternal counts them.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 9, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

addedInput schema / properties / action / type
```
Added value: +"string"
```

addedInput schema / properties / reproduce

Added value: +{
+  "default": false,
+  "description": "Include the command and calls for reproducing this result.",
+  "type": "boolean"
+}

changedInput schema / title

Previous value: -"object input"New value: +"object_registry input"

Changed8 schema fields changedOct 8, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / allOf

Removed value: -[
-  {
-    "if": {
-      "properties": {
-        "action": {
-          "const": "list"
-        }
-      },
-      "required": [
-        "action"
-      ]
-    },
-    "then": {
-      "additionalProperties": false,
-      "properties": {
-        "action": {
-          "const": "list"
-        },
-        "domain": {
-          "description": "Filter to objects in a specific domain (e.g. 'core.identity', 'saas.billing')",
-          "type": "string"
-        },
-        "includeInternal": {
-          "default": false,
-          "description": "Also list OODS Foundry's internal (non-business) objects, after the business objects. Without it they are left out and hiddenInternal counts them.",
-          "type": "boolean"
-        },
-        "maturity": {
-          "description": "Filter by metadata maturity level",
-          "enum": [
-            "draft",
-            "alpha",
-            "beta",
-            "stable"
-          ],
-          "type": "string"
-        },
-        "trait": {
-          "description": "Filter to objects composing a given trait (e.g. 'Priceable', 'lifecycle/Stateful')",
-          "type": "string"
-        }
-      },
-      "type": "object"
-    }
-  },
-  {
-    "if": {
-      "properties": {
-        "action": {
-          "const": "show"
-        }
-      },
-      "required": [
-        "action"
-      ]
-    },
-    "then": {
-      "additionalProperties": false,
-      "properties": {
-        "action": {
-          "const": "show"
-        },
-        "context": {
-          "description": "Optional: filter view_extensions to a single context (e.g. 'detail', 'list', 'form', 'timeline', 'card', 'inline')",
-          "type": "string"
-        },
-        "name": {
-          "description": "Object name to look up (e.g. 'User', 'Product', 'Invoice')",
-          "pattern": "^[A-Za-z][A-Za-z0-9_-]*$",
-          "type": "string"
-        }
-      },
-      "required": [
-        "name"
-      ],
-      "type": "object"
-    }
-  }
-]

addedInput schema / properties / context

Added value: +{
+  "description": "Optional: filter view_extensions to a single context (e.g. 'detail', 'list', 'form', 'timeline', 'card', 'inline')",
+  "type": "string"
+}

addedInput schema / properties / domain

Added value: +{
+  "description": "Filter to objects in a specific domain (e.g. 'core.identity', 'saas.billing')",
+  "type": "string"
+}

addedInput schema / properties / includeInternal

Added value: +{
+  "default": false,
+  "description": "Also list OODS Foundry's internal (non-business) objects, after the business objects. Without it they are left out and hiddenInternal counts them.",
+  "type": "boolean"
+}

addedInput schema / properties / maturity

Added value: +{
+  "description": "Filter by metadata maturity level",
+  "enum": [
+    "draft",
+    "alpha",
+    "beta",
+    "stable"
+  ],
+  "type": "string"
+}

addedInput schema / properties / name

Added value: +{
+  "description": "Object name to look up (e.g. 'User', 'Product', 'Invoice')",
+  "pattern": "^[A-Za-z][A-Za-z0-9_-]*$",
+  "type": "string"
+}

addedInput schema / properties / trait

Added value: +{
+  "description": "Filter to objects composing a given trait (e.g. 'Priceable', 'lifecycle/Stateful')",
+  "type": "string"
+}

AddedOct 6, 2026

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds non-annotation context: what each action returns, that filters narrow the list, and that includeInternal appends internal objects. It omits auth needs and any pagination/limit behavior, so not a 5.

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?

Front-loaded with the core purpose, then action semantics, then sibling routing. Dense semicolon clauses earn their place but are slightly packed for an 8-parameter tool, keeping it just short of ideal scannability.

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?

With 8 params, no output schema, and rich annotations, the description covers action behavior, filter applicability, and alternative tools adequately. It doesn't explain the reproduce parameter or return envelope, but nothing critical to correct invocation is missing.

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, but the description adds meaning the schema does not: it ties domain/trait/maturity/includeInternal specifically to the list action and context specifically to show's view_extensions. That action-to-parameter binding is genuinely useful beyond the flat property list.

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?

States a specific verb+resource ('Read objects from the pinned registry') and immediately breaks the tool into its two modes (list vs show). It also distinguishes itself from siblings registry_snapshot and design_preview by naming them and giving their differing scope, so an agent can route without opening any schema.

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?

Gives explicit when-to-use per action ('action list returns names, traits and field counts'; 'action show requires name and returns its composed definition'), names which params apply to list, and names the two alternative tools plus what they cover instead. This is close to full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All OODS Foundry tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Read Object Registry

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources