Sugra API

get_snapshot

Read-onlyIdempotent

Composed current view of an entity via a named recipe.

Executes a fixed server-side recipe (company_snapshot, etf_snapshot, quote_snapshot, macro_indicator_snapshot, macro_calendar, earnings_snapshot, debt_snapshot) and returns one envelope with freshness, provenance, per-component coverage, and billing. Composed calls charge the recipe's fixed cost (1-2 units) from the daily quota. status "partial" means an optional component was unavailable - the present components are still trustworthy; honor the freshness block (stale=true means the data aged past its budget); for macro_calendar, entity is accepted but does not filter the calendar.

Args: recipe: Recipe name from the fixed manifest. entity: Entity dict from resolve_entity ({"namespace": ..., "ids": ...}).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`entity`	Yes	Entity dict from resolve_entity ({namespace, ids}). Extra keys are ignored.
`recipe`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedSep 14, 2026

removedInput schema / $defs

Removed value: -{
-  "AgentEntity": {
-    "description": "The agent-plane entity shape returned by resolve_entity and consumed by\nget_snapshot / get_timeseries. Extra keys from a resolve result (label,\nconfidence) are accepted and ignored - only namespace + ids are sent on.",
-    "properties": {
-      "ids": {
-        "additionalProperties": true,
-        "title": "Ids",
-        "type": "object"
-      },
-      "namespace": {
-        "title": "Namespace",
-        "type": "string"
-      }
-    },
-    "required": [
-      "namespace",
-      "ids"
-    ],
-    "title": "AgentEntity",
-    "type": "object"
-  }
-}

removedInput schema / properties / entity / $ref
```
Removed value: -"#/$defs/AgentEntity"
```
addedInput schema / properties / entity / additionalProperties
```
Added value: +true
```

addedInput schema / properties / entity / description

Added value: +"Entity dict from resolve_entity ({namespace, ids}). Extra keys are ignored."

addedInput schema / properties / entity / properties

Added value: +{
+  "ids": {
+    "additionalProperties": true,
+    "description": "Identifier map from resolve_entity.",
+    "type": "object"
+  },
+  "namespace": {
+    "description": "Entity namespace from resolve_entity.",
+    "type": "string"
+  }
+}

addedInput schema / properties / entity / required
```
Added value: +[
+  "namespace",
+  "ids"
+]
```
addedInput schema / properties / entity / type
```
Added value: +"object"
```

Changed5 schema fields changedJul 5, 2026

addedInput schema / $defs

Added value: +{
+  "AgentEntity": {
+    "description": "The agent-plane entity shape returned by resolve_entity and consumed by\nget_snapshot / get_timeseries. Extra keys from a resolve result (label,\nconfidence) are accepted and ignored - only namespace + ids are sent on.",
+    "properties": {
+      "ids": {
+        "additionalProperties": true,
+        "title": "Ids",
+        "type": "object"
+      },
+      "namespace": {
+        "title": "Namespace",
+        "type": "string"
+      }
+    },
+    "required": [
+      "namespace",
+      "ids"
+    ],
+    "title": "AgentEntity",
+    "type": "object"
+  }
+}

addedInput schema / properties / entity / $ref
```
Added value: +"#/$defs/AgentEntity"
```
removedInput schema / properties / entity / additionalProperties
```
Removed value: -true
```
removedInput schema / properties / entity / title
```
Removed value: -"Entity"
```
removedInput schema / properties / entity / type
```
Removed value: -"object"
```

First observedJun 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: quota/billing cost (1-2 units), the meaning of 'partial' status, the freshness block contract (stale=true aged past budget), and the macro_calendar edge case where entity is accepted but does not filter. The annotations only cover read-only/idempotent safety, so this description carries the real behavioral load.

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, followed by execution behavior then args. Dense but every sentence adds operative detail; no filler, though it is on the longer side for a two-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema covers the returned envelope, so return-value detail is not needed here, and the description still covers billing, partial status, freshness, and the macro_calendar exception. Combined with safety annotations, an agent has everything needed to call it correctly.

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?

At 50% schema coverage the description must compensate, and it does: it documents recipe as coming from a fixed manifest and lists the valid recipe values (acting as an enum substitute), plus clarifies entity's expected shape from resolve_entity. It stops short of explaining semantics of the ids map.

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 and resource ('Composed current view of an entity via a named recipe') and enumerates the exact recipe names, which lets an agent distinguish it from siblings like get_timeseries, fetch_data, and call_endpoint 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear usage context: composed calls charge 1-2 units from the daily quota, status 'partial' is explained, and freshness/staleness must be honored. However, it never explicitly names an alternative sibling or a when-not-to-use condition, so routing guidance is implied rather than stated.

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

All Sugra API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.