Skip to main content
Glama

Get an agency issuance

get_issuance
Read-onlyIdempotent

Retrieve a government issuance by agency code and reference number, returning metadata and initial passages with citations.

Instructions

Return an issuance by agency + reference number (e.g. 'BIR' / 'RMC 85-2023') with metadata and the first passages of the document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax passages to return (default 20)
agencyYesAgency code, e.g. 'BIR'
referenceNoYesReference number, e.g. 'RMC 85-2023'

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYes
statusYes
referenceNoYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.12.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: it returns metadata and only the first passages rather than the full document. There is no contradiction with 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. It states the purpose, the required lookup keys, gives examples, and notes the output scope in one efficient pass.

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?

Given a fully documented input schema, a present output schema, and annotations that cover safety semantics, the description is sufficiently complete. The only non-obvious behavioral limitation—that only the first passages are returned—is explicitly stated.

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?

The input schema already documents all three parameters with examples and the default/max for limit, so the schema carries the full load. The description repeats the same examples but adds no new semantic information about parameter format or constraints.

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?

The description names a specific verb ('Return'), a concrete resource ('issuance'), and the exact lookup key ('agency + reference number'). It also clarifies the result includes metadata and only the first passages, which separates it from sibling tools like search_issuance and get_provision even without naming them.

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?

The description clearly communicates when to use the tool: when you already have an agency code and reference number and want the issuance's metadata and opening passages. It does not explicitly name alternatives or say 'use search_issuance when the reference is unknown,' so it stops short of a 5, but the context is unambiguous.

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