Skip to main content
Glama

Meta Council

by com.meta-council
OverviewDiscussionsAdmin

Execute Saved View

execute_saved_view
Read-onlyIdempotent

Run saved ticket, attention or reviewed-work intent against live owned data. Ordinary views return matching tickets and optional group counts. Triage returns the original reader envelope in data, the view and a definition_token. For triage continuation send expected_definition_token; attention uses next_offset, reviewed work uses next_cursor with offset0. A changed definition refuses409: reload and restart. Ordinary views refuse cursor/token. Results are always YOUR tickets: a shared view shares the question, not the answers, so opening a teammate's view runs it against your own work and never reveals theirs. An archived view is refused rather than executed. Returns the same payload the web app receives. Follow next_offset while has_more; live ticket or filter changes can shift offset pages, so restart to refresh. Requires authentication and the tickets:read scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size: ordinary defaults200/max500, attention defaults100/max500, reviewed work defaults20/max50. Omit for the reader's default.
cursorNoReviewed-work next_cursor only; never saved in the definition.
offsetNoHow many tickets to skip. Defaults to 0.
view_idYesThe view's id, from list_saved_views.
expected_definition_tokenNoRequired on triage continuation; bind to the preceding saved definition.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Reviewed-work next_cursor only; never saved in the definition.",
+  "maxLength": 2048,
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / expected_definition_token
      Added value: +{
+  "description": "Required on triage continuation; bind to the preceding saved definition.",
+  "pattern": "^[0-9a-f]{64}$",
+  "type": "string"
+}
    • removedInput schema / properties / limit / default
      Removed value: -200
    • changedInput schema / properties / limit / description
      Previous value: -"How many tickets to return. Defaults to 200. The ceiling is above the ordinary ticket page size because group counts need to see more rows in one call than a paged list does."New value: +"Page size: ordinary defaults200/max500, attention defaults100/max500, reviewed work defaults20/max50. Omit for the reader's default."
  2. Changed1 schema field changed
    • addedInput schema / properties / offset / maximum
      Added value: +2147483647
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "text": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "text"
-  ],
-  "type": "object"
-}New value: +null
  4. Added

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: results are scoped to the caller's own tickets even for shared views, archived views are refused, a changed definition returns 409 and requires reload/restart, live ticket or filter changes can shift offset pages, and it requires auth plus the tickets:read scope. This is exactly the operational context annotations cannot convey.

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 purpose in the first sentence and each subsequent sentence carries operational detail, though some sentences are dense and the shared-view explanation is slightly repetitive ('shares the question, not the answers' restated). Appropriately sized for the complexity despite the density.

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?

With no output schema, the description compensates by describing return shapes (matching tickets plus optional group counts; triage returns the reader envelope, view, and definition_token) and notes it mirrors the web app payload. Auth/scope, refusal cases, and pagination rules are all covered.

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 cross-parameter semantics the schema cannot: which intent uses offset vs next_offset vs cursor, that offset0 pairs with next_cursor, and that token/cursor are rejected for ordinary views. It adds real meaning over the per-parameter schema text.

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 ('Run') and resource/intent set ('saved ticket, attention or reviewed-work intent against live owned data'), and is clearly distinguishable from siblings like get_saved_view, list_saved_views, and create_saved_view. An agent can tell what this does without opening the 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 concrete conditional guidance: send expected_definition_token for triage continuation, next_offset for attention, next_cursor with offset0 for reviewed work, and notes ordinary views refuse cursor/token. It does not name sibling tools to use instead in ambiguous cases, but the when-to-use conditions are clear and specific.

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

All Meta Council toolsInspect
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.

Resources