Skip to main content
Glama

Get Arms Sales Notification Totals

arms_sales_summary
Read-onlyIdempotent

Totals from the Arms Sales Register, built from the Federal Register copies of the Defense Department's notifications to Congress under section 36(b)(1) of the Arms Export Control Act, delivered from January 1, 2017. Returns the total estimated value of the proposed sales notified to Congress with its basis and the date the copies are printed through; notices and estimated value by year delivered, with the 36(b)(5)(C) enhancement or upgrade reports counted apart; the 10 largest buyers by estimated value notified; the equal one-year windows around January 20, 2025 with the Gulf governments' share, the last window labelled open, as the Federal Register prints notices months after delivery; the 10 contractor families named in the most notices, with the value of the notices naming each; the counter-findings (the largest buyer's FARA rank, no named family among the reviewed super PAC donors, and every printed sales-commission line saying none); the transmittal-number gaps and the publication lag by year, with the Taiwan line; the FMS trust fund account as context only; and the register's headlines with their basis. The notices printed with no delivery date and the notice DoD withdrew are listed, each labelled as outside every total. Each row is a proposed sale notified to Congress, and its value is the estimated value the notice prints: never a price, a signed case, a contract or a payment. A company appears only as a notice names it, resolved to the register's reviewed family table: the value of the notices naming a family is shared, never split between the companies a notice names, never added across families and never described as company revenue. 36(b)(5)(C) enhancement or upgrade reports are a separate record type, counted apart; their values are never added to 36(b)(1) values. The estimated value notified, FARA money, connected-PAC money, lobbying amounts and the inaugural and super PAC records are separate records, shown side by side: never added together and never put in date sequence with a notice. Every answer carries the register's question note: these are proposed sales the Defense Department notified to Congress, as printed in the Federal Register; a notification is not a completed sale, and the records do not show why any sale was proposed or whether it went ahead. Every answer also carries the side-by-side caption, the as-of date, the date the Federal Register copies are printed through, each file's date, the source page on morvs.ai and the licence. Where FEC figures appear, the answer quotes the FEC's restriction on the sale or use of individual contributor information (52 U.S.C. 30111(a)(4)). Institutions only: no official, signer, lobbyist, treasurer, candidate or member of Congress is named, and single-person firms are withheld and appear only as counts. No party label is given and no buyer government is characterised.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior5/5

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

Annotations already cover read-only and idempotent safety, but the description adds substantial behavioral context: values are estimates never prices or contracts, enhancement reports are counted apart and never summed with 36(b)(1) values, separate record types must not be combined, withdrawn and undated notices are listed outside totals, and every answer must carry a question note, as-of dates, source and licence. It also discloses the FEC restriction and that single-person firms are withheld, which goes well 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.

Conciseness2/5

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

The description is a dense wall of semicolon-linked clauses that enumerates every section of a very large output. While each clause carries some content, the lack of paragraphing and the run-on style make it hard to scan, and the core purpose is buried under enumeration; it is over-specified rather than under-specified.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema summary tool, the description covers the returned sections extensively (totals, top buyers, windows, contractor families, counter-findings, gaps, trust fund, headlines) and the required accompanying caveats. It is nearly complete on content, though the dense structure reduces how usable that completeness is.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description appropriately focuses on output content rather than inventing parameter semantics.

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 opening states a specific resource and scope: totals from the Arms Sales Register built from Federal Register 36(b)(1) notifications since 2017. It is clear what the tool returns in aggregate, but it never distinguishes itself from siblings like arms_sales_notices, arms_sales_buyer or arms_sales_contractor, so an agent cannot tell from the description alone why it should pick this summary over those detail tools.

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 when-to-use guidance, no statement of alternatives, and no exclusions about when other sibling tools are more appropriate. The long caveats about not adding records together are interpretive rules, not routing guidance, so the agent is left to infer that this is an overview tool.

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.

Resources