Skip to main content
Glama

Meta Council

by com.meta-council
OverviewDiscussionsAdmin

Account Export

account_export
Read-onlyIdempotent

Export this account's own data across every table the account owns, as the same JSON envelope the REST route returns. The set of tables served is derived from the same ownership reflection that decides what an account deletion removes, so a table the account can destroy is a table it can also read. Credentials never appear: columns held encrypted at rest are withheld unless recorded as the account's own content, and password hashes, reset and verification tokens, and API key hashes are withheld by name. Some tables are deliberately excluded -- see docs/ACCOUNT_DATA_EXPORT.md, and note that the coverage block on every response lists exactly which models are served and which are excluded with their reasons. Artifacts are described by their metadata rows rather than inlined. Bounded rather than streamed: each model reports truncated and the envelope reports complete, so narrow to one model and raise rows_per_model rather than re-reading everything. This is a data export, not an erasure request and not a claim of regulatory compliance. Requires authentication and the account:export scope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelsNoModel names to narrow to, which is how a caller pages a table that truncated without re-reading the others. Omit to export every model the coverage block lists as served.
rows_per_modelNoRow ceiling applied to each model separately. Defaults to 500, maximum 5000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "text": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "text"
-  ],
-  "type": "object"
-}New value: +null
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial behavioral detail beyond that: credentials are withheld (with specifics like password hashes, tokens), some tables are deliberately excluded (referenced to docs), and the export is bounded (per-model truncation with envelope completeness). It also clarifies it is not erasure or compliance, and states auth/scope requirements. No contradiction with annotations.

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?

The description is long but each sentence adds value: purpose, exclusions, credential behavior, pagination tactic, clarification of non-compliance, and auth requirement. It's front-loaded with the core function and structured logically, though a bit dense. It earns its length for a complex 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?

For a tool with no output schema, the description covers all necessary aspects: behavior, exclusions, credentials, pagination, auth/scope, and points to docs for further details. An agent can correctly call it knowing what it does, how to page, and what to expect in the response envelope.

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?

Though schema coverage is 100%, the description enriches parameter meaning: it explains that 'models' is for narrowing to page truncated tables, and that 'rows_per_model' is a per-model ceiling with defaults and max. This goes beyond the schema's bare descriptions, helping an agent understand how to use them together for pagination.

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?

Description uses a specific verb ('Export') and clearly defines the resource ('this account's own data across every table the account owns'). It also specifies the format ('same JSON envelope the REST route returns'). By emphasizing 'this account's own data', it distinguishes itself from potential siblings like audit_export, which might cover broader scopes.

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?

Provides explicit context on when to use it: it's a data export, not an erasure request or compliance claim. It also explains pagination strategy (narrow to one model, raise rows_per_model) and points to documentation for exclusions. It doesn't name specific alternative tools, but the constraints and exclusions are clear enough for an agent to decide.

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