Skip to main content
Glama

Fixter

by dev.fixter.mcp
OverviewDiscussionsAdmin

Describe Schema

describe_schema
Read-onlyIdempotent

Discover the queryable fields, functions, and measures for a data source. Use this before run_sql to learn what's available.

Sources: logs, spans, metrics. Default: logs.

Call with NO arguments to start — you get the list of services (with volumes) plus the field profile for logs. Then optionally pass service= to drill into one service's fields (different services emit different dynamic attributes).

Per field: type, coverage, distinct-value estimate, top values (low-cardinality), and a GROUP BY verdict (safe / with care / filter only). Dynamic attributes are the ACTUAL keys in your data — use them directly in QuerySQL (e.g. SELECT http_method FROM logs). Resource-level attributes (logs and spans only) use a resource. prefix, e.g. resource.service.name.

Every source has a typed bytes field, the row's stored size in bytes: use SUM(bytes) to measure data volume.

Always returns the source's measures (fn, label, unit, defaultMode — the mode a new alert rule on this measure should default to) and the available QuerySQL functions with their argument counts.

For source=metrics, the metric list is volume-ranked and bounded to a default page; metricsMatched reports the true total independent of what was returned. Pass prefix= to reach past that default page into the tail, e.g. prefix="http." for HTTP metrics.

Optional filter= restricts discovery to matching rows. The predicate is QuerySQL and uses the same field names as run_sql (e.g. level = 'ERROR', http_method = 'GET'); subqueries are not allowed.

Input Schema

NameRequiredDescriptionDefault
pathNoOptional: focus on a single field.
filterNoOptional: QuerySQL predicate restricting discovery, e.g. "level = 'ERROR'". Same field names as run_sql; no subqueries.
prefixNoOptional, source=metrics only: only include metric names starting with this prefix — reaches past the default-bounded list.
sourceNoData source: logs, spans, or metrics. Default: logs.
serviceNoOptional: scope to one service.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Added
  3. Removed
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing return shape (per-field type/coverage/top values/GROUP BY verdict), measure metadata, function argument counts, and that the metrics list is default-bounded with metricsMatched reporting the true total. It does not mention auth or rate limits, but adds substantial context beyond the 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?

Front-loaded with purpose and the before-run_sql rule, then organized into scannable blocks. It is long, and the filter semantics are restated from the schema, but nearly every sentence carries usable detail.

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?

No output schema exists, so the description carries the full burden of explaining returns — and it does: field profiles, measures with defaultMode, QuerySQL functions, and metrics pagination totals. An agent has everything needed to call it correctly and interpret results.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: source defaults to logs, service drills into per-service dynamic attributes, prefix exists specifically to reach past the default-bounded metric page, and filter is a QuerySQL predicate sharing run_sql field names with no subqueries allowed. Only 'path' lacks description-level elaboration.

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: 'Discover the queryable fields, functions, and measures for a data source.' It also scopes the sources (logs, spans, metrics) and clearly separates itself from run_sql, which it feeds.

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?

Explicit sequencing guidance: 'Use this before run_sql to learn what's available,' plus a concrete workflow (call with no arguments to get services, then drill in with service=<name>). It also states the metrics-specific escape hatch via prefix, which is a when-to-use condition.

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

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