Skip to main content
Glama

Get Document Documents

get_document_documents
Read-only

Get metadata for one specification by its ID.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
titleNo
seriesYes
statusYes
releaseYes
versionYes
doc_typeYes
filenameYes
created_atNoWhen Scout indexed this version, not a 3GPP date; see provenance for those.
doc_numberYes
provenanceNoWhen this version was uploaded to the 3GPP archive and the TSG plenary it came from, with sources. Null when the version has no provenance row yet.
total_text_chunksNo
total_image_chunksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / created_at / description
      Added value: +"When Scout indexed this version, not a 3GPP date; see provenance for those."
    • addedOutput schema / properties / provenance
      Added value: +{
      +  "anyOf": [
      +    {
      +      "description": "When this spec version reached the public 3GPP archive, and the TSG plenary it came from.\n\nEvery value comes from the 3GPP FTP server: archive and dated plenary folder listings, 3GPP's lists of\nspecifications arising from each TSG round, and the 3GPP change request database. Unknown values stay null.",
      +      "properties": {
      +        "archive_date_source": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "'ftp_archive_listing' (the spec's folder under /ftp/Specs/archive/) or 'ftp_plenary_folder_listing' (a dated plenary folder that showed an earlier time).",
      +          "title": "Archive Date Source"
      +        },
      +        "archive_uploaded_at": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "When this version's zip was uploaded to the 3GPP archive (ISO 8601, UTC), as the 3GPP FTP folder listing at archive_url shows it. If 3GPP re-uploaded the file, the earliest time seen. Null when not found; see unknown_reasons.",
      +          "title": "Archive Uploaded At"
      +        },
      +        "archive_url": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "The zip on the 3GPP FTP server whose folder listing gives archive_uploaded_at; open its folder to verify the time.",
      +          "title": "Archive Url"
      +        },
      +        "notes": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Anything a reviewer should know, e.g. the file was re-uploaded or two sources name different meetings.",
      +          "title": "Notes"
      +        },
      +        "plenary_batch": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "YYYY-MM of the plenary round whose batch of specifications includes this version (3GPP's dated folders, /ftp/Specs/YYYY-MM/).",
      +          "title": "Plenary Batch"
      +        },
      +        "plenary_batch_source": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "'tsg_spec_list' (stated in 3GPP's list of specifications arising from that TSG round), 'tsg_meeting_start' (the month the plenary in tsg_meeting started) or 'ftp_plenary_folder' (the earliest dated folder holding the zip).",
      +          "title": "Plenary Batch Source"
      +        },
      +        "statement": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "The known facts as plain sentences, ready to quote, e.g. 'Uploaded to the 3GPP archive on 2026-09-24 at 16:47 UTC. Approved at TSG SA #113 (2026-09-15 to 2026-09-18).' It says 'uploaded to the 3GPP archive' and 'approved at', never 'published': no source states a publication date.",
      +          "title": "Statement"
      +        },
      +        "tsg_meeting": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Plenary meeting ID: 'SP-113' (TSG SA #113), 'RP-109' (TSG RAN), 'CP-110' (TSG CT); a trailing '-e' marks an electronic meeting.",
      +          "title": "Tsg Meeting"
      +        },
      +        "tsg_meeting_end": {
      +          "anyOf": [
      +            {
      +              "format": "date",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Last day of the plenary meeting.",
      +          "title": "Tsg Meeting End"
      +        },
      +        "tsg_meeting_name": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "The meeting as 3GPP names it, e.g. 'TSG SA #113'.",
      +          "title": "Tsg Meeting Name"
      +        },
      +        "tsg_meeting_relation": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "'approved': change requests approved at this meeting created this version (3GPP CR database). 'arising_from': 3GPP lists this version among the specifications arising from this meeting. 'presented': a draft (below version 3.0.0) presented to this meeting.",
      +          "title": "Tsg Meeting Relation"
      +        },
      +        "tsg_meeting_source": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "'cr_database' (3GPP change request database export) or 'tsg_spec_list' (3GPP's list of specifications arising from that TSG round).",
      +          "title": "Tsg Meeting Source"
      +        },
      +        "tsg_meeting_source_url": {
      +          "anyOf": [
      +            {
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "The 3GPP file that names the meeting.",
      +          "title": "Tsg Meeting Source Url"
      +        },
      +        "tsg_meeting_start": {
      +          "anyOf": [
      +            {
      +              "format": "date",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "First day of the plenary meeting.",
      +          "title": "Tsg Meeting Start"
      +        },
      +        "unknown_reasons": {
      +          "anyOf": [
      +            {
      +              "additionalProperties": {
      +                "type": "string"
      +              },
      +              "type": "object"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ],
      +          "description": "Why a field is null, by field name. archive_uploaded_at: 'not_in_archive_listing'. tsg_meeting: 'before_tsg_lists_no_approved_cr' (uploaded before March 2023, when 3GPP's per-round spec lists start, and created by no approved change request, e.g. a release upgrade), 'draft_not_listed', or 'not_in_cr_database_or_tsg_lists'. Nothing is guessed.",
      +          "title": "Unknown Reasons"
      +        }
      +      },
      +      "title": "SpecProvenance",
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "When this version was uploaded to the 3GPP archive and the TSG plenary it came from, with sources. Null when the version has no provenance row yet."
      +}
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that it returns metadata rather than document content, but says nothing about auth needs, rate limits, or error behavior.

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?

A single front-loaded sentence with no filler, which is appropriately sized. It is slightly vague in wording ('specification' vs 'document') but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 need not be described, and annotations cover the read-only nature. Still missing is a tie-in to the surrounding document/tdoc tool family and any note on what 'metadata' excludes, leaving the agent to infer scope.

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 description coverage is 0%, so the schema gives only a name and type for document_id. The description compensates slightly by indicating the parameter is an ID lookup, but adds no format, range, or expected value detail for the integer identifier.

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 states a specific verb and resource ('get metadata for one specification') and scopes it to a single record by ID, which distinguishes it from list_documents_documents_get. However, it never names a sibling alternative and the terminology ('specification') doesn't clearly reconcile with the tool's own 'document' naming or with get_tdoc/list_tdocs.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus the many sibling lookup tools (get_tdoc, fetch_tdoc, list_documents_documents_get). The 'by its ID' phrasing only weakly implies the required input form; no prerequisites, no when-not conditions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.