GovInbox

Research sources

research

Read-onlyIdempotent

Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service. NOT for bid/no-bid, pursue-or-pass, eligibility, qualification, certification, size-standard, or submit-a-bid questions: for those call explain_policy_boundary first and do not research or use memory to answer. For source='DOE eXCHANGE', searches recorded official DOE laboratory-call documents and explicitly ingested lab calls. Returns separate lab-call identities, recorded stage deadlines, source gate facts and scoped provenance. This is a partial stored source, not a live or complete eXCHANGE search. No company eligibility is assessed. One accepted DOE search counts as one use. Other sources return a pointer and source coverage metadata without a source search or primary quota charge. For FAR, Federal Register, Grants.gov and MCC, use the named source tools.

Input Schema

Name	Required	Description
`limit`	No	Maximum 25 DOE lab-call records; minimum 1; default 10. Other sources remain pointers.
`query`	Yes	Source query or exact recorded reference
`source`	No	DOE eXCHANGE executes a stored lab-call search; far, federal_register, grants and mcc return source pointers

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 24, 2026

addedInput schema / properties / limit

Added value: +{
+  "default": 10,
+  "description": "Maximum 25 DOE lab-call records; minimum 1; default 10. Other sources remain pointers.",
+  "maximum": 25,
+  "minimum": 1,
+  "title": "Limit",
+  "type": "integer"
+}

changedInput schema / properties / query / description

Previous value: -"What to look up"New value: +"Source query or exact recorded reference"

addedInput schema / properties / query / maxLength
```
Added value: +200
```
addedInput schema / properties / query / minLength
```
Added value: +1
```

changedInput schema / properties / source / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maxLength": 120,
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / source / description

Previous value: -"far, federal_register, grants, mcc"New value: +"DOE eXCHANGE executes a stored lab-call search; far, federal_register, grants and mcc return source pointers"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "researchDictOutput",
+  "type": "object"
+}

First observedOct 14, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it warns the DOE source is 'a partial stored source, not a live or complete eXCHANGE search,' states that no company eligibility is assessed, and explains quota behavior ('One accepted DOE search counts as one use' vs. other sources without a primary quota charge). These are useful operational details the annotations do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is long and front-loads two nearly redundant disclaimers ('Not affiliated with the U.S. government, GSA, or SAM.gov. Not a U.S. government service.'), delaying the actual purpose. The remaining content is useful, but the opening could be trimmed and the operational purpose placed first.

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?

Given a read-only, open-world search tool with an output schema, the description covers the critical non-obvious behaviors: policy boundaries, source-specific behavior, quota implications, partial coverage, and alternatives. The output schema handles return-value details. Minor gaps remain around exact result shape, but the definition is largely complete for safe invocation.

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. The description adds semantic meaning for the 'source' parameter: DOE eXCHANGE executes a stored lab-call search, while other named sources return only source pointers and coverage metadata without a search or quota charge. That clarifies the consequence of the parameter choice beyond what the schema text alone states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description eventually states that for source='DOE eXCHANGE' it searches recorded DOE laboratory-call documents, but the first three sentences are disclaimers and exclusions rather than a clear verb+resource statement. The tool name 'research' is generic, and the actual purpose is conditional on a parameter value, so an agent must read several sentences before learning what it does.

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?

It explicitly says when NOT to use the tool (bid/no-bid, eligibility, certification, etc.) and directs the agent to call explain_policy_boundary first in those cases. It also names alternatives for other sources: 'For FAR, Federal Register, Grants.gov and MCC, use the named source tools.' This is exactly the when/when-not/alternative guidance an agent needs.

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

All GovInbox tools Inspect

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

Need Help?