Skip to main content
Glama
Sign In

TeamShared

by io.github.xhad
OverviewDiscussionsAdmin

org_automation_get

Read the org's automation level: what waits for a person and who decides.

Returns the level (full_automation / balanced / gated), what it sets every area to, the overrides on top, and each area's effective value: memory_writes, schema_proposals, entity_proposals, contradictions, routine_changes (auto | review; whether the manager's agent_routine_set waits for a person's Approve), secret_first_use (auto | review; whether an agent's first spend of a vault secret pauses its run for a person), wiki_sources (org | review | all; which memory scopes the curator and the dream report read: org memory only by default, review holds a page built partly from private memory for a person, all is every scope), share_scope (targeted | review | org_wide; who reads a memory once it is shared with a team, project, user or agent: its audience and author, or every member; an org_wide org also gets share_scope_impact.would_narrow, the shared memories a switch to targeted would hide), init_constraints (include | omit; whether agents get the org's standing rules in the instructions they receive when they connect, quoted and cut at about 2 KB; the console calls these "Include org rules" and "Leave org rules out"), decider (console | person | permission), proposer_permission (memory:create | org:admin) and the tool-call gates destructive_actions / publish_actions / spend_actions (review | auto). deciders gives the rule each review kind is decided under (balanced keeps skill_rewrite, schema_link_type and command at permission; gated_command is a queued command that would run a destructive, publish, spend or routine call). Needs memory:read.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely does so: it discloses the auth requirement (memory:read), that this is a read operation, and enumerates what the read resolves (levels, overrides, effective per-area values). It does not state cache/rate-limit or freshness behavior, but the core behavioral profile is well covered.

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?

The first sentence is an excellent front-loaded summary, but the body becomes a dense run-on packed with nested parentheticals and inline enum glossaries. Much of that detail is already carried by the output schema, so the sentences stop earning their place.

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?

An output schema exists, so return values needn't be enumerated, and the description goes beyond anyway. Combined with the stated memory:read prerequisite, an agent has enough to call the tool correctly; only alternative-tool routing is absent.

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?

The tool takes zero parameters, so the baseline is 4. The schema and description agree there is nothing to pass, and no parameter semantics are needed or missing.

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?

The description opens with a precise verb+resource ('Read the org's automation level') and immediately clarifies the domain scope ('what waits for a person and who decides'). It is clearly the read counterpart to the sibling org_automation_set, though it never names that sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The purpose implies usage but there is no explicit when-to-use, when-not, or pointer to org_automation_set for changing values. The only actionable guidance is the trailing prerequisite 'Needs memory:read', which is useful but not a selection rule.

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

All TeamShared toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources