Skip to main content
Glama

OODS Foundry

by com.oods-foundry
OverviewDiscussionsAdmin

Fetch Structured Data

structured_data_fetch
Read-onlyIdempotent

Read the tokens or manifest dataset. Full data is the default; detail summary returns section counts and the first page call. page reads lossless JSON Pointer entries; pageSize defaults to 10, at most 100, also bounded by size. meta.next continues and meta.full requests full data. includePayload false returns metadata; listVersions lists dates, version selects one, and ifNoneMatch returns matched true without unchanged payload. catalog_list reads components.

Input Schema

NameRequiredDescriptionDefault
pageNoDataset only: read a 1-based page of lossless JSON Pointer entries, each reply below 100,000 characters. Omit for full data.
detailNoDataset only. summary returns section counts and the call for page 1; full (default) preserves the dataset.
datasetYesRegistry dataset to return.
versionNoRequest a specific date-stamped version (e.g., '2026-02-24'). Omit for latest. Applies to dataset mode only.
pageSizeNoDataset entries per page, default 10, also bounded by serialized size. Reply meta gives next and full calls.
reproduceNoInclude the command and calls for reproducing this result.
ifNoneMatchNoReturn matched=true without payload when the ETag matches.
listVersionsNoWhen true, return available version dates instead of payload.
includePayloadNoWhen false, omit payload even if no ETag match occurs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / detail
      Added value: +{
+  "description": "Dataset only. summary returns section counts and the call for page 1; full (default) preserves the dataset.",
+  "enum": [
+    "summary",
+    "full"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "description": "Dataset only: read a 1-based page of lossless JSON Pointer entries, each reply below 100,000 characters. Omit for full data.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / pageSize
      Added value: +{
+  "description": "Dataset entries per page, default 10, also bounded by serialized size. Reply meta gives next and full calls.",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed6 schema fields changed
    • removedInput schema / $id
      Removed value: -"structuredData.fetch.input.json"
    • removedInput schema / $schema
      Removed value: -"https://json-schema.org/draft/2020-12/schema"
    • changedInput schema / properties / dataset / enum
      Previous value: -[
-  "components",
-  "tokens",
-  "manifest"
-]New value: +[
+  "tokens",
+  "manifest"
+]
    • removedInput schema / properties / includeInternal
      Removed value: -{
-  "default": false,
-  "description": "Live components dataset only: also list OODS Foundry's internal (non-business) objects, after the business objects. Without it they are left out and registry.hiddenInternal counts them; a dated export is served unchanged.",
-  "type": "boolean"
-}
    • 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: -"structuredData.fetch input"New value: +"structured_data_fetch input"
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations cover safety (readOnly, idempotent, non-destructive, not open-world), so the bar is lower, and the description still adds real behavior: ETag/ifNoneMatch short-circuit returning matched=true without payload, page-size bounds, and continuation via meta.next. It does not clarify what a truncated page does to the rest of the dataset or whether pages are stable across calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose correctly, but the body is a dense run-on chain of semicolon clauses that mixes parameter restatement, output hints, and an orphaned sibling note. Information is packed in but not organized by task, making it harder to scan than its length suggests.

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?

For a 9-parameter, no-output-schema tool, the description covers the main mode interactions (full vs summary, page vs full, version vs listVersions, payload suppression) reasonably well. The gap is that meta.next/meta.full are referenced as output fields with no output schema to define them, so their shape is left implicit.

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 each parameter's meaning, bounds, and defaults; the prose largely restates pageSize, detail, and page. The only added value is linking the params into a workflow (meta.next continues, meta.full requests full data), which is modest. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Read the tokens or manifest dataset") and enumerates the modes it supports. It gestures at sibling differentiation with "catalog_list reads components," but that clause is a dangling fragment that doesn't clearly frame it as the alternative for component data.

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?

Gives concrete when-to-use context for modes: full is default, summary for section counts, page for paginated JSON Pointer entries, includePayload false for metadata-only, listVersions for dates. However it never states when NOT to use the tool or spells out the routing rule to catalog_list beyond the terse fragment.

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

All OODS Foundry toolsInspect
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.

Resources