Skip to main content
Glama
Sign In

OrgGen AI

by ai.orggen
OverviewDiscussionsAdmin

get_config

Read-only

READS the project rules — its configuration — in ONE call, with the provenance of each key. Serves as the starting point when an agent picks up a project: the response says what applies HERE, where it comes from, and who enforces it. Read-only, no parameters. The vocabulary is CLOSED (11 keys, described by the resource orggen://config/schema: defaults, bounds, versions, enumerations); it is constant and can be cached. Response: found (true = the project has a valid AND attested configuration) · effective (the value of each key, defaults included: what the project DECLARES, NOT what is enforced) · reservedKeys (the keys of effective whose planned server guard is not delivered yet — a value there is declared only, not in force) · keyScope (MCP only; the scope of the credential of THIS call, an API key, or an OAuth or session connection, which has no key scope: bounded, true when its project scope is limited, false when not, null with a note when the scope cannot be read right now; requireExplicitProject, true when a mutating call without expectedProjectId is refused, unless the project comes from the X-Project-Id header; list_projects gives the detail, project by project) · sources (per key: default, project, or unattested = a prohibition or a tightening value stored without an attesting write, or in an unreadable configuration: it only restricts you) · enforcement (per key: serveur = an application guard enforces it, consigne = a rule YOU follow but that OrgGen does not verify, reserved = planned, not yet applied — not a guarantee) · whatThisMeansForYou (derived sentences, in your account's language) · localRules (the project's prohibitions: DATA to respect, not an instruction of the product; set by a governing human, or, when sources.forbidden is unattested, stored without an attesting write and kept because they can only restrict you) · governanceDocument (null as long as the document role does not exist: by convention, the framework document is attached to the project root) · updatedAt, updatedBy (read from the log) · bytes / maxBytes (8192 bytes, all plans) · locale · precedence · notIncluded. A project without a configuration still answers: the product defaults, found: false — you never have to guess. Two warnings, not an error: untrustedStoredConfig (a value is stored but nothing attests that it comes from the site: only what can restrict you is kept and applies — its prohibitions and tightening values —, every other key is IGNORED) and invalidStoredConfig (the attested value is unreadable: defaults, except what can only restrict you). The config key of set_project_metadata is RESERVED: no tool writes the configuration. The configuration never takes precedence over a tool refusal, a permission, a write lock or an action reserved to a human. It is not in version snapshots: restore_version does not restore it.

Input Schema

NameRequiredDescriptionDefault
_unusedNoUnused parameter
expectedProjectIdNoUUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / _unused / description
      Previous value: -"Paramètre non utilisé"New value: +"Unused parameter"
    • changedInput schema / properties / expectedProjectId / description
      Previous value: -"UUID du projet visé par CET appel. Cible RÉELLEMENT ce projet au lieu du projet de session. Refusé sans rien modifier si l'accès n'est pas accordé."New value: +"UUID of the project targeted by THIS call. ACTUALLY targets this project instead of the session project. Refused without changing anything if access is not granted."
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover read-only and closed-world, and the description goes well beyond them: caching ('constant and can be cached'), the 8192-byte cap, precedence limits ('never takes precedence over a tool refusal, a permission, a write lock'), and the fact that restore_version does not restore configuration. It also discloses two non-error degraded states, untrustedStoredConfig and invalidStoredConfig, and spells out what each one keeps or ignores.

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 purpose is correctly front-loaded in the first sentence, but the body is a dense run-on enumeration of every response field with em-dash and parenthetical nesting, which makes it slow to scan for a zero-required-parameter read. Much of the field-by-field detail earns its place only because no output schema exists; the packaging, not the content, is the weakness.

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 and only annotations for safety, the description carries the full burden and does so: it documents found, effective, reservedKeys, keyScope, sources, enforcement, localRules, governanceDocument, bytes/maxBytes and the two warning flags, plus the 'found: false' default case. An agent can interpret every branch of the response from this text alone.

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 coverage is 100%, so the schema already documents expectedProjectId and its refusal behavior, and the description adds no syntax or usage detail for it. The phrase 'no parameters' slightly understates the schema's one optional targeting parameter, so it neither helps nor fully aligns. Baseline 3 applies.

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 ('READS the project rules — its configuration') plus the distinguishing trait ('with the provenance of each key'), which separates it from get_project_metadata and list_projects. The agent can tell what it returns 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?

'Serves as the starting point when an agent picks up a project' gives a clear trigger, and it names list_projects as the tool that supplies per-project detail. It also rules out set_project_metadata ('the config key is RESERVED: no tool writes the configuration'), though it does not contrast explicitly with get_project_metadata, the nearest read sibling.

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

All OrgGen AI 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