Skip to main content
Glama
1102tools-dev

ecfr-mcp

by 1102tools-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

lookup_far_clause

Read-only

Convenience tool: look up the current text of a FAR, DFARS or FAR supplement section or clause.

Instructions

Convenience tool: look up the current text of a FAR, DFARS or FAR supplement section or clause.

Pass a section identifier like '15.305', '52.212-4', '2.101', 'DFARS 252.204-7012' or '552.238-81'. The chapter comes from the number (52.x = FAR, 252.x = DFARS, 552.x = GSAR, 852.x = VAAR, 1852.x = NFS, 3052.x = HSAR), so chapter is optional. Prefixes like 'FAR', 'DFARS', '§' and '48 CFR', en dashes, and trailing paragraph cites such as '(d)(11)(xviii)' are handled.

Auto-resolves the latest available date. Returns parsed clean text with heading, paragraphs and citations, plus tables, notes (such as drafting notes, which are not clause text), examples, images and pending_amendments when present; see get_cfr_content. A clause longer than about 60,000 characters comes in pages: use page=2 and so on.

Common FAR sections: 2.101 (Definitions), 9.104-1 (Responsibility), 15.305 (Proposal Evaluation), 19.502-2 (Small Business Set-Asides), 52.212-4 (Commercial Terms), 52.212-5 (Required Commercial Terms).

Input Schema

NameRequiredDescriptionDefault
dateNo
pageNo
chapterNo
section_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.33
    • changedInput schema / properties / chapter / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "integer"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / chapter / default
      Previous value: -"1"New value: +null
    • addedInput schema / properties / page
      Added value: +{
+  "default": 1,
+  "title": "Page",
+  "type": "integer"
+}
  2. Changed2 schema fields changedv1.0.7
    • addedInput schema / properties / chapter / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  }
+]
    • addedInput schema / properties / section_id / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "integer"
+  }
+]
  3. First observedv0.2.6

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/destructive, but the description adds real behavioral value: auto-resolution of the latest date, parsed output contents (headings, paragraphs, tables, notes vs clause text), and a concrete pagination rule ('clause longer than about 60,000 characters comes in pages: use page=2'). The only gap is rate/limit or freshness caveats, which are minor here.

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-loads the one-line purpose, then groups format handling, resolution behavior, output shape, and examples. It is a bit long, and the 'Common FAR sections' list and 'see get_cfr_content' pointer stretch it, but every block is scannable and earns its place for selection.

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 single-lookup tool with an output schema, the description covers selection, identifier formats, pagination, and result composition. The remaining gap is the lack of explicit routing against its closest siblings (search_cfr, get_cfr_content, find_far_definition).

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?

With 0% schema description coverage, the description carries the load and does so well: it demonstrates section_id formats and tolerated prefixes/en-dashes/trailing cites, and derives chapter from the number. page is explained via the pagination rule. date is only described as auto-resolving the latest available date, leaving its override semantics slightly vague.

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 ('look up the current text of a FAR, DFARS or FAR supplement section or clause') and names the sibling it defers to ('see get_cfr_content'). An agent can distinguish it from search_cfr and find_far_definition without opening any schema.

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?

Explains the calling context clearly: pass a section identifier, chapter is optional because it derives from the number, and it lists common sections to guide selection. It stops short of explicit when-not-to-use guidance versus search_cfr or find_far_definition, so it is context-clear but not exclusionary.

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

Deploy Server

Other Tools