Skip to main content
Glama

FlowCastle

by ai.flowcastle
OverviewDiscussionsAdmin

get_action_schema

Read-only

Read-only, needs no API key. The action-authoring contract apply_actions batches are validated against. With NO arguments, returns an INDEX of block types, actions, action kinds and topics with descriptions and sizes. Then request only what this bot uses. Detail responses include essential rules and basic shapes; follow seeWhen before using specialized features: templateExpressions for computed CEL expressions, groupVariables for sender/chat variable ownership, triggerDetails for webhook/module events and trigger output mappings. Responses return whole sections within the budget. Request omitted names again; alsoRelevant lists referenced topics that did not fit.

Input Schema

NameRequiredDescriptionDefault
topicsNoTopics whose rules you need, from the index (e.g. ["knowledgeBases","broadcasts"]).
actionsNoAction names whose contract you need, from the index (e.g. ["create_block","create_link"]).
blockTypesNoBlock types whose payload contract you need, from the index (e.g. ["MESSAGE","AI_TOOL_ROUTER"]).
actionKindsNoACTION-block action kinds whose config you need, from the index (e.g. ["SET_VARIABLE","HTTP_REQUEST"]).
includeCoreNoLeave this out on your FIRST detail call to receive placeholder rules and always-on invariants; the index reports their size as coreChars. Pass false only on LATER detail calls in the same session after receiving those rules.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / includeCore / description
      Previous value: -"Leave this out on your FIRST detail call: that call must return the batch contract, placeholder rules and always-on invariants (~9k characters), and the index does not contain them. Pass false only on LATER detail calls in the same session, to avoid receiving them again."New value: +"Leave this out on your FIRST detail call to receive placeholder rules and always-on invariants; the index reports their size as coreChars. Pass false only on LATER detail calls in the same session after receiving those rules."
  2. Changed1 schema field changed
    • addedInput schema / properties / includeCore
      Added value: +{
+  "description": "Leave this out on your FIRST detail call: that call must return the batch contract, placeholder rules and always-on invariants (~9k characters), and the index does not contain them. Pass false only on LATER detail calls in the same session, to avoid receiving them again.",
+  "type": "boolean"
+}
  3. Changed6 schema fields changed
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / actionKinds
      Added value: +{
+  "description": "ACTION-block action kinds whose config you need, from the index (e.g. [\"SET_VARIABLE\",\"HTTP_REQUEST\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / actions
      Added value: +{
+  "description": "Action names whose contract you need, from the index (e.g. [\"create_block\",\"create_link\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / blockTypes
      Added value: +{
+  "description": "Block types whose payload contract you need, from the index (e.g. [\"MESSAGE\",\"AI_TOOL_ROUTER\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / topics
      Added value: +{
+  "description": "Topics whose rules you need, from the index (e.g. [\"knowledgeBases\",\"broadcasts\"]).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already establish read-only safety, but the description adds useful behavioral context: no API key is needed, responses respect a budget by returning whole sections, truncation is surfaced through `omitted`, and referenced topics that did not fit appear in `alsoRelevant`. It also explains the session-sensitive `includeCore` behavior, which is exactly the kind of operational nuance annotations cannot capture.

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

Conciseness5/5

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

The key operational fact — read-only, no API key — is front-loaded, followed immediately by the no-argument index workflow. Despite covering index/detail modes, budget behavior, and specialized feature routing, every sentence carries useful information without repetition.

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?

There is no output schema, so the description carries the full burden of explaining return behavior. It does so by naming what the index contains, how detail responses work, how budget omissions are reported, and how `alsoRelevant` works, leaving no major ambiguity for an agent preparing to call it.

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 complete, so the schema already documents each parameter. The description nonetheless adds meaningful call-shape semantics by explaining that omitting all arguments returns an index and that subsequent calls should request only the bot's relevant items, which helps the agent understand how the optional arrays are intended to be used together.

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?

The description names the resource and states the specific contract it exposes: the schema that `apply_actions` validation uses. It also distinguishes the no-argument index mode from targeted detail requests, making the tool clearly separate from `apply_actions` and `validate_actions`.

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?

It explicitly tells the agent to call with no arguments first to get the index, then request only the topics/actions/block types actually used. It further directs the agent to follow `seeWhen` before specialized features and to re-request `omitted` names, giving clear sequencing guidance.

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

All FlowCastle 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